A screen that could never be late
Our page-speed board had a rule: anything averaging over 300ms gets made faster. Four screens in the back office were structurally incapable of ever appearing on it, however slow they got. What a report cannot see is more dangerous than what it shows.
There is a rule on this product that predates most of its features: track how long every page takes to load, and anything averaging over 300ms gets made faster. It is a good rule because it is falsifiable. Every screen reports a number from the browser that actually loaded it, the numbers go on a board in the owner dashboard, slowest first, and anything over budget is a job.
Reading that board one night, several screens were reporting warm averages of two to seven milliseconds. A settings screen at four milliseconds. A store details screen at three.
Four milliseconds is not a page load. It is roughly the time it takes to put text on a screen and nothing else.
What the number was actually of
The back office is a single page that swaps screens. When you click through to a screen, the router paints a loading box, calls that screen's render function, waits for it to finish, and reports how long that took.
Which is exactly right, as long as the render function finishes when the screen has its data. Some of ours did not. They painted the loading box, fired off a request for the data, and returned immediately — leaving the request in flight. The router saw the function finish in three milliseconds and wrote three milliseconds on the board. Meanwhile the screen sat there saying Loading while a request crossed the Atlantic and came back.
Three of the small numbers turned out to be honest. One screen renders a fixed list and fetches nothing, so four milliseconds is the truth. Another is a redirect that hands you to the kitchen display. The till views draw from data already in memory. A small number is not automatically a lie.
But four screens were not honest, and the consequence is worse than a slow screen. They could not appear on the board at all. Those pages could have taken four seconds every single time and the 300ms rule would never once have pointed at them, because the rule reads a number that was never about them.
Proving it, rather than reasoning about it
Reading code and concluding is how the wrong answer gets written down confidently. So instead: open the office in a real browser, delay every single API call by a fixed 400 milliseconds, and see what each screen reports. A screen that genuinely waits for its data cannot report less than 400ms. A screen that reports the paint will report the paint.
The results were not ambiguous. Store details went from 3ms to 439ms. Gratuity from 2ms to 616ms. Accounts from 6ms to 443ms. Business details, which had been half-honest — it waited for one thing and not for three others — went from 454ms to 922ms.
The important row is the one that did not move. The settings screen that fetches nothing reported 2ms before and 3ms after. That is the control, and without it the whole experiment says nothing: it proves the injected delay only moves screens that actually wait, and that a tiny number is still a legitimate answer for a screen that does no work.
The fix changed no pixel
Each of those screens already painted its shell before firing its request. Making the render wait for the data does not delay anything a person sees. The only thing that moved is the moment the number is sent.
So nothing got faster. Four screens simply became visible to a rule that had been unable to see them. Some of them may now show up over budget, and that is the point rather than a regression.
Why this generalises past our code
If you run a venue, you probably have at least one dashboard whose numbers come from somewhere you have never checked. Waste, wait times, prep times, how long a card payment takes. The question worth asking of any of them is not whether the number looks reasonable. It is: what exactly stops this number being recorded, and could the bad case produce a good-looking number?
A wait-time report that only records orders somebody remembered to tap will show you a lovely average. A waste log with no entries means either no waste or no logging, and the two look identical from the outside. A number that is absent is not a number that is fine.
The board on this product has one more column now, because of this: alongside the seven-day average sits the average measured only on the release that is actually running. A fast average for code that has since been replaced is not evidence about anything.