Performance in web applications: where slowness comes from

The short answer

Slow applications lose users quietly: nobody complains, they just do the task somewhere else or avoid it. Slowness hides in five places, and every slow screen has one dominant cause among them. Database queries that fetch too much or lack an index. Too many round trips between browser and server, or between server and database. Heavy front-end bundles that make the browser do work before anything appears. Slow external calls that the screen waits on. And work repeated on every request that could have been done once and cached. The way to find the cause is a trace of one slow request, not a debate, and most fixes are boring once the cause is named.

The five places

Place	How it shows	Typical cause	Typical fix
Database	Lists and searches slow; slower as data grows	Missing index; a query per row instead of one query; fetching everything to show ten	Indexes; batch queries; pagination; select only needed fields
Round trips	Screens that load in stages; spinners in sequence	Many small requests instead of one; waterfall of dependent calls	Combine requests; load in parallel; fetch what the screen needs in one go
Front end	Slow to appear, slow to respond after loading	Large JavaScript bundles; heavy libraries; rendering huge lists	Split code by route; drop heavy dependencies; virtualise long lists
External calls	Unpredictable hangs	Waiting synchronously on a third-party API	Timeouts; caching; move to background jobs; show partial results
Repeated work	Everything a little slow, servers busy	Recomputing the same thing per request; no caching	Cache computed results; precompute in background jobs

The method

Keeping it fast

Performance is easier to keep than to recover. Budgets checked in the pipeline catch regressions on the day they are introduced. Real-user monitoring shows drift as data grows and usage changes. A quarterly look at the slowest screens keeps the list short. And the habit of tracing before touching anything keeps effort where it matters rather than where someone guessed.

What this means for you

When an application feels slow, insist on measurement: real-user timings to find the screens, a trace to find the cause, a boring fix aimed at it. Database queries, round trips, front-end weight, external calls and repeated work cover nearly everything. Set budgets, check them in the pipeline, and treat a slow screen as a defect with a number attached rather than a reason to buy a bigger server.