Performance
A slow page is usually one of a few specific, identified layers, most already fixed by default — rarely the database. Here’s the honest, current picture.
The single biggest thing you control: run a real build
Serve the built frontend, not the dev server, and run the backend without live reload. The
dev server ships hundreds of unminified files on every load — fine while coding, genuinely slow
otherwise, especially on a phone. npm run build once, run the backend without --reload, and
this goes away. Sluggish instance set up for development instead of daily use? This is very
likely why.
What else has already been fixed
| Cause | Fix |
|---|---|
| Many things loading at once serialized behind Python’s own concurrency limits | Expensive calculations now gated so a burst of requests doesn’t fight for the same CPU |
| Caching was silently broken — too aggressive invalidation on the backend, none trusted on the frontend | Rebuilt to actually hold; a repeated view within a short window reuses the last answer |
| A live price fetch could block unrelated requests waiting on a slow provider | An interactive view shows the last known price immediately, refreshes in the background |
| A long chat history was rendered and reloaded in full | Now paged and trimmed |
What’s still a known, open cost
- A few pages compute the same underlying numbers more than once per load — work is ongoing to compute shared foundations once per page, not once per widget.
- A couple of specific reports (a full financial briefing, long-history return calculations) are inherently heavier and take longer than an ordinary read.
If something feels slow
- Confirm you’re running a built frontend and non-reloading backend — resolves most “everything’s slow” reports.
- One specific page or number? Report that instead of “the app is slow” — far more actionable than a general impression.
Related pages
operations/logs— the per-request timing breakdown, if you want to check yourself