Performance and efficiency, measured

You'll be able to: report a latency figure so someone else can check it; recognise when your own measurement method is the thing producing the result; and decide what to optimise from evidence rather than instinct.

How these numbers were taken

The latency and origin figures were measured against the live deployment on 2026-07-18 from a single client in Western Europe, twelve samples per figure, reporting median with min and max.

That last part is the important caveat: one vantage point is not a global latency profile. A reader in Sydney will see different numbers, dominated by physics I cannot measure from here. Where this chapter says "48 ms", it means "48 ms from one place, on one day" — not a service-level objective.

The page-weight figures come from a different instrument on a later date: the CI budget gate, run against a production-shaped serve. Where a number's provenance differs from the rest of the chapter, this text says so next to the number rather than in a footnote — because a table that mixes two measurement methods without labelling them is how a plausible chapter becomes a wrong one.

Latency

So the edge cache is worth roughly 4× on content reads, and — more importantly — it removes the long tail. The cached path's worst sample was 133 ms; the origin path's worst was 403 ms, and that variance is a home network with a domestic uplink behaving exactly as one should expect.

The cf-cache-status header distinguishes the two, and it is the reason the cache rule is verifiable rather than assumed.

Caching policy

The stale-while-revalidate window is the part that most changes how the site feels. Within it, a reader whose cached copy has just expired gets the stale copy instantly while the refresh happens behind them. Nobody waits for revalidation; the cost is that someone might see a version up to a minute old.

What the browser downloads

This is the figure that changed most, and the way it changed is more interesting than the number.

The measurement above was taken while the reader was a WebAssembly application: a ~630 KiB critical path, 96% of it one wasm module, against a 700 KiB budget. Every page paid all of it, and paid it before rendering any prose — measured at 1.25 s to readable content on broadband and 7.2 s on a mid-range phone over Fast-3G.

Server rendering does not make that bundle smaller. It removes the question, because there is no longer one bundle: each page ships only its own assets, and the prose is in the HTML.

Measured against the live deployment before and after — median of three runs, the mobile figures throttled to Fast-3G with a 4× CPU penalty:

The delivered 2.4× and 3.9× land slightly under the 3×/5× the change was modelled to produce, and that is worth stating rather than rounding up: the model was an upper bound, as models of this kind usually are. The structural line is the one that matters most anyway — time to content stopped being a function of how fast a bundle boots, so it is no longer a number that can quietly regress by a dependency getting heavier.

Two things about that table are worth more than the numbers.

The measurement method had to change with the architecture. "Sum the entry chunk" is meaningless now. The gate fetches each page kind from a production-shaped serve, collects every script and stylesheet its HTML references, and gzip-sums them — so it measures what a reader waits for, which is what the old number was a proxy for.

The lazy half is absent by construction. Monaco, keycloak-js, mermaid, d2, the tracers and the visualiser are dynamic imports, so they cannot appear in a page's HTML and cannot land in the sum. No exclusion list has to be maintained, and no future dependency can sneak into the critical path by being forgotten in a glob.

The budget is a CI gate, and its headroom is deliberate — about five times the heaviest page. It is not sized to be tight; it is sized so that approaching it means something structural regressed, in which case the fix is to find the island that went eager rather than to raise the number.

The origin is nearly idle

That last row is measured, not estimated — the load test and the capacity arithmetic it supports are in Scaling and maintainability. The short version: the application is about ten times faster than the network it speaks through, so the origin's throughput has never been the thing worth optimising.

The application is not the bottleneck and is not close to being one. At ~99% cache-hit-eligible traffic, the origin only sees cache misses, revalidations and the small volume of runs and writes.

This is the payoff from the architecture chapter's traffic table: reads were designed to be derived, cacheable data, so the origin's job at scale is mostly not answering.

The one real performance bug, and how it was found

The most user-visible performance problem was not throughput. It was that a lesson with several diagrams rendered nothing — blank page, then everything at once, seconds later.

The cause was ordering, not slowness: diagrams were rendered during markdown parsing, sequentially, inside the promise the page waited on. So the slowest diagram's layout gated the first paint of the entire page, including prose that had been ready immediately.

The fix was to change when, not how fast: parsing now emits a placeholder holding the diagram source, and rendering happens at mount, near the viewport. Prose paints at once; diagrams fill in independently and concurrently; below-the-fold diagrams do not render until approached; the heavy engines load only if the page uses them.

The lesson generalises past this codebase. The parse loop was never the slow part — the dependency order was. A profiler would have shown time inside diagram layout, which is true and useless; the question that mattered was why is prose waiting for this at all? Optimising the layout engine would have made a blank page appear slightly sooner.

What is deliberately not optimised

• The database. Six small tables, one index per query that needs one, and no query that is not either a primary-key lookup or a two-column index scan. Tuning it would be optimising a component that is not in any critical path.
• The judge. It runs someone else's code; its duration is set by that code. The design goal was never to make judging fast — it was to stop judging from blocking anything else, which is what the 202-and-poll shape achieves.
• Compile times. Genuinely annoying, entirely a development cost, invisible to readers.

Each of those is a place where effort would produce a number that improves and an experience that does not.