Raw bytes are not the wire

The register's first screen waits on one request: the menu. On one live venue that answer was 177 KB, so we read it field by field. More than half of it — 91 KB — was modifier groups. A dish that asks questions (which taco, which side, which drink) carries the group that asks them, with every option. The same eight groups were asked by 39 of the venue's 60 dishes, and the answer repeated all eight, in full, under every one of the 39.

Sending each group once

The fix is the obvious one. The answer now carries each group once, in a map at the top, and each dish carries the list of group ids it asks. The small client library that every screen calls puts the groups back onto each dish before any screen sees the answer, so the till, the back office and the previews read exactly what they always read. A till that has not yet picked up the new code asks without the flag and gets the old shape; nothing breaks mid-service. Live: 177 KB became 108 KB.

Then we measured the wire

And this is the part worth writing down. Browsers do not receive the file; they receive it compressed, and text that repeats compresses almost to nothing. The old 177 KB answer crossed the wire as 17 KB. The new 108 KB answer crosses as 16 KB. Eight identical groups repeated 39 times cost almost no bytes in transit, because a compressor is very good at exactly that.

The night before, we had described this payload as "half a megabyte to draw a list" — raw bytes, read off a tool that asks for the uncompressed file. The transfer was never that. The change is still right: a phone parses 70 KB less text and holds 70 KB less in memory, and a menu answer that says each thing once is easier to reason about. But it did not buy the seconds the raw number implied, and saying it had would have been a claim about the wire made from a measurement of the disk.

The rule

Before attributing time to a payload, measure the payload the way the browser gets it. A file's size is a fact about the file. The wire has its own.