Despite significant changes to the organic search landscape throughout the year, the speed and efficiency of web pages have remained paramount.

Users continue to demand quick and seamless online interactions, with 83% of online users reporting that they expect websites to load in three seconds or less.

Google sets the bar even higher, requiring a Largest Contentful Paint (a metric used to measure a page’s loading performance) of less than 2.5 seconds to be considered “Good.”

The reality continues to fall below both Google’s and users’ expectations, with the average website taking 8.6 seconds to load on mobile devices.

On the bright side, that number has dropped 7 seconds since 2018, when it took the average page 15 seconds to load on mobile devices.

But page speed isn’t only about total page load time; it’s also about what users experience in those 3 (or 8.6) seconds. It’s essential to consider how efficiently pages are rendering.

This is accomplished by optimizing the critical rendering path to get to your first paint as quickly as possible.

Basically, you’re reducing the amount of time users spend looking at a blank white screen to display visual content ASAP (see 0.0s below).

What Is The Critical Rendering Path?

The critical rendering path refers to the series of steps a browser takes on its journey to render a page, by converting the HTML, CSS, and JavaScript to actual pixels on the screen.

Essentially, the browser needs to request, receive, and parse all HTML and CSS files (plus some additional work) before it will start to render any visual content.

Until the browser completes these steps, users will see a blank white page.

Steps for browser to render visual content. (Image created by author)

How Do I Optimize It?

The primary goal of optimizing the critical rendering path is to prioritize the resources needed to render meaningful, above-the-fold content.

To do this, we also must identify and deprioritize render-blocking resources – resources that are not necessary to load above-the-fold content and prevent the page from rendering as quickly as it could.

To improve the critical rendering path, start with an inventory of critical resources (any resource that blocks the initial rendering of the page) and look for opportunities to:

• Reduce the number of critical resources by deferring render-blocking resources.
• Shorten the critical path by prioritizing above-the-fold content and downloading all critical assets as early as possible.
• Reduce the number of critical bytes by reducing the file size of the remaining critical resources.

There’s a whole process on how to do this, outlined in Google’s developer documentation (thank you, Ilya Grigorik), but I will be focusing on one heavy hitter in particular: Reducing render-blocking resources.

What Are Render-Blocking Resources?

Render-blocking resources are elements of a webpage that must be fully loaded and processed by the browser before it can start rendering the content on the screen. These resources typically include CSS (Cascading Style Sheets) and JavaScript files.

Render-Blocking CSS

CSS is inherently render-blocking.

The browser won’t start to render any page content until it is able to request, receive, and process all CSS styles.

This avoids the negative user experience that would occur if a browser attempted to render un-styled content.

A page rendered without CSS would be virtually unusable, and the majority (if not all) of content would need to be repainted.

Example page with and without CSS, (Image created by author)

Looking back to the page rendering process, the gray box represents the time it takes the browser to request and download all CSS resources so it can begin to construct the CCSOM tree (the DOM of CSS).

The time it takes the browser to accomplish this can vary greatly, depending on the number and size of CSS resources.

Steps for browser to render visual content. (Image created by author)

Recommendation:

“CSS is a render-blocking resource. Get it to the client as soon and as quickly as possible to optimize the time to first render.”

Render-Blocking JavaScript

Unlike CSS, the browser doesn’t need to download and parse all JavaScript resources to render the page, so it’s not technically* a “required” step (*most modern websites require JavaScript for their above-the-fold experience).

Yet, when the browser encounters JavaScript before the initial render of the page, the page rendering process is paused until after the JavaScript is executed (unless otherwise specified using the defer or async attributes – more on that later).

For example, adding a JavaScript alert function into the HTML blocks page rendering until the JavaScript code is finished executing (when I click “OK” in the screen recording below).

Example of render-blocking JavaScript. (Image created by author)

This is because JavaScript has the power to manipulate page (HTML) elements and their associated (CSS) styles.

Since the JavaScript could theoretically change the entire content on the page, the browser pauses HTML parsing to download and execute the JavaScript just in case.

How the browser handles JavaScript, (Image from Bits of Code, August 2024)

Recommendation:

“JavaScript can also block DOM construction and delay when the page is rendered. To deliver optimal performance … eliminate any unnecessary JavaScript from the critical rendering path.”

How Do Render Blocking Resources Impact Core Web Vitals?

Core Web Vitals (CWV) is a set of page experience metrics created by Google to more accurately measure a real user’s experience of a page’s loading performance, interactivity, and visual stability.

The current metrics used today are:

• Largest Contentful Paint (LCP): Used to evaluate loading performance, LCP measures the time it takes for the largest visible content element (such as an image or block of text) to appear on the screen.
• Interaction to Next Paint (INP): Used to evaluate responsiveness, INP measures the time from when a user interacts with the page (e.g., clicks a button or a link) to the time when the browser is able to respond to that interaction.
• Cumulative Layout Shift (CLS): Used to evaluate visual stability, CLS measures the sum total of all unexpected layout shifts that occur during the entire lifespan of the page. A lower CLS score indicates that the page is stable and provides a better user experience.

