Deferring render blocking CSS is a major component to ensuring your web pages load fast. This is technique is not to be confused with the standard “Google Best Practice of Eliminating Render Blocking CSS in Above the Fold Content”.  It is in fact, a better way to achieve higher PageSpeed scores up to 10 points when effectively implementing the proper mechanisms.

What is Render Blocking CSS

When we talk about “render blocking”, and specifically render blocking CSS, we are referring to those resources — CSS files — that are loaded in the page that cause the web browser to block the rendering of the page until they are loaded.

Those CSS files can be large — in many cases, CSS can account for hundreds of kilobytes of data that must be loaded, in addition to the HTML, before it is rendered.  Thankfully there are solutions to eliminate render-blocking CSS in above-the-fold content and optimize CSS delivery.

The Defacto Solution

The most common solution, to defer the loading of your render blocking CSS, and reduce render-blocking round trips is called loadCSS by Filament Group.  The latest version takes advantage of the not yet fully supported rel=’preload’ attribute that allows for asynchronous loading of CSS.

An example of how your existing stylesheet reference might look:

<link rel="stylesheet" href="path/to/stylesheet.css" type="text/css">

An example of how the HTML would be formatted with loadCSS:

<link rel="preloadhref="path/to/mystylesheet.cssas="styleonload="this.onload=null;this.rel='stylesheet'"><noscript><link rel="stylesheet" href="path/to/stylesheet.css"></noscript>

And then you would need to add the loadCSS rel=’preload’ polyfill script immediately after your stylesheet references, preferably within the <head>…</head> region of your pages.

This needs to be repeated for every page on your website.

The Achilles Heel

If you can picture this: the page loads, and then a second or two later, the CSS that was once render blocking itself loads.

But for a brief period of time, you experience what is called the Flash of Unstyled Content (FOUC).  This is where the unstyled page is displayed, black text on white background.  And then POP, parts of the page start styling.

It can be jarring.

That Face When you See the Flash of Unstyled Content | Render Blocking CSS

And Google looks on this as a penalty as you’re not prioritizing visible content.

How to Solve the Flash of Unstyled Content

Solving the flash of unstyled content is enough for another article altogether.   But the short explanation is that you need to inject the “Critical Path CSS” (all the CSS that is required for the rendering of any content that is visible “above the fold” upon initial page load) into the <head>…</head> region of the page.

You can use our handy Critical Path CSS Generator to get this done right away.

An example of how this might look:

<html>
<head><style>/* your critical path css */</style><link rel='preload' href='/path/to/stylesheet.css' as='style' onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="path/to/stylesheet.css"></noscript>
</head>
<body>
<!-- your html -->
</body>
</html>

It is important to put your critical path CSS BEFORE any stylesheet references in the event that there are styles in those stylesheets that render parts of the page below the fold, that must override the critical path styles.  Because the styles are loaded into the document in sequential order, if the critical path inline style were to be added after the <link> tag, some styles in the loaded stylesheet may not take precedence.

Remember, the point of inlining the Critical Path CSS is to get the visible region of the page to load without the flash of unstyled content.  After that is accomplished, the original styles from the stylesheets should take precedence over how the page is rendered.

You need to repeat this for every page in your site.

Since we know all too well how challenging this process can be for even experienced developers, we’ve made extracting CPSS from your pages as simple as possible with our handy online tool.  Keep in mind that this is only half of the work, you still need to enter the extracted CSS into your pages.

An Automated Solution

If you’re running a website that is 2-10 pages, it is probably do-able to manually apply these changes to each of your pages.

If you’re like me, though, and more important things to do with my time, there are two options to automate these fixes:

Automated Google PageSpeed for WordPress

If you’re running WordPress, you can use the Pegasaas Accelerator WordPress plugin.  It automatically optimizes the entire site for Google PageSpeed, including deferring the render blocking CSS, and automatically detecting and injecting the critical CSS.  It also automatically optimizes images, defers render blocking javascript, minifies HTML, CSS, and Javascript, plus a bunch of other very handy automation.

Automated Google PageSpeed for Traditional Websites

If you’re running a traditional website with static HTML pages, and manually going through each one and correcting the render blocking CSS is more than you’re up for, you can use the Numo Accelerator website plugin.  Much like the Pegasaas Accelerator plugin for WordPress, Numo Accelerator also automatically detects and injects the critical path CSS, defers your render blocking CSS and Javascript, optimizes images, plus a number of other automated techniques that will save your hours and hours of time.

Speeding up a website with Minification