Skip to content
Website Speed

Critical CSS Explained: Faster First Paint, Fewer Surprises

Critical CSS lets the first screen paint without waiting for the full stylesheet. How it is generated, the side effects to watch, and why it goes stale after redesigns.

A screen of website performance metrics and charts
7 sections · 7 min read
In this article · 7 sections

You switched on a setting called something like “optimise CSS delivery” or “load CSS asynchronously”. The speed score went up. Then, on your phone, you noticed the home page flash for a moment as plain black text on white before the design snapped in. Or the footer looks right but a section halfway down has lost its background colour. Both are signs of critical CSS at work, either doing its job slightly wrong or going out of date.

Below is critical CSS explained in plain terms: what it is, why the first screen appears sooner with it, how tools generate it, which side effects to look out for, and how to keep it accurate when the design changes.

Critical CSS explained in one idea

A browser will not paint a page until it has downloaded the stylesheets linked in the head. If your theme’s stylesheet is large or slow to arrive, the visitor sees nothing until it does. That is why stylesheets appear in reports among the resources that block rendering.

Critical CSS gets around the wait. A tool works out which style rules are needed to draw the part of the page visible when it first opens, the “above the fold” area, and places those rules directly inside the HTML. The full stylesheet is then loaded in a way that does not block painting. The browser can draw the first screen as soon as the HTML arrives, and the rest of the styles follow a moment later.

It is a sleight of hand, but a legitimate one. The page is not lighter overall. The first view simply stops waiting for files it does not strictly need yet.

What it actually improves

The gain shows up in the early paint measurements: First Contentful Paint, and often Largest Contentful Paint if the largest element is text or sits in the first screen. On a fast connection the difference can be small. On mobile data, where every extra file means another trip to the server, removing the wait for a stylesheet is often noticeable.

What it does not do: make images smaller, speed up the server, or reduce JavaScript. If your largest element is a heavy hero image, the image is still the bottleneck, and the fixes in improving a slow Largest Contentful Paint will matter more.

It is also different from removing unused CSS, though plugins often present the two together. Removing unused CSS cuts rules a page does not use. Critical CSS changes the order in which the needed rules arrive. If you want the first, see trimming CSS your pages never use.

How tools generate critical CSS

You can write it by hand, but nobody sensible does on a WordPress site with dozens of templates. Tools do it roughly like this:

  1. Load the page in a headless browser, a browser with no visible window, at one or more screen sizes.
  2. Note which elements are visible in the first screen at each size.
  3. Collect every style rule that affects those elements, including fonts, colours and layout.
  4. Save that collection and insert it into the head of the page when it is served.
  5. Change the link to the full stylesheet so it loads without blocking.

On WordPress, the common ways to generate critical CSS are through your optimisation plugin. WP Rocket can do it as part of its CSS delivery options. LiteSpeed Cache generates it through its QUIC.cloud service, covered in our notes on configuring LiteSpeed Cache safely. Autoptimize can work with an external critical CSS service. Other performance plugins have their own approach, so check the documentation for the one you use. Developers building a custom theme can generate it as part of their build instead.

Per page or per template

Many tools generate critical CSS per template or post type, not for every single URL. Your blog posts share one set, your service pages another, your home page its own. That is efficient, but it assumes pages of the same type look alike at the top. If one service page has a large coloured banner and the others do not, the shared critical CSS may not include the banner’s styles, and that page will flash.

Good tools let you generate separate sets for mobile and desktop, because the first screen on a phone contains different things from the first screen on a laptop.

The side effects to watch for

Flash of unstyled content

If the critical set is missing something that is visible at the top, that element appears unstyled until the full stylesheet arrives. On a fast connection it is a blink. On a slow one it can last long enough for the visitor to see the bare page. Common culprits: a header that changes on scroll, a cookie notice, a promo bar added after the CSS was generated, or a hero section whose styles come from a page builder’s per-page file.

Layout shift when the rest arrives

