Eleven seconds to under three: the register got its own page
A phone opened our register cold and waited 11.8 seconds — for a back office it would never use. The till now has its own page, a third the size, and the first real phone measured 2.8 seconds cold and 15 milliseconds for the screen after. Why the board now separates the two.
The number that started it was on our own load-time board: a phone opened the register cold and the first screen took 11,767 ms. The next screen, a tap later, took nine. Nothing about the register was slow. What was slow was the page it lived in.
The register had always been one route inside the back-office app — the same page as the reports, the rota, the stock counts and a hundred other screens. To draw one row of tiles, a phone had to download all of it: 138 scripts, one and a quarter megabytes compressed. On a counter with wifi that is a few seconds. On a phone in an apron pocket, on whatever signal a market building allows, it was twelve.
A page of its own
So the register now has its own page. Not a second copy of the code — a page generated from the same source at build time, carrying only what the till references: 70 scripts, 469 KB. Pressing Register in the back office takes you to it; logging out of it takes you back. The kitchen screen and every venue's own till address serve the same page. A test fails the build if the generated page ever drifts from the code it was cut from, because a copy that can drift is a second product.
The first cut shipped a page that threw before it started — one declaration the generator did not know how to copy. No test saw it; a real browser driving the real page did, in under a minute. That is now part of the rule: after any change to a shell, drive the actual page.
What the first real phone said
Two nights later a phone opened the new page cold: 2,846 ms. The screen after it: 15 ms. That is the same act, the same kind of connection, four times faster — and it also says where the remaining time is. Not in the screen. In the download of the app itself and the first two round trips it makes.
Two numbers, not one
Which exposed a fault in the board. It had been averaging a cold first screen — download included — together with every later click, so a slow app and a slow screen looked identical, and they are different decisions: one is a route to make parallel, the other is a shell to slim. Every page view now says which it was, and the board shows First load and After that side by side. A slow first load with a fast repeat is the app's own weight. A slow repeat is the screen's. You fix them in different places, so you need to be told which one you are looking at.