Fast on the edge, with the receipt

• Payload

  How many bytes have to arrive before the page is usable — the HTML, its stylesheet, and any JavaScript it loads, plus whatever images and fonts ride along with it.

• Request count

  Every separate file the browser fetches is its own round trip. A page built from one HTML file and a dozen small extras is slower than one built from a handful of larger ones.

• Cache miss

  The first visitor to ask for a file pays for fetching it from wherever it actually lives. Whether the next visitor pays that cost again depends on whether anything kept a copy closer by.

• Distance

  How far a request has to travel to reach a server that can answer it, and back. A visitor a continent away from a single server feels every one of those extra milliseconds.

Fonts aren't in the table above — a font file is loaded from inside a stylesheet, not a page, and only the weights and characters a given page actually uses. Counted once site-wide instead of per route: 33 font files, 483.0 KB total, fetched once and cached for every page after.

The ceilingEvery route is held to 60.0 KB of page weight, 8.0 KB of JavaScript, and 12 requests — comfortably above today's worst measured route. The build fails if any route crosses one of those three ceilings, or if a third-party host shows up anywhere on the site that isn't on the short, named allowlist behind the row above — today, that's our own analytics tag and nothing else.

Measured 2026-08-27 from a build of commit 08d2f9e.

• Static sites

  Every file is built once and handed to the edge cache, so almost no request ever reaches a single origin server — most visitors are answered by whichever cache node is nearest them. Filenames change when the content does, so a cached copy is never stale, and every response is compressed before it leaves.

• Dedicated instances

  The same edge cache sits in front of static assets even here; what the instance itself answers gets compression and cache headers set deliberately, and the instance is sized to the workload rather than shared with anyone else's spike.

• Anything else we host

  Whatever the shape, it goes through the same pipeline: edge cache in front where a request can be cached at all, compression on what can't, and a box sized for the job rather than guessed at.

1. 1

   An unoptimised image

   A single uncompressed photo can outweigh everything else on a page put together.

   The loop's fix Brief it — "compress the hero image" — and the pull request that resizes and re-encodes it is ready to review.

2. 2

   An embedded third-party tag

   A widget, a tracking pixel, an embed from somewhere else — each one is a request to a server this page's own budget has no say over, and one this site discloses rather than hides (see the row below and /legal/privacy).

   The loop's fix Brief "drop the unused tag" or "add this one, disclosed," and the diff that adds or removes it is reviewed against the same allowlist this page's own budget is held to — nothing third-party ships silently.

3. 3

   A font you added yourself

   Every weight and script you load is a file a visitor has to fetch before that text renders in it.

   The loop's fix Brief which weights actually get used on the page; the pull request drops the rest.

4. 4

   An unbounded query on the homepage

   A dedicated instance is only as fast as the slowest thing it has to compute before it can answer.

   The loop's fix Brief the symptom — "the homepage is slow under load" — and the fix (an index, a limit, a cache) comes back as a reviewable pull request instead of a guess.

• Field Core Web Vitals

  The numbers above are a lab measurement of the build itself — bytes over the wire, not what a real visitor's device and connection actually experienced. We don't run the traffic yet to publish that honestly.

• A time-to-first-byte promise

  How fast a server answers depends on the visitor, the route, and the day — a single promised number would be true for nobody in particular.

• An "N% faster than X" comparison

  That claim needs someone else's site measured the same way, on the same day, under the same load — a comparison we have no honest way to run.

See the same discipline applied to real shipped changes at Case files, and the full run of them at Built in the open.

1. 01Where do these numbers come from?

   A script measures the build that produced this exact page — HTML, CSS, and JavaScript, brotli-compressed, per route — and the committed figures are checked against a fresh build on every deploy. Nothing here is typed in by hand.

2. 02Why brotli, and not the raw file size?

   Because that's what actually crosses the wire to a modern browser — every response here is served compressed, so measuring the uncompressed file would overstate what a visitor's connection has to carry.

3. 03Why aren't fonts counted per page?

   A font file is referenced from inside a stylesheet, not from any one page's HTML, and it's split by unicode range — which files a given visitor's browser actually fetches depends on which characters that page uses. We count the whole set once, site-wide, instead of publishing a per-route number that isn't real.

4. 04What happens if a page goes over budget?

   The build fails. The budget above isn't a description of what we happened to measure — it's a ceiling enforced on every deploy, including this one.

5. 05Does this include my app, if I'm not on a static plan?

   This page measures our own site, which is static. A dedicated instance running your own application has its own performance characteristics — the edge cache, compression, and cache-header discipline in the per-shape rows above apply to it, but the budget itself is specific to what we publish, not a promise about every app anyone hosts here.