12 Jun 26 
Critical CSS is the minimal set of styles needed to render everything above the fold. Inline it, defer the rest, and the first paint arrives far sooner. Here is how to extract it, ship it, and avoid the common traps.
Web Performance
When someone lands on a page, the browser cannot paint a single pixel until it has downloaded and parsed every stylesheet in the head. That is the rule most teams forget. Critical CSS is our answer: the small slice of styles needed to render what a visitor sees first, inlined into the page so the first screen appears while the rest of the CSS is still loading. It is one of the most reliable perceived speed wins I know, and easy to get wrong.
What Critical CSS Actually Is
Critical CSS is not a special dialect or a plugin. It is the minimal set of rules required to style the content above the fold: the header, the hero, the first block of text. Everything below that, the footer, a modal that has not opened yet, is non-critical and can wait.
The idea sits on a simple mechanism. A normal external stylesheet is render blocking. The browser sees the link tag, pauses rendering, fetches the file, parses it, and only then paints. On a slow connection that is a visible delay before anything appears. By inlining the critical rules in a style tag in the head, we remove that round trip and paint at once.
Inline the Critical, Defer the Rest
The pattern has two halves. First, put the critical rules inline in the head. Second, load the full stylesheet in a way that does not block rendering. The common technique is a link with a media attribute that flips to all once it loads, which lets the browser fetch it at a lower priority without holding up the paint.
The deferred stylesheet then applies the complete styling once it arrives, including the parts that were briefly unstyled below the fold. If you are already using resource hints to control what loads and when, it slots into the same discipline: fetch what is urgent now, everything else in order of need.
Extracting It Without Losing Your Mind
For a simple, stable page you can extract critical CSS by hand. Look at what renders on first view, copy those rules, and inline them. It is tedious but honest. For a marketing site with a few templates, that is often all you need.
For complex applications with many components and states, hand extraction does not scale. Tools that render the page at your target viewports and compute which rules are used above the fold generate the critical set for you as part of the build. The trade off is a build step you have to maintain and trust, so we reach for it only when the page count or the component churn makes manual work impractical.
The Pitfalls, and When to Skip It
The biggest trap is staleness. Critical CSS is a snapshot. Redesign the hero, change a font, and the inlined styles no longer match, so we regenerate it in the build rather than pasting it once and forgetting. Over inlining is the opposite failure: cram too much in and the HTML balloons, slowing the first response you were trying to speed up. Keep it to the first screen, or you invite a flash of unstyled content as the deferred sheet reshuffles things.
Done well, this improves your Largest Contentful Paint, because the element that defines LCP renders without waiting on a blocking file, often the missing piece when you are chasing down a failing LCP score. Still, be honest about the cost. On a small site served fast with one lean stylesheet, the complexity may not be worth it. Critical CSS shines on content heavy pages, slower networks, and templates that stay stable enough to justify the upkeep. Treat it like any optimisation: measure first, and fold it into a wider performance budget that keeps the whole site fast rather than chasing a single number. The same care applies to images and scripts, which I cover in loading below the fold the right way.