The Critical Rendering Path Optimization is the process of minimizing the time spent by the browser to perform each step of the sequence prioritizing the display of content related to the current user action.
Much of this process pertains to the portion of the page that is visible without scrolling down the browser window. That section is also known as Above the Fold. For a better usability, the ATF should be rendered as soon as possible, and this can be done reducing the number of network round trips at a minimum. The resources required to render the ATF are considered critical, and optimizing the Above the Fold means minimizing the impact of critical resources on the time to first render of the page.
In this post, we will walk through the Critical Rendering Path optimization sequence.
Here is the sequence of steps performed by the browser to render a page:
As well explained in Google’s Critical Rendering Path Optimization guide, the browser builds the Document Object Model in a four step sequence:
What is important to note here is that the browser constructs the DOM incrementally. This gives us the opportunity to speed up the rendering of the page by creating efficient DOM structures.
When the parser encounters a
link tag that refers to an external CSS stylesheet, it blocks the parsing and sends out a request for this resource. Once the CSS file has been received, the browser starts building a tree data structure of CSS nodes.
Unlike DOM construction, CSSOM construction is not incremental. The browser can’t use a portion of a stylesheet, because styles can be refined and redeclared in the same stylesheet. For this reason, the browser blocks the rendering process until it receives and parses all the CSS. This means that CSS is render blocking.
The browser combines DOM and CSSOM into the Render Tree, which is the final tree structure containing all nodes and properties that are being used to render the page to the screen.
The Render Tree only contains nodes that are required to render a page. As a consequence, invisible nodes are omitted.
The browser uses the Render Tree to calculate node dimensions and position, and ultimately as an input for the paint process.
In the layout stage, the browser calculates dimensions and position of each node of the Render Tree. In this stage, the browser traverses the Render Tree starting from its root and produces a box model. This information is finally used to convert each node of the Render Tree into actual pixels on the screen.
The time required to run the entire process can be variable. It depends on many factors like the document size, the number of requests, the applied styles, the user device, etc.
One of the most relevant Google recommendations is to prioritize visible content so to render the Above the Fold as quick as possible, and provides two main rules to follow:
As well explained in Google’s PageSpeed guide, if the amount of data required to render the ATF exceeds the initial congestion window (14.6kb), it will require additional network round trips between the server and browser. On mobile networks, with high latencies, this would significantly delay the page loading (read more on latency).
The browser builds the DOM incrementally, and this gives us the opportunity to reduce the time required to render the ATF by structuring the HTML so to load the above-the-fold first and defer the rest of the page.
But optimization does not end with the construction of an effective DOM structure. Rather, it’s a process of improvement and measurement that involves the whole Critical Rendering Path sequence.
Let’s dive deep.
Now we know that the browser has to wait until it fetches and processes the CSS code before it can render the page (CSS is render blocking). But not all CSS resources are render-blocking.
CSS can be scoped to particular conditions, and we can optimize it using media types and media queries. If you’re viewing a webpage on the screen, the browser will send a request for print media type but it won’t block the rendering of the page for this resource.
Take the following
<link rel="stylesheet" href="style.css" />
The referenced stylesheet of this tag applies under any condition, independently from the current media type, screen resolution, device orientation, etc. This means that the CSS resource is always render-blocking.
Luckily, we can send a request for a CSS resource under specific conditions. We could move print styles into a separate file and use the
media attribute to tell the browser that the specified style sheet should only be loaded when printing the page, and it doesn’t need to block the rendering on the screen:
<link rel="stylesheet" href="print.css" media="print" />
The browser still downloads the print.css stylesheet, but it won’t block the rendering. Moreover, the browser has to download less data for the main CSS file and this would help us speed up the download. We can specify any media query on the
link attribute, so we can split the CSS into multiple files and load them conditionally:
<link rel="stylesheet" href="style.css" media="screen" /> <link rel="stylesheet" href="portrait.css" media="orientation:portrait" /> <link rel="stylesheet" href="widescreen.css" media="(min-width: 42rem)" />
Be sure your styles are actually required to render the page. If they’re not, you can add an appropriate value to media tag attribute and unblock rendering.
Media types and queries can help us to speed up the page rendering, but we can do a lot more.
The time spent by the browser to layout the document depends on the number of DOM elements to layout and on the complexity of those layouts.
Strictly connected to the Layout is the Paint process, which is probably the most time-consuming stage in the Critical Rendering Path sequence, because anytime you change the layout of an element or any non-geometric property the browser triggers a paint event. Making things as simple as possible at this stage could help the browser speed-up the paint process. For instance, a
box-shadow property, which requires some sort of calculations, would take longer to paint than a solid border color.
Optimizing the paint process may not be that easy, and you should make use of your browser’s developer tools to measure how long the browser takes to trigger each paint event. You can read more on this topic in Google’s Rendering Performance guide.
In case of external JS files, the parser must also wait until the resource has been fetched from cache or remote server, and this could heavily slow down the time to first render of the page.
asyncattribute of the
scripttag instructs the browser to execute the script asyncronously, if possible, without blocking the DOM construction. The browser sends the HTTP request for the script, and continues parsing the DOM. Also, the script does not block the CSSOM construction, meaning that it won’t block the Critical Rendering Path (see MDN docs for further information about script tag attributes)
deferattribute of the
scripttag tells the browser to execute the script after the document has been parsed, but before firing the
DOMContentLoadedevent. This attribute must not be used if the src attribute is absent, i.e. inline scripts (read more on Mozilla Hacks)
deferattributes for inline scripts, so the only way to load them after the document has been loaded is moving them to the bottom. The advantage is that inline scripts do not require additional HTTP requests. However, inlining scripts used in several pages would result in redundant code.
That’s a lot of stuff, isn’t it? Let’s take a breath, and write down a list of the optimization actions described so far.
deferattribute on the script tags
asyncattribute on the script tags
scripttags to the bottom of the document
Now that we know the basic concepts of Critical Rendering Path Optimization, we can have a look at some WordPress popular optimization plugins.
WordPress users can take advantage of a number of plugins that cover almost every aspect of the optimization process. You can install a fully featured plugin, or you can install several plugins at once, each providing specific optimization features.
If your site is hosted by Kinsta you won’t need a caching plugin because No WordPress Caching Plugins Needed at Kinsta.
This single plugin covers almost every stage of the Critical Rendering Path optimization process. At a first glance the plugin configuration can be overwhelming, but once you become more familiar with the Critical Rendering Path sequence, you will be able to take advantage of a powerful performance toolset.
Here is a list of some plugin features:
These are just few of the many W3TC features. You can read more on WordPress.org plugin’s page.
WP Super Cache is another popular plugin for site performance.
It comes with a good number of optimization features, but it’s less comprehensive than the previous W3 Total Cache and may look more affordable to novice and intermediate users.
defer attributes. However, more than one million active installs prove that the plugin is worth a try.
With over 400,000 active installs, Autoptimize is one of the most popular free plugins for minification.
You can also aggregate independent scripts or stylesheets and set exceptions for specific resources. Furthermore, Autoptimize allows to cache minified resources on disk or on CDN and save optimized assets as static files.
This plugin provides a comprehensive toolset for Above the Fold optimization. It’s a tool for professionals and advanced users aiming to score 100/100 in Google PageSpeed test.
Here are some of the most interesting features:
Moreover, the plugin provides support for Google’s Progressive Web App and Google Web Font optimization. Other optimization plugins you may want to try:
Swift Performance is another plugin you might want to check out. This is a premium plugin which can help increase your performance scores, and was developed specifically to help you try and achieve those 100/100 Google PageSpeed Insights scores.
Some of its main features include:
The Critical Rendering Path Optimization is a process of improvement and measurement that requires a clear understanding of every task the browser performs to convert code into pixels and so to render a page on the screen. You can learn more about Critical Rendering Path in Google’s optimization guide.
Here on Kinsta Blog, we try to cover any aspect of performance optimization. Here is a list of further readings:
How long does it take you to optimize the Critical Rendering Path of your websites? And which aspects of the optimization process are the thoughest for you to master? Let us know in the comments below.
Send this to a friend