If the critical rules give an element one size and the full stylesheet then gives it another, the page jumps. Fonts can do the same if the critical set uses a fallback font with different proportions. That movement counts against Cumulative Layout Shift, which our post on fixing layout shift problems explains.

A heavier HTML file

Critical CSS is placed inside every page, so the HTML grows. It is also not cached separately the way a stylesheet is, so returning visitors download it again with each page. A tight set is fine. A generated set that has ballooned to include most of the theme defeats the purpose.

Clashes with other CSS settings

Critical CSS rarely runs alone. The same plugin may also be minifying, combining or trimming your stylesheets, and the options interact. In some plugins, the unused CSS feature and the critical CSS feature cannot both be active, and the settings screen will grey one out. Where both can run, the order they are applied in matters, and a trimmed stylesheet may no longer contain rules the critical set expected to find later.

If you run two optimisation plugins, or a plugin plus a CDN that also rewrites CSS, the risk climbs quickly. Pick one place to handle CSS delivery and switch the equivalent options off everywhere else.

Keeping it accurate after design changes

This is the part most sites forget. Critical CSS is a snapshot of how the page looked when it was generated. Change the design and the snapshot is wrong.

Regenerate it after:

  • Changing the header, hero section, colours or fonts.
  • Updating the theme or page builder, since class names and CSS files can change.
  • Adding a new template, landing page layout or post type.
  • Adding anything that appears at the top of every page, such as a notice bar.

Most plugins have a button to clear and regenerate it. Some regenerate automatically when you purge the whole cache. If a page that used to load cleanly starts flashing, stale critical CSS is the first thing to suspect.

Is it worth switching on?

Critical CSS is usually worth trying if:

  • Your stylesheets are large and show up as blocking in PageSpeed Insights.
  • Your visitors are mostly on phones and mobile data.
  • Your first screen is mainly text, a heading and a button, rather than one heavy image.

It is less useful if your CSS is already small, if the real delay is server time, or if nobody will remember to regenerate it after the next redesign. In that last case, a stale critical set can make the site look worse than no critical set at all.

To test, use a throttled connection in Chrome DevTools or a filmstrip view in WebPageTest and look at the first frames, not just the final score. You want the first frame that shows content to look like the finished page. Where this step sits among all the other work on a slow site is set out in our guide to making a website faster.

Frequently asked questions

Why does my page look broken for a split second after enabling critical CSS?

The generated critical styles are missing rules for something visible at the top, so it shows unstyled until the full stylesheet arrives. Regenerate the critical CSS, check whether mobile and desktop need separate sets, and if one element keeps flashing, add its styles to the plugin’s critical CSS fallback or custom field.

Do I need critical CSS if I use a lightweight theme?

Often not. Lightweight themes ship small stylesheets that download quickly, so the wait they cause is short and the risk of a flash may not be worth it. Measure First Contentful Paint on mobile first. If it is already good and stylesheets are not flagged as blocking, leave it off.

Does critical CSS work with page builders?

Yes, but with more care. Builders often load a separate CSS file for each page, and the critical set must include rules from it for the top section. Generate per page where your plugin allows it for pages with unusual layouts, and regenerate whenever someone edits the top of a page in the builder.

How often should critical CSS be regenerated?

Whenever the top of any page changes: a new header, hero, fonts or colours, a theme or builder update, or a new template. There is no fixed schedule. Many plugins regenerate when you clear the full cache, but check that yours does and look at key pages on a phone afterwards.

If you are not sure whether critical CSS is helping or hurting your site, our website speed optimisation starts with an audit and a prioritised fix list. CSS delivery is reviewed alongside everything else, nothing goes live until you have said yes, and a re-test at the end shows what actually changed.

Next in this series: Are Google Fonts Slowing Your Website? What to Cut First

Is Your Website Working Properly?

Get a free website health check from WebMaintor. We'll review your website's speed, security, forms, and technical health — and tell you exactly what needs attention.

No obligation. No automated reports. A real review by our team.