Critical CSS is the minimal set of style rules a browser needs to render everything
visible in the first viewport, the “above-the-fold” screen. Instead of making the browser
download an external stylesheet before it can paint, that slice is written directly into a
<style> block in the HTML, so the first paint happens on the very first network response.
Why the technique exists
A normal <link rel="stylesheet"> is render-blocking: the browser refuses to paint
anything until it has fetched and parsed the whole file. On a throttled mobile connection
that single round-trip can cost a second or more, and most of the CSS in it styles content the
visitor cannot see yet: the footer, a modal, pages they may never scroll to.
Critical CSS breaks that trade-off. The handful of rules for the header, hero and first section travel inside the HTML, so the first screen paints immediately. The full stylesheet still loads, asynchronously and off the critical path, to style everything below.
How often it is actually the binding constraint
Critical CSS is the most cited fix in the genre, which made our own numbers a surprise. Across our audit base (snapshot 2026-07-23), the filter that extracts and inlines critical CSS found work worth doing on 9 of 57 WordPress sites, 3 of 32 Webflow sites, and 6 of the 195 sites in our largest engine bucket. That is a small minority in every group.
The technique that fired constantly was its unglamorous neighbour: inlining small stylesheets that cost a round-trip each rather than extracting a critical slice from a big one. That applied to all 37 Squarespace sites, 32 of 39 Tilda sites and 22 of 30 Bitrix sites.
Where inlining stops paying
- It bloats the HTML. The CSS now ships on every page load instead of being cached once. Inline too much and you inflate the first response, nudging TTFB and total transfer up far enough to cancel the win.
- It goes stale. If the inlined rules are generated once and the design changes, the first paint flashes the wrong styles before the real stylesheet arrives.
- The boundary is hard to draw by hand. Too little and the first screen renders unstyled; too much and you are shipping a full stylesheet inline.
The discipline that keeps it honest is a byte budget: inline only what the first screen needs, and keep the HTML lean enough that the saved round-trip is still worth more than the added bytes.
Where WebSpeed draws the line
WebSpeed extracts and inlines critical CSS automatically, up to a byte budget, then loads the rest of the stylesheet asynchronously so it no longer blocks the paint. Because the budget is enforced per request, the first screen paints on the first response without the HTML ballooning. On the many pages where no clean critical slice exists, we take the round-trips out instead and leave the stylesheet alone.