Optimizing The Critical Rendering Path

Identifying the most critical resources and loading them early is one way to make your website load faster.

Understand the role of the critical rendering path in user experience, and how you can shorten this path to display the most important content early.

What is the critical rendering path?

When a website loads it often makes over a hundred requests to load resources from the internet. Some of these requests are critical to loading the website, others are less important.

A critical resource prevents page content from rendering.

Browsers then take these critical resource and turn them into content that can be shown to the visitor. This process is called rendering.

The critical rendering path describes the steps the browser has to go through in order to start rendering the page.

Why does the critical rendering path matter?

Showing content quickly is important for visitors. Otherwise they may become frustrated or abandon the page altogether, especially on slower network connections.

Page speed also matters for search engine rankings, as Google uses the Core Web Vitals metrics as a ranking factor.

How are critical resources defined?

Critical resources are very similar to render-blocking resources. Typically they include:

• HTML
• CSS
• JavaScript

These resources aren't always critical though. For example, JavaScript loading can be deferred.

Web fonts can also form part of the critical rendering path.

An example of the critical path

Let's look at a real world example of a critical rendering path. Request waterfall visualizations are a great way to do that.

Waterfall charts show us when different resources are loaded and often also include information on CPU tasks and rendering progress.

Here we can see three steps:

1. Loading the HTML document
2. Loading render-blocking CSS stylesheet files
3. Rendering the page and displaying content

These three steps are sequential and have to happen one after the other:

• The CSS stylesheets are referenced in the HTML, so they can only load once the HTML starts downloading.
• The way the page is rendered depends on how it's styled, and that's defined in the CSS files

The orange marker in the screenshot above shows when the CPU processing work that's necessary to render the page happens. Shortly after that we see the page content appear. The First Contentful Paint is used to measure this page load milestone, and is shown by the blue line on the right of the waterfall.

Using PageSpeed Insights and Lighthouse to identify critical resources

Google has built a free page speed tool called Lighthouse, which you can use to test your website and detect resources that are part of the critical rendering path.

You can run Lighthouse using DebugBear's website speed test or Google's PageSpeed Insights tool.

Run the test, open the Lighthouse report, and scroll down to the Avoid chaining critical requests audit in the performance diagnostics section.

tip

This automated analysis is helpful, but it is not fully correct. For example, the dark-theme.css file has the disabled attribute, which makes it not render-blocking.

What is the maximum critical path latency

The critical path latency in Lighthouse adds up the time spent loading the resources in the longest chain of critical requests on the page.

For example, if loading the HTML takes 0.4 seconds, loading the CSS takes 0.8 seconds, and the page renders after that, then the maximum critical path latency is 1.2 seconds.

Are fonts critical resources?

In the Lighthouse result above we could see that fonts were included in the critical rendering path. However, the page content does render without them.

So, are fonts part of the critical rendering path? It depends on what you consider critical. Sometimes text will appear invisible until after the font is loaded. However, that's not the case here.

Instead, when the web font loads there is a small change in how the website displays. From both a user perspective and for the Core Web Vitals assessment I don't think this font is critical for the page.

Are images critical resources?

Images do not form part of the critical rendering path.

However, they can be important for user experience and as a factor impacting the Largest Contentful Paint metric, which is one of the Core Web Vitals that impact rankings.

tip

While images are not part of the critical path in a technical sense, they can play a critical role on your website.

What is critical CSS?

In general, CSS stylesheets are critical because if the page renders without them the visitor will experience a Flash of Unstyled Content.

However, not all CSS rules in a stylesheet are critical. Some of the CSS will be unused on the page, for example because it's for styling elements on other pages. Other styles will be needed for page elements that are below the "fold", the threshold the visitor can see when the website first loads.

Critical CSS refers to only the styles that are necessary to style page elements that appears above the fold.

tip

Where the "fold" is will depend on the visitors device size, so generally a generous amount of CSS for a large screen is included.

Extracting and inlining critical CSS

We've seen that CSS files are chained after the HTML with a sequential load order. The idea of extracting critical CSS and inlining critical styles in the HTML is to shorten the critical request chain by embedding important styles in the HTML code itself with <style> tags.

