Critical CSS is the small set of style rules needed to display the part of a page visible before anyone scrolls. It is placed directly in the HTML so the browser can draw that first screen straight away, while the rest of the stylesheet loads in the background.
How critical CSS works
By default, a stylesheet linked in the head of a page is render-blocking: the browser will not paint anything until it has downloaded and processed that file. On a typical WordPress theme with several plugins, the combined CSS can be large, and most of it styles things far down the page or on other pages entirely.
The critical CSS technique handles this in three steps:
- Extract. A tool loads each page template at a set screen size, records which rules apply to the content in the first viewport, and outputs just those rules. This is usually a few kilobytes.
- Inline. Those rules go into a style block in the HTML head, so they arrive with the document itself.
- Defer the rest. The full stylesheet is loaded in a way that does not block rendering, for example with a preload link that switches to a stylesheet once it has downloaded.
The result is that the browser can paint the header, hero and opening text as soon as the HTML arrives, rather than waiting for a separate file.
Why it matters
Render-blocking CSS is one of the most common causes of a slow First Contentful Paint and a slow Largest Contentful Paint, especially for mobile visitors on slower connections. Getting the first screen up quickly reassures visitors that the page is working, and LCP is one of the Core Web Vitals Google uses as a page experience signal.
For a business whose visitors arrive on phones, such as a café in Brighton or a locksmith covering south London, the first screen often decides whether someone stays. A visible headline, phone number and booking button within the first second or so is worth more than any amount of content further down.
That said, critical CSS is an optimisation for sites where CSS is the bottleneck. If the delay comes from a slow server, a huge hero image or heavy JavaScript, inlining styles will barely move the numbers.
Common mistakes
- Generating it once and forgetting it. When the design changes, stale critical CSS styles the first screen wrongly, and the page visibly changes once the full stylesheet arrives.
- Using one set of critical CSS for every template. A product page and a blog post have different first screens.
- Inlining too much. Putting the whole stylesheet inline bloats every HTML response and cannot be cached separately.
- Creating layout shift. If the inline rules miss something, elements jump when the full CSS loads, which harms Cumulative Layout Shift.
- Testing only on desktop. Mobile and desktop viewports need different critical rules.
How to act on it
Run your key templates through PageSpeed Insights or Lighthouse. If the render-blocking requests finding lists stylesheets with a meaningful potential saving, critical CSS is worth considering. On WordPress, performance plugins such as WP Rocket, LiteSpeed Cache and Autoptimize can generate it per template; custom builds can use tools such as the open-source critical package in the build process.
After switching it on, test on a real phone and on a throttled connection: watch for flashes of unstyled content or jumps, and compare field data in Search Console over the following weeks. Reduce the overall CSS too, by removing unused rules and applying minification. Deciding whether critical CSS is the right fix, or whether the time belongs elsewhere, is part of my technical SEO work.