The till was downloading the back office
One stylesheet for the whole product means the register waits for rules about screens it has no route to. Splitting it took 112 KB off the till opening cold — measured over the wire, not in a lab.
A register has one screen. Tiles, a keypad, a payment sheet, a kitchen view. Tap anything that leaves that screen and you have left the page entirely.
Our stylesheet did not know that. It was one file for the whole product — 574 KB of rules, 147 KB gzipped, covering every back-office report, every settings panel, every chart. The till downloaded all of it before it could draw a single tile.
How much of it could the till even use?
We counted. Of 4,099 rules in that file, the register's page can match 1,471. The other two thirds describe screens the till has no route to. A phone at a counter was waiting on styling for a purchase-order form it will never open.
So the build now writes the register its own stylesheet: the same rules in the same order, minus the ones nothing on that page can match. Measured on the live site, over the wire, both files, like for like:
brotli 154,238 -> 39,526 bytes saved 114,712 (74.4%) gzip 150,799 -> 36,784 bytes saved 114,015 (75.6%)
A real browser takes the brotli copy, so 112 KB comes off the till's cold load. That is the load that matters: a new device, a phone that cleared its cache, the tablet somebody set up this morning. A till that is already warm was never the problem.
Which way we let it be wrong
Deciding what to drop is a judgement with two possible mistakes, and they are not the same size. Keeping a rule nothing uses costs a few bytes nobody notices. Dropping a rule something does use breaks a till at a counter during service.
So the rule we wrote is deliberately generous: a rule stays if every class it names appears anywhere in the till's own source — the page plus every script that page loads, read back out of the page itself so the stylesheet and the script tags cannot disagree about what the till is. That keeps rules that are probably dead. Fine. The 112 KB is already there.
Why this is worth an operator's attention
Not because of the number. Because of the shape. Front-of-house software grows by having more screens added to it, and the cost of every new screen is usually paid by every other screen quietly, at open, on the slowest connection in the building.
If your supplier ships one bundle for the whole product, the question to ask is not "how fast is the till" but "what is the till waiting for that it cannot use". Ours was waiting for the back office.