Critical CSS: Inline What Matters and Defer the Rest

A browser will not paint a page until it has downloaded and processed the stylesheets that apply to it. If your main stylesheet is large, visitors stare at a blank screen while it arrives. Critical CSS is the technique of putting only the styles needed for the first screen directly in the HTML, and loading the rest of the stylesheet without blocking the first paint.

This guide explains what critical CSS is, how to decide whether you need it at all, and how to do it in a way you can maintain. It is for site owners and developers who have seen Lighthouse report render-blocking stylesheets and who can edit a page template or a build step. You will finish with an inlined style block for your key templates, a non-blocking load of the remaining CSS, and a test routine for catching the flash of unstyled content that a mistake produces.

Be warned that both web.dev articles on the subject call this an advanced technique that can cause bugs when implemented badly, and say most sites can reach their performance targets without it. Treat it as a last step after the simpler fixes, not a first one.

Before you begin

You need access to the template that outputs the <head> of your pages, or to the build system that produces your CSS. Back up the templates you will change. Know which page types matter most: a home page, an article, a product page. Critical CSS is per template, not per site.

You also need a baseline. Run Lighthouse a few times on each key template and note First Contentful Paint and whether "render-blocking" items are listed. Without a before measurement you cannot tell whether the change helped. Allow half a day for a first template and more for a site with many layouts.

Before you start, try the cheaper fixes: remove unused CSS, minify, compress responses and cache the stylesheet. Our guide on removing render-blocking CSS and JavaScript covers the full set, and improving Lighthouse performance puts them in order.

Why CSS blocks rendering and what Lighthouse looks for

web.dev explains that CSS is a render-blocking resource by default: the browser does not render processed content until it has built the CSS object model, because both HTML and CSS are needed to build the render tree. A stylesheet that only applies to printing, written as media="print", does not block the first render, though the browser still downloads it at a lower priority.

Lighthouse's "Eliminate render-blocking resources" audit uses simple attribute rules, according to the Chrome documentation. A <link rel="stylesheet"> counts as blocking unless it is disabled or its media attribute does not match the visitor's device. media="all", which is the implicit default, counts as blocking. The audit gives no byte or time threshold; the rules are about attributes. As of Lighthouse 13, that documentation says the audit has moved into the "Render-blocking requests" insight, so the label you see depends on your tool version.

Step-by-step instructions

Step 1: Decide whether critical CSS is worth it

web.dev suggests trying the technique when First Contentful Paint is poor and Lighthouse flags render-blocking resources. It also notes that the more CSS a site has, the greater the potential benefit. If your single stylesheet is small, cached and served from a fast host, you may gain little.

Check these three things on a throttled mobile profile: how long the stylesheet takes to download, how large it is compressed, and how soon first paint occurs after it arrives. If the stylesheet is the visible delay, continue. If the delay is the server response, fix that first. See time to first byte.

What success looks like: You have a written reason for doing it, such as "main.css takes about as long as the whole rest of the page to arrive on mobile", backed by a measurement.

Step 2: Find the styles the first screen needs

There is no fixed definition of "above the fold". web.dev notes there is no universally defined pixel height because devices differ, so tools should cover several screen sizes. The simplest way to see what is used is the DevTools Coverage tool: open the Command Menu, choose "Show Coverage", reload the page, and note which rules are marked as used for the visible content.

For anything beyond a one-off experiment, use a tool. web.dev names Critical (an npm module that extracts, minifies and inlines above-the-fold CSS, with support for several resolutions), criticalCSS (extraction only, with finer control) and Penthouse (which uses Puppeteer and suits sites with many or dynamically injected styles). Run the tool against each key template at a phone width and a desktop width and save the output for each.

Review the output by hand. Check that it includes the header, navigation, hero area, base typography, the layout grid and any @font-face rules you rely on. Your own fonts may need extra thought; see font loading and font-display.

What success looks like: For each template you have a small CSS file containing only what the first screen needs.

Step 3: Keep the inlined block small

Inlining is not free. web.dev warns that inlining a lot of CSS delays the rest of the HTML document, and that inlined styles cannot be cached for reuse on later page loads. Its guidance is to keep the above-the-fold content under 14 KB compressed, tied to how many packets the first round trip can carry, and to use the technique sparingly.

If your extracted block is far larger than that, narrow it. Trim rules for components below the first screen, and split off anything shared by every page that could live in the normal cached stylesheet. A good critical block covers the visible shell, not every component.

What success looks like: The inlined style block is small, readable and limited to the first screen.

Step 4: Inline the critical block and load the rest without blocking

Put the extracted CSS in a <style> element in the <head>, then load the full stylesheet so it does not block the first paint. web.dev gives this pattern:

