How to Find the Reason Your Business Application Is Slow

"The app is slow" is a starting complaint, not a diagnosis — it needs to become something specific before anyone can fix it: which screen, which action, for which users, at what time of day. A vague complaint sends a team chasing the wrong thing; a specific one, like "the sales report takes over a minute to load every day around 6 pm," points straight at where to look.

Once the journey is specific, reproduce it under the same conditions it was reported in — same data volume, same time of day, same user role — because a page that loads fine with ten test records can behave completely differently with two years of real transaction history behind it.

A single "page load" is actually several sequential steps, each with its own timing: how long the browser takes to render, how long the network request takes to travel, how long the API takes to process it, how long the database query inside that API takes, and how much of any of that is waiting on infrastructure that is under-resourced or shared with other load.

Measuring each layer separately, rather than only the total, is what actually locates the bottleneck. A report that takes eight seconds might be seven seconds of database query and one second of everything else — in which case optimising the frontend code would have no meaningful effect at all, however reasonable a guess it seemed.

Not every slowdown has the same shape, and the shape matters for the fix. A problem that only appears during a predictable traffic spike — a festival sale, month-end billing, a morning login rush — is often a capacity issue: the system works fine most of the time and only strains under unusually high concurrent load.

A problem that is present consistently, regardless of how many people are using the system, points to an underlying inefficiency — an unindexed database query, a report that recalculates something it should have cached, code that fetches far more data than the screen actually displays. Consider a mid-sized wholesale distributor whose reporting dashboard was blamed on "too many users" for months, when in fact a single query was scanning the entire order history table on every page load, regardless of how many people were logged in at the time.

Once timing data exists across the layers, prioritise fixes by actual impact rather than by which layer is easiest to blame — "upgrade the server" is often the first suggestion precisely because it requires no investigation, not because the evidence points there.

A short table — journey, layer, measured time, share of total — built from real traces turns this from an argument into a straightforward decision: whichever layer accounts for the largest share of the time on the highest-impact journey is where the first fix should go.

Before any fix is made, record the current timing as a baseline — without it, there is no reliable way to know afterward whether a change actually helped, made no difference, or quietly made something else worse. "It feels faster" is not evidence; the same measurement taken before and after is.

After a fix, retest the same journey under the same conditions used to establish the baseline, and keep watching for a reasonable period afterward — some fixes hold up under normal load but degrade again once traffic returns to its usual patterns, and only a follow-up check some days later would catch that.