An Introduction to Critical CSS in WordPress

A major goal of web site maintainers should be to reduce the amount of time a visitor is required to wait before they can see the content. The longer a page takes to load and display, the more likely that the visitor will simply click away to another site.

Critical CSS is an important tool in a web developer’s arsenal to reduce the time it takes to load a page.

A Primer on Performance

There are three main focuses for performance of a web site:

Generate the page resources for the browser faster – backend
Get the page resources to the browser faster – network
Get the browser to render the page faster – frontend

Backend

The performance improvements in the backend can include database improvements, code tuning, and object or opcode caching.

Network

The performance improvements in the “network” layer are usually comprised of a reverse cache proxy (such as Varnish or Nginx) and a CDN.

Frontend

The performance improvements in the frontend layer are more nuanced, but they can be summarized by the rule “reduce browser blocks” – get resources to the browser at the right time.

Unless you have a very dynamic (frequent content changes including visitor-specific content) site, most basic websites will get the biggest benefit by improving the network layer. This can help mitigate issues with slow page generation (via the reverse cache proxy) and high latency for global content delivery (CDN). However there are still things that can be done to help the browser render the page faster.

Critical CSS is one of these things.

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.

HTTP/1

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.