In this guide 6 sections
Reproduce the slowness on one named journey first. Then measure the frontend, network, API, database and infrastructure separately with real timing data, because the bottleneck is usually one narrow layer and guessing buys the wrong fix. Evidence comes before spending.
Defining the slow journey and reproducing it
“Slow” is a complaint, not a diagnosis. Make it specific: which screen, which action, which role and which hour, such as a sales report that takes over a minute to load around 6 pm. Ask for the exact address, the role used and the time of the last slow load, so the first reproduction attempt starts from facts instead of memory.
Then reproduce it under the reported conditions. Use the same data volume, the same account type and the same hour, because a page that loads with ten test records can crawl on two years of history. Compare office Wi-Fi with a cellular connection.
Measuring frontend, network, API, database and infrastructure timing
One page load is several steps in sequence. The browser renders, the network carries the request, the API processes it, the database runs its queries, and shared infrastructure may be waiting on other load. A profiler or flamegraph reports these splits. Browser developer tools show the frontend and network split quickly, while the server logs or an application monitor show the API and database share. A single slow API call may itself wait on a third-party service such as a courier tracker or payment gateway, which belongs in the infrastructure share.
Time each layer, not only the total. A report that takes eight seconds may be seven seconds of database query and one second of everything else, and then polishing the frontend code would change almost nothing.
Separating volume spikes from a persistent inefficiency
Not every slowdown has the same shape. A slowdown that appears only during a predictable peak, such as month-end billing, a seasonal sale or the morning login rush, usually points to capacity under concurrent load. Locks and deadlocks appear only under load. Check whether the slow hours match a scheduled job such as a nightly backup, a report email or a data sync, because background work can starve interactive screens. Ask who runs the heaviest report.
A constant slowdown points elsewhere. Typical causes are an unindexed database query, a report that recalculates what it could cache, or a list endpoint without pagination that returns every row. Blaming user numbers can hide a single query that scans the whole order history table on every page load, whoever happens to be logged in at the time.
Prioritising bottlenecks with evidence, not guesses
Rank fixes by measured impact. “Upgrade the server” is the usual first suggestion because it needs no investigation, yet it is only right when the evidence shows the infrastructure layer holding the time. A small index change on the slowest report often beats a server migration that moves the same delay to a new machine.
Build a short table instead. List the journey, layer, measured time and share of the total from real traces, then put the first fix on the largest share of the most important journey. The table ends the argument.
Retesting fixes against an agreed baseline
Record a baseline before any change. Without it nobody can tell afterwards whether a fix helped, changed nothing or quietly made another screen worse, and “it feels faster” is not evidence. Store the baseline next to the ticket, with the date, the data volume and the tool used, so a colleague can repeat the measurement months later.
Retest the same journey the same way. Then keep watching for some days, because a fix that holds under a quiet afternoon can degrade again when traffic returns to its usual pattern. A later check catches that. Report the result as a before and after pair for the one journey, in seconds, and say plainly which layer changed and what was done to it.
Application request timing breakdown
A waterfall-style table for one slow journey, listing frontend render, network, API processing, database query and infrastructure wait, each with its measured time and share of the total. Figures are recorded before and after every fix.
Open a blank worksheet to printQuestions owners ask
Should we upgrade the server first?
Not without evidence that infrastructure is the bottleneck. An inefficient query or slow report will swallow whatever capacity you add, at extra ongoing cost, while the real fault remains untouched.
How do we locate the actual bottleneck?
Time every layer of the slow journey separately instead of only the total, then look at which layer holds the largest share of the measured time. That layer is rarely the one blamed first.
What if the slowness cannot be reproduced?
Ask the reporter for a screen recording that shows the clock, the account used and the exact steps taken, then compare data volume against a test account. Intermittent slowness usually depends on data or timing.