Deferring render blocking CSS is a major component to ensuring your web pages load fast. By effectively implementing the proper mechanisms, you can improve your PageSpeed score by up to 10 points.
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:
An example of how the HTML would be formatted with loadCSS:
<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="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.
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.
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.
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
Automated Google PageSpeed for Traditional Websites