Defer non-critical CSS

Demian Renzulli
Demian Renzulli

CSS files are render-blocking resources: they must be loaded and processed before the browser renders the page. Web pages that contain unnecessarily large styles take longer to render, increasing the likelihood that users bounce: 53% of mobile visits bounce if the page does not load in 3 seconds or less.

In this guide, you’ll learn how to defer non-critical CSS with the goal of optimizing the Critical Rendering Path, and improving FCP (First Contentful Paint).

Loading CSS in a suboptimal way

The following example contains an accordion with three hidden paragraphs of text, each of which is styled with a different class:

This page requests a CSS file with eight classes, but not all of them are necessary to render the "visible" content.

The goal of this guide is to optimize this page, so only the critical styles are loaded synchronously, while the rest (like the ones applied to paragraphs), are loaded in a non-blocking way.

Measure

Run Lighthouse on the page and go to the Performance section.

The report shows the First Contentful Paint metric with a value of "1s", and the opportunity Eliminate render-blocking resources, pointing to the style.css file:

Lighthouse report for unoptimized page, showing FCP of '1s' and 'Eliminate blocking resources' under 'Opportunities'

The CSS we are using for this demo site is quite small. If you were requesting larger CSS files (which are not uncommon in production scenarios), and if Lighthouse detects that a page has, at least, 2048 bytes of CSS rules that weren't used while rendering the above the fold content, you'll also receive a suggestion called Remove Unused CSS.

To visualize how this CSS blocks rendering:

  1. Open the page in Chrome.
  2. Press Control+Shift+J or Cmd+Option+J (Mac), to open DevTools.
  3. Go to the Performance tab and click on the Reload button.

In the resulting trace, you’ll see that the FCP marker is placed immediately after the CSS finishes loading:

DevTools performance trace for unoptimized page, showing FCP starting after CSS loads.

This means that the browser needs to wait for all CSS to load and get processed before painting a single pixel on the screen.

Optimize

To optimize this page, you need to know which classes are considered “critical”. You'll use the the Coverage Tool for that:

  1. In DevTools, open the Command Menu, by pressing Control+Shift+P or Command+Shift+P (Mac).
  2. Type "Coverage" and select Show Coverage.
  3. Click the Reload button, to reload the page and start capturing the coverage.
Coverage for CSS file, showing 55.9% unused bytes.

Double-click on the report, to see classes marked in two colors:

  • Green (critical): These are the classes the browser needs to render the visible content (like the title, subtitle, and accordion buttons).
  • Red (non-critical): These styles apply to content that's not immediately visible (like the paragraphs inside the accordions).

With this information, optimize your CSS so that the browser starts processing critical styles immediately after page loads, while deferring non-critical CSS for later:

  • Extract the class definitions marked with green in the report obtained from the coverage tool, and put those classes inside a <style> block at the head of the page:
<style type="text/css">
.accordion-btn {background-color: #ADD8E6;color: #444;cursor: pointer;padding: 18px;width: 100%;border: none;text-align: left;outline: none;font-size: 15px;transition: 0.4s;}.container {padding: 0 18px;display: none;background-color: white;overflow: hidden;}h1 {word-spacing: 5px;color: blue;font-weight: bold;text-align: center;}
</style>
  • Then, load the rest of the classes asynchronously, by applying the following pattern:
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

This is not the standard way of loading CSS. Here's how it works:

  • link rel="preload" as="style" requests the stylesheet asynchronously. You can learn more about preload in the Preload critical assets guide.
  • The onload attribute in the link allows the CSS to be processed when it finishes loading.
  • "nulling" the onload handler once it is used helps some browsers avoid re-calling the handler upon switching the rel attribute.
  • The reference to the stylesheet inside of a noscript element works as a fallback for browsers that don’t execute JavaScript.

The resulting page looks exactly like the previous version, even when most styles load asynchronously. Here's how the inlined styles and asynchronous request to the CSS file look like in the HTML file:

Monitor

Use DevTools to run another Performance trace on the optimized page.

The FCP marker appears before the page requests the CSS, which means the browser doesn’t need to wait for the CSS to load before rendering the page:

DevTools performance trace for unoptimized page, showing FCP starting before CSS loads.

As a final step, run Lighthouse on the optimized page.

In the report you’ll see that the FCP page has been reduced by 0.2s (a 20% improvement!):

Lighthouse report, showing an FCP value of '0.8s'.

The Eliminate render-blocking resources suggestion is no longer under Opportunities, and now belongs to the Passed Audits section:

Lighthouse report, showing 'Eliminate blocing resources' on the 'Passed Audits' section.

Next steps & references

In this guide, you used vanilla code to implement this optimization. In a real production scenario, it’s a good practice to use functions like loadCSS, that can encapsulate this behavior and work well across browsers. As a complement to this, the extract critical CSS guide covers some of the most popular tools to extract critical CSS and includes a codelab to see how they work in practice.

Last updated: Improve article