Optimizing the critical rendering path will typically have the largest impact on Largest Contentful Paint (LCP) since it’s specifically focused on how long it takes for pixels to appear on the screen.

The critical rendering path affects LCP by determining how quickly the browser can render the most significant content elements. If the critical rendering path is optimized, the largest content element will load faster, resulting in a lower LCP time.

Read Google’s guide on how to optimize Largest Contentful Paint to learn more about how the critical rendering path impacts LCP.

Optimizing the critical rendering path and reducing render blocking resources can also benefit INP and CLS in the following ways:

• Allow for quicker interactions. A streamlined critical rendering path helps reduce the time the browser spends on parsing and executing JavaScript, which can block user interactions. Ensuring scripts load efficiently can allow for quick response times to user interactions, improving INP.
• Ensure resources are loaded in a predictable manner. Optimizing the critical rendering path helps ensure elements are loaded in a predictable and efficient manner. Effectively managing the order and timing of resource loading can prevent sudden layout shifts, improving CLS.

To get an idea of what pages would benefit the most from reducing render-blocking resources, view the Core Web Vitals report in Google Search Console. Focus the next steps of your analysis on pages where LCP is flagged as “Poor” or “Need Improvement.”

How To Identify Render-Blocking Resources

Before we can reduce render-blocking resources, we have to identify all the potential suspects.

Luckily, we have several tools at our disposal to quickly pinpoint exactly which resources are hindering optimal page rendering.

PageSpeed Insights & Lighthouse

PageSpeed Insights and Lighthouse offer a quick and easy way to identify render blocking resources.

Simply test a URL in either tool, navigate to “Eliminate render-blocking resources” under “Diagnostics,” and expand the content to see a list of first-party and third-party resources blocking the first paint of your page.

Both tools will flag two types of render-blocking resources:

• JavaScript resources that are in <head> of the document and don’t have a <defer> or <async> attribute.
• CSS resources that do not have a disabled attribute or a media attribute that matches the user’s device type.

Sample results from PageSpeed Insights test. (Screenshot by author, August 2024)

Tip: Use the PageSpeed Insights API in Screaming Frog to test multiple pages at once.

WebPageTest.org

If you want to see a visual of exactly how resources were loaded in and which ones may be blocking the initial page render, use WebPageTest.org.

To identify critical resources:

• Run a test using webpagetest.org and click on the “waterfall” image.
• Focus on all resources requested and downloaded before the green “Start Render” line.

Analyze your waterfall view; look for CSS or JavaScript files that are requested before the green “start render” line but are not critical for loading above-the-fold content.

Sample results from WebPageTest.org. (Screenshot by author, August 2024)

How To Test If A Resource Is Critical To Above-The-Fold Content

Depending on how nice you’ve been to the dev team lately, you may be able to stop here and just simply pass along a list of render-blocking resources for your development team to investigate.

However, if you’re looking to score some extra points, you can test removing the (potentially) render-blocking resources to see how above-the-fold content is affected.

For example, after completing the above tests I noticed some JavaScript requests to the Google Maps API that don’t appear to be critical.

Sample results from WebPageTest.org. (Screenshot bu author, August 2024)

To test within the browser how deferring these resources would affect above-the-fold content:

• Open the page in a Chrome Incognito Window (best practice for page speed testing, as Chrome extensions can skew results, and I happen to be a collector of Chrome extensions).
• Open Chrome DevTools (ctrl+shift+i) and navigate to the “Request blocking” tab in the Network panel.
• Check the box next to “Enable request blocking” and click the plus sign.
• Type a pattern to block the resource(s) you’ve identified, being as specific as possible (using * as a wildcard).
• Click “Add” and refresh the page.

Example of request blocking using Chrome Developer Tools. (Image created by author, August 2024)

If above-the-fold content looks the same after refreshing the page – the resource you tested is likely a good candidate for tactics listed under “Methods to reduce render-blocking resources.”

If the above-the-fold content does not properly load, refer to the below methods to prioritize critical resources.

Methods To Reduce Render-Blocking

Once you have confirmed that a resource is not critical to rendering above-the-fold content, explore different methods for deferring resources and improving page rendering.

Place JavaScript At The Bottom Of The HTML

If you’ve ever taken a Web Design 101 course, this one may be familiar: Place links to CSS stylesheets at the top of the HTML <head> and place links to external scripts at the bottom of the HTML <body>.

To return to my example using a JavaScript alert function, the higher up the function is in the HTML, the sooner the browser will download and execute it.

When the JavaScript alert function is placed at the top of the HTML, page rendering is immediately blocked, and no visual content appears on the page.

Example of JavaScript placed at the top of the HTML, page rendering is immediately blocked by the alert function and no visual content…