A call nobody waits for is not a wait

The hub screen sat at the top of the speed board at 860 milliseconds, and the column beside it said 856 of those were spent waiting on one API call. A screen that is nothing but its API wait. Except the call it named was not the hub's own route. It was the call that tells us which screens get used, and a different screen had named the same call on a different day.

A beacon, three ways over

Following it into the client: the router fires that call before it starts drawing the screen, the function that sends it does not wait for the answer, and the request swallows its own failure. Nobody is looking at a spinner while it runs. It overlaps the draw instead of following it. A slow one costs nobody anything, and it was being reported as the screen's own API time, on the number our 300 millisecond rule is read from.

The reporting code already excluded exactly one background call: its own report to the board. The reasoning behind that exclusion had never been applied to any other. We had even added a column weeks earlier so a reader could see when a shared call was winning, after four rows all named the same one. Seeing it is not the same as not counting it.

What goes on the list, and what deliberately does not

There is now a named list of background calls, excluded before the slowest call is chosen, with the rule for adding a third written above it: a path goes on only when the client has been read and found not to wait on it. The languages call looks exactly like one and is not. The menu fires it at load and a second asker waits on the first, so excluding it would hide a real wait, which is the mirror of the bug.

Proving it in a browser took four attempts, and the first three were worthless. Two of them passed with the fix reverted. A request has no timing entry until it finishes, and the page samples the list the instant it reports, so delaying the background call past the draw guaranteed it was absent, the opposite of the case under test. Local screens draw in under 80 milliseconds, which makes the window a few milliseconds wide. On the live hub at 860 it is metres wide, which is why the bug was visible there and nowhere else.

The fourth probe stopped arranging timing and built the load: a real slow background call, a real screen call, both with their bodies read, one report over both. Old code: 716 of 718 milliseconds, naming the beacon, the hub's 856 of 860 reproduced. New code: 14 milliseconds, naming the screen's own call. The same harness with no delay at all showed the beacon inside the window on four of four navigations, so it was a live candidate the old rule really did compare, not a theory.