Critical CSS is an important tool in a web developer’s arsenal to reduce the time it takes to load a page.
What is Critical CSS?
When a browser renders a page, it takes the HTML and the CSS, parses them both, and sorts out the layout. This can’t be done until “all” of the CSS is received. However, people can only view a part of the web page at a time. The CSS used to render the part of a page that people see when it firsts loads is considered the Critical CSS.
How does Critical CSS work?
If you can include the Critical CSS in the HTML of the web page and defer the loading of all of the other CSS then you can make the page load faster because there is less initial CSS for the browser to download and parse, plus there is no additional CSS network request overhead.
Considerations for Critical CSS
This is a high-level view of considerations for implementing Critical CSS. We will dig into these topics and specific implementation details related to WordPress in future articles in the series.
For First-time Visitors
When implemented properly, the Critical CSS should only be served to first-time visitors. Subsequent visitors will have the full CSS cached and there is no reason to include the Critical CSS in the HTML payload.
Multiple Critical CSS Snippets
In a moderately complicated website, different pages will have different Critical CSS – but it is resource-prohibitive to generate Critical CSS for every page on your site. It is a good idea to identify a range of pages that are key entry points for your site visitors and generate Critical CSS for those pages. I recommend one of two aproaches for determinining which pages to generate Critical CSS for:
- Review analytics to determine the top 5 or 10 pages that visitors enter your site through
- Identify several “high-profile” pages on the site
Please note, 1 can break down if you have many long-tail search pages. In that case it is best to try to identify a representative page that encapsulates the styling for all of the others and use that to generate the Critical CSS for the entire set.
Cached CSS Cookie
It is important for the server-side code to know when a browser has cached the full CSS. You can use a cookie for this since cookies are shared by the browser and the server. If the cached CSS cookie is set then don’t inline the Critical CSS.
Additionally, you should use a version number (or file hash) as the value for your cached CSS cookie. This makes it easy to deliver new Critical CSS and force the browser cache to load new CSS when it changes. Also, the lifetime of this cookie should match the expires value of your CSS files in your server’s configuration.
Cookies and the Reverse Cache Proxy
As noted above, the Reverse Cache Proxy is a key piece of your architecture to reduce load on your backend infrastructure by saving the output of a URL. However, with the cached CSS cookie, the same URL could generate different HTML depending on if the cached CSS cookie is set or what value it is set to.
To avoid serving pages without Critical CSS to new visitors (and pages with Critical CSS to returning visitors) the cached CSS cookie needs to be included as a part of the key for finding cached responses.
Load Full CSS Asynchronously
The full CSS still needs to be loaded, just asynchronously. It is critical that the full CSS be loaded and cached so that future visits can leverage this cached CSS.
This is a performance technique for HTTP/1. If you are using HTTP/2 then there is likely to be less benefit from using Critical CSS. We will discuss HTTP/2 in the last article of the series Considerations for the Future of Critical CSS in WordPress.