Byte Ledger is the audit methodology I built for the WordPress performance work that comes through the high-end practice. The format is borrowed from accounting because the discipline is the same: every byte the browser downloaded is a line item, and every line item has to justify itself.
A byte ledger for a single surface contains four columns of data:
- **Decoded bytes** — what the browser actually parses, after decompression.
- **Compressed bytes** — what came across the wire (Brotli where available, gzip as fallback).
- **Request count** — how many round-trips it cost to assemble the page.
- **First-14-KB-budget check** — whether the resource fits inside the initial TCP slow-start window where [lcp-largest-contentful-paint](/glossary/lcp-largest-contentful-paint/) is won or lost.
Below those columns, the ledger carries one more thing each row: a refusal. A line that ships 84 KB of block-library CSS to a surface using none of it doesn't get a recommendation — it gets a refusal that names the waste and routes to the agent who fixes it (the WordPress-architecture agent dequeues, the CSS agent rebuilds the per-surface bundle, the theme agent moves the enqueue to the right hook). The audit doesn't end with "you should look into this." It ends with named work.
Inside a byte ledger sit measurements that don't live anywhere else: [class-token-coverage](/glossary/class-token-coverage/) on every stylesheet, [render-blocking](/glossary/render-blocking/)-resource count in the head, decoded-to-compressed ratio (the signal for poor compression configuration), inline-vs-external split on the critical path. The ledger is how I produce a performance audit deliverable that reads at the senior-practitioner bar — every claim sized, every fix routed, no PageSpeed-Insights-screenshot theatre.