The screen was slow and the query was not
A dashboard measured 926ms against a 300ms budget. The route behind it answered in 250ms. Which page is slow and why it is slow are two questions.
We hold every page in this product to 300ms and keep a board of which ones are over. This week the owner's dashboard came up on it: four real loads averaging 926ms on the release that was running. That is the signal working — a real screen, real loads, measured in real browsers rather than in a lab.
The obvious next move is to go and make the dashboard's query faster. We did not, because we measured it first. The route behind that screen answers in about a quarter of a second and sends 1.7KB. It makes two trips to the database, both of them batched, and there is nothing queued behind them. The screen itself makes exactly one call. There was nothing there to fix.
A page is not its slowest query
A page's time is the app's own download, the browser's work, the round trip to wherever the data lives, the server's time inside that, and the drawing. Any of those can dominate, and they fail in different ways:
- A slow first load with fast repeats is the application downloading itself, not the screen.
- A slow every-time load with a fast query is rendering, or distance.
- A slow query with a fast page is a report that nobody waits on.
Treat them as one number and you optimise whichever part you guessed at. We have had that board split first loads from later ones for a while precisely because of this, and it has repeatedly stopped us rewriting a screen when the real cost was the download in front of it.
The measurement had a gap of its own
Here is the part worth passing on. Our board tells us which page is over budget on the release running now — that matters, because a seven-day average covers code that has since been replaced. But the columns that explain a number — the time in the network, the time inside the server, whether the loads were first loads — were still seven-day blends. So the board could name the slow page and could not say where its time went without somebody going and timing the route by hand.
That breakdown is now scoped to the running release too. It is a small thing and it is the difference between an instrument that raises a question and one that answers it. If you have a performance dashboard, it is worth checking whether the number that tells you something is wrong and the number that tells you what is wrong are measured over the same window. Ours were not.