June 02, 2026
Notes on a faster critical rendering path
Most performance work is not clever. It's removing things the browser has to wait for before it can paint anything at all.
The fastest optimization is always the thing you didn’t ship. Before reaching for lazy-loading, code-splitting, or a CDN, it’s worth asking what’s actually blocking first paint — and most of the time the answer is boring.
Fonts are usually the first suspect
A custom font that isn’t self-hosted means a third-party DNS lookup, a connection, and a round trip before any text can render in that font — and if you didn’t set font-display, the browser may hide the text entirely while it waits. Self-hosting fonts and setting font-display: swap fixes most of this in an afternoon, with no design changes required.
Render-blocking CSS is a budget, not a boolean
A stylesheet isn’t “blocking” or “not blocking” — it’s blocking for however long it takes to download and parse. A 4kb critical stylesheet inlined in the <head>, with everything else loaded async, gets you a meaningfully faster first paint than a single 80kb bundle, even though the total bytes shipped barely changed. The win is entirely about sequencing.
JavaScript you don’t run is free
The cheapest JavaScript is the JavaScript that never reaches the browser. Static-first frameworks that ship zero JS by default and add interactivity only where a component actually needs it — islands, partial hydration, whatever a given framework calls it — aren’t a performance trick so much as a default that matches how most pages actually behave: mostly static, with a few interactive parts.
Measure the thing that matters
Lighthouse scores are a proxy. The number that matters is how long a real visitor, on a real connection, waits before they can read the first sentence of content. If a change doesn’t move that number, it’s not a performance win — it’s a score win, and those aren’t the same thing.