This can work, however there are two common problems with this:

• You need to generate a custom set of CSS rules for each page, often by rendering the page and checking what content appears above the fold
• Inlining CSS in the HTML means the CSS code can't stored in the browser cache and reused across visits to different pages

The role of DOM and CSSOM

The DOM is the set of page elements created based on the HTML code. Similarly, the CSSOM is created based on the CSS rules in the website's stylesheets.

tip

The browser turns code into object models (OM) for the HTML document (DOM) and CSS (CSSOM).

Together, DOM and CSSOM are used to construct the render tree. This is a data structure that contains all page elements and the styles that apply to them.

Once that is done the render tree can be converted to a page layout which can then be rendered on the screen.

How do these components factor into the critical rendering path?

• The DOM is needed to know what content to display
• The CSSOM is constructed based on CSS rules and is required to display content
• The layout and rendering steps are the processing tasks the browsers needs to complete to actually display the content

How to optimize the critical rendering path

Here are a few steps you can take to shorten the critical rendering path:

• Re-use server connections between requests
• Reduce server response time
• Make download sizes smaller
• Break up sequential request chains
• Make sure JavaScript does not block rendering

Re-use server connections between requests

Making each request in the critical rendering path faster means your website will load faster overall. Re-using server connections is one way to achieve this.

Before loading a resource browsers first need to connect to the server that the resource is loaded from.

Every new server requires a new connection.

The screenshot above shows a CSS file that's loaded from the same domain as the document. Here, no server connection is required.

However, another CSS file is loaded from fonts.googleapis.com, which means a connection to this new server is needed. The three colored rectangles ahead of the main request bar indicate the three network round trips required to create a connection.

Reduce server response time

Another factor that determines request duration is how long the server takes to respond to the request.

Reduce server response time by simplifying your page, optimizing your code, or caching responses on a CDN or in your application.

Make download sizes smaller

Another factor that impacts request duration is the download size of the response. Larger responses take longer to download.

This screenshot shows that loading the small 936 byte CSS file takes a lot less time than loading the 130 kilobyte stylesheet.

How can you reduce download size? A lot of that depends on the file type:

• Use text compression on code responses
• Serve images in modern formats
• Avoid serving unused JavaScript code

We've also published an in-depth guide on how to avoid large network payloads.

Break up sequential request chains

Whenever possible you want to load all critical resources in parallel to reduce the maximum critical path latency.

For example, using CSS @import rules can slow down your website as it causes two stylesheets to load one after the other.

Here's an example waterfall from DebugBear's synthetic monitoring tool. The typography.css file only starts loading once the download of style.css is complete.

Make sure JavaScript does not block rendering

We've already talked about how JavaScript files are part of the critical rendering path by default. However, the async and defer attribute on the <script> element can prevent this and ensure the script is not render-blocking.

We can see a nice example of this here. The script has the async attribute, so when it finishes loading the browser has already started displaying page content. The script is therefore not part of the critical request chain on the page.

What is progressive rendering?

Progressive rendering is one approach to shortening the critical rendering path.

Instead of waiting for all resources on the page to load before displaying content, you instead identify specific critical resources that need to load early.

Other content can then load late on and the website can gradually render until it is visually complete.

For example, your website can render without sliders or chat widgets and these non-critical UI components can then initialize later on once the user can start consuming the page content.

The critical rendering path for React and other client-side applications

Today many websites are built using JavaScript frameworks like React, and implemented as single-page applications that don't load a new document for each navigation on the website.

On the one hand, this can often achieve a short critical path, as the page header and placeholder content can quickly be shown to the user while the JavaScript code is loading.

However, the visitor is likely to feel that the main page content that's rendered with JavaScript is actually critical to them!

That's why you need to make sure that the main page content shows up quickly using these two techniques:

• Implementing server-side rendering so the browser doesn't have to wait for the JavaScript to render key content
• Optimizing front-end JavaScript performance to make your application load quickly

tip

Single-page applications don't fit well in the traditional concept of the critical rendering path, as important content is displayed dynamically.

Shorten the critical path for a fast website

Optimizing the critical path is one important aspect of website performance optimization. It provides a helpful perspective on the role different resources play on your website.