<head>
  <meta charset="utf-8">
  <title>Example page</title>
  <style>
    /* critical rules for this template */
    body { margin: 0; font-family: system-ui, sans-serif; }
    .site-header { background: #04111e; color: #fff; padding: 1rem; }
    .hero { padding: 2rem 1rem; }
  </style>
  <link rel="preload" href="/css/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>

How it works: rel="preload" with as="style" fetches the file without blocking rendering, and the onload handler turns it into a real stylesheet once it has loaded. Setting this.onload=null stops some browsers from calling the handler again after the rel change. The noscript element covers visitors without JavaScript.

Two cautions from the same article. First, an inline onload handler can be blocked by a Content Security Policy, so test it under your real policy; a small helper such as loadCSS supports CSP. Second, moving the stylesheet link to the bottom of the page does not remove the blocking, because the browser still prioritises the stylesheet.

There is also a simpler option for stylesheets that apply only under certain conditions. Give the link a media attribute with a query that does not match the visitor's device, such as media="print" for a print stylesheet, and the browser will not hold the first render for it. That helps for genuinely conditional CSS, but it is not a way to defer your main stylesheet.

What success looks like: With the Network panel open, main.css is still requested, but the first paint no longer waits for it.

Step 5: Test for a flash of unstyled content

The risk of this technique is a visible jump: the first paint uses only the critical rules, and the full stylesheet then restyles the page. If the critical block is missing a rule, the user sees plain content and then a sudden change.

Test by throttling the network to a slow profile and recording a filmstrip in the Performance panel. Compare the first painted frame with the final one. Layout shifts are the thing to watch: a header that changes height or an image that moves is a signal the critical block is incomplete. Our guide on Cumulative Layout Shift explains how to measure it.

Also test with JavaScript disabled to confirm the noscript fallback works, and in more than one browser.

What success looks like: The first frame looks like the final frame at the same layout, and the page is fully styled with scripts off.

Step 6: Automate it and re-measure

Extraction done by hand goes stale as soon as the design changes. Add the extraction step to your build, so each deploy regenerates the critical block for each template. Re-run Lighthouse on the same templates, with the same throttling, and compare FCP and the render-blocking list with your baseline. Use several runs, since single runs vary.

In web.dev's own demo, FCP fell from 1 second to 0.8 seconds. Treat that as an illustration of the type of change, not a result to expect on your site.

What success looks like: The build regenerates the critical CSS, and your measurements show whether the change helped.

Final verification checklist

You measured the baseline before changing anything.
Each key template has its own small critical CSS block in the <head>.
The inlined block is limited to the first screen and sized sensibly.
The full stylesheet loads without blocking first paint and has a noscript fallback.
A throttled filmstrip shows no visible restyling flash or layout jump.
The page works with JavaScript disabled and under your real Content Security Policy.
Menus, forms and cookie notices still look right after the full CSS arrives.
The extraction runs in your build, not by hand.
You compared before and after on the same throttling profile.

Common mistakes to avoid

Inlining the entire stylesheet. This delays the rest of the HTML and loses caching. Keep the block to the first screen.
Extracting at one screen size. A desktop-only extraction leaves phones unstyled. Run the tool at several widths.
Forgetting the noscript fallback. Visitors without scripts get an unstyled page. Include the fallback link.
Ignoring the Content Security Policy. web.dev warns that an inline onload handler may be blocked. Test with the real policy, and check how it treats the inline <style> block too.
Letting the critical block go stale. After a redesign the inlined rules no longer match. Generate it in the build and re-test after design changes.
Using it as the first fix. Unused CSS, large images and slow servers are often bigger causes of delay. Start with removing render-blocking resources and work in order.
Declaring victory from one Lighthouse run. Lab scores vary. Compare repeated runs and check real-user data when you have it.

Frequently asked questions

Is critical CSS required for good Core Web Vitals?

No. web.dev says most sites can meet their targets without it. It is an optimisation for pages where a large blocking stylesheet is measurably delaying first paint.

How big should the inlined CSS be?

web.dev's guidance is to keep the above-the-fold content under 14 KB compressed, linked to how much data the first network round trip can carry. Treat it as a guide rather than a hard rule, and measure your own pages.

Does critical CSS help search rankings?

It can improve how quickly the first content appears, but no one can promise a ranking change from it. Page speed is one of many things that matter, and relevance and content quality still decide most results.

Should I inline CSS in a CMS or WordPress site?

Many caching and optimisation plugins offer a "critical CSS" feature. If you use one, test every template, forms and logged-in views, because generated rules can miss dynamic components.

Can I inline JavaScript the same way?

The Chrome documentation for the render-blocking audit describes inlining critical scripts and deferring the rest with async or defer. Scripts have ordering and dependency rules, so use the cautions in the render-blocking guide rather than copying the CSS approach.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.