Why almost every page here ships zero JavaScript

This site is also a test bed. We are building a system that will make changes to it and measure whether those changes caused growth. That only works if the measurements are clean — and page speed is one of the loudest confounders in search performance data.

So the constraint came first: a content page ships no client-side JavaScript unless something on it genuinely needs to run in a browser.

What that costs

Less than expected. Navigation, layout, typography and content rendering all happen at build time. Measured on 1 September 2026, every page on this site except the home page references no script at all.

The one exception, and what it costs

The home page has an animated introduction, and it is worth being precise about its price rather than rounding it to zero. What that page loads up front is a 2.7 KB gate. The gate decides whether the animation is worth running — it is skipped on phones, on machines reporting fewer than four cores, under prefers-reduced-motion, when the browser reports a data saver, when WebGL is missing, and on every visit after the first in a session.

Only if all of those pass does anything heavy get fetched: the 3D library, the scene and the glyph outlines, as separate chunks, after the page has painted. The wordmark, tagline and link are real HTML and are complete with JavaScript disabled entirely.

That distinction — what the page ships versus what it may later choose to fetch — is the whole budget. An enhancement that can decline to load is not the same cost as a library in the critical path, and reporting them as the same number is how performance budgets quietly stop meaning anything.

Why it matters for measurement

If a page is slow, a drop in rankings has at least two plausible explanations, and separating them costs weeks of data. Removing the variable up front is cheaper than controlling for it later.