Critical CSS

Why It Matters

On a static page this is often the largest single win available, because the stylesheet is usually the only thing standing between the HTML and the first paint. Removing that one blocking request can take several hundred milliseconds off Largest Contentful Paint on a mobile connection, and the HTML grows by a few kilobytes the visitor was going to download anyway. The risk sits on the other side: if the inline set is wrong, the visitor gets a flash of half-styled content and then a jump when the real stylesheet lands, which looks cheap and registers as layout shift as well.

How It Works

Generating it is mechanical — load the page at a chosen width, walk the rendered tree, keep every rule matching something in the first screenful and discard the rest. That output goes inside a style tag in the head. The full stylesheet then loads without blocking, usually through the preload pattern: a link with rel="preload" and as="style", plus an onload that flips rel to stylesheet, and a noscript copy behind it for browsers with scripting off. Because the critical block is inlined it cannot be cached separately from the HTML, so it has to be regenerated whenever the design changes or it quietly goes stale. Keep it small: past roughly 14 kilobytes you are paying the cost on every page load without buying back a round trip.

Real-World Example

Common Mistakes

• ✕Inlining the whole stylesheet — the CSS can no longer be cached on its own, so every visit downloads all of it again inside the HTML
• ✕Generating it once and forgetting it — after a redesign the inline block styles elements that no longer exist and misses the ones that do
• ✕Generating at a desktop viewport — the first screen on a phone needs a different set of rules, and phones are where the delay actually hurts

Related Terms