The list had a lid, and the busy screens fell off it
Eight of fourteen slow screens gave no reason at all. The browser keeps 250 resource timings and silently drops the rest, so the deepest screens went blank.
Our speed board lists every screen slowest first against a 300 millisecond budget, and beside each row it says how long the screen's own API calls took, how many it made, and which was slowest. The first morning it had real traffic, fourteen screens were over budget. Eight of them had nothing beside the number. Slow, with no column to say why, and the two slowest rows on the board were among the eight.
It was not that those screens made no calls
Every one of them waits for its data before it draws, so the calls had finished by the time the screen reported itself. The browser should have had a timing entry for each. It did not, because the list a page can ask the browser for has a lid of 250 entries, and past the lid the browser drops everything, silently, with no error and no event unless you ask for one.
The back office loads about 170 files before anyone opens a screen. Sixteen screens into a session the lid closes. The screens that fall off it are the ones somebody reached deepest, which are the ones they use most. That is the signature on all eight rows.
The second fault was the one we should have caught the day before
Past the lid the breakdown vanishes. Approaching it, the breakdown is wrong. One screen reported two calls at the cap and five once the lid was handled. The call count had shipped an hour earlier to explain a different column, and it was under-reporting on precisely the busy sessions it existed to diagnose. We had shipped a column that read a list without asking whether the list was complete.
The fix is both halves. After every report the page clears the list, because it only ever looks at entries inside the window of the load it is reporting, and a till left open all day stops carrying a list it cannot use. And at load the lid is raised to a thousand, for the one window clearing cannot cover: the cold load itself, where the app's own download is inside the number and the split matters most.
One rule holds the change up, and it is now a test: this file must stay the only reader of that list. Clearing is only safe while that is true, and it is the assumption most likely to be broken by somebody adding an honest feature later. The test walks every file under the public folder, counts one reader, and carries a floor so an empty walk cannot pass. Every number on the board before this change is suspect, and the board now says so.