A board that lists every page, slowest first
We now time every page of the product in the browser that loaded it — the till, the kitchen screen, the guest menu, the public site — and the owner sees them ranked slowest first against a 300 ms budget. What that took, and what the first day of real numbers said.
The instruction was one sentence: keep tracking the load of every single page, and any time it takes over 300 ms, try and reduce it. Not the till. Not the kitchen screen. Every page — the guest's menu on a phone, the marketing site, the setup wizard, every screen of the back office, every view of the register.
The honest way to do that is not a lab. A lab tells you how a page loads on one machine on one connection, and the one machine that matters is the one in a guest's hand on a Saturday at half past seven. So every page now reports itself. When a screen has finished drawing, the browser that drew it posts one number — how long it took, from the moment the person asked for it — to a small endpoint that keeps it. A plain page reports the moment its largest visible thing was painted, which is what a person means by "loaded". A screen inside the app reports the time from the tap to the answer.
What the owner sees
On the dashboard: a table of every page that loaded in the last day, week or month, sorted slowest first. Average, worst, how often it was over budget, how many times it loaded, and which surface it belongs to. Anything averaging over 300 ms is amber. That is the whole design. The list does not need explaining because the top row is the job.
What the first day said
The first rows were not from a guest at all. Nine different marketing pages, one visit each, spread across ten hours, all around a second. Nobody browses a site like that; a search engine rendering it does, and it renders with a real browser that runs our timer like anyone else. Those renders are now kept off the board (the next post). The first human numbers said two things. A first visit to a text-only page took about a second on a real phone, most of it the network. And every screen of the back office was re-asking the server about files it already had — which is a post of its own.
What a lab is still for
Finding the cause. Once the board names a slow page, a browser on a throttled connection shows where the time goes: a stylesheet fetched before anything can paint, a hero image told it was not urgent, a screen waiting on four requests in a row. The board decides what to fix; the lab shows how. And the fix is measured on the board again, in real browsers, because a lab number that says "faster" has not yet met a phone on a train.