How To Identify & Reduce Render-Blocking Reosurces

How To Identify & Reduce Render-Blocking Reosurces

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.

Method
Impact
Works with

JavaScript at the bottom of the HTML
Low
JS

Async or defer attribute
Medium
JS

Custom Solutions
High
JS/CSS

CSS media queries
Low-High
CSS

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 renders.
When the JavaScript alert function is moved to the bottom of the HTML, some visual content appears on the page before page rendering is blocked.

Example of JavaScript placed at the bottom of the HTML, some visual content appears before page rendering is blocked by the alert function.
While placing JavaScript resources at the bottom of the HTML remains a standard best practice, the method by itself is sub-optimal for eliminating render-blocking scripts from the critical path.

Continue to use this method for critical scripts, but explore other solutions to truly defer non-critical scripts.

Use The Async Or Defer Attribute

The async attribute signals to the browser to load JavaScript asynchronously, and fetch the script when resources become available (as opposed to pausing HTML parsing).

Once the script is fetched and downloaded, HTML parsing is paused while the script is executed.

How the browser handles JavaScript with an async attribute. (Image from Bits of Code, August 2024)
The defer attribute signals to the browser to load JavaScript asynchronously (same as the async attribute) and to wait to execute JavaScript until the HTML parsing is complete, resulting in additional savings.

How the browser handles JavaScript with a defer attribute. (Image from Bits of Code, August 2024)
Both methods are relatively easy to implement and help reduce the time the browser spends parsing HTML (the first step in page rendering) without significantly changing how content loads on the page.

Async and defer are good solutions for the “extra stuff” on your site (social sharing buttons, a personalized sidebar, social/news feeds, etc.) that are nice to have but don’t make or break the primary user experience.

Use A Custom Solution

Remember that annoying JS alert that kept blocking my page from rendering?

Adding a JavaScript function with an “onload” resolved the problem once and for all; hat tip to Patrick Sexton for the code used below.

The script below uses the onload event to call the external resource “alert.js” only after all the initial page content (everything else) has finished loading, removing it from the critical path.

JavaScript onload event used to call alert function
Rendering of visual content was not blocked when a JavaScript onload event was used to call alert function.
This isn’t a one-size-fits-all solution. While it may be useful for the lowest priority resources (i.e., event listeners, elements in the footer, etc.), you’ll probably need a different solution for important content.

Work with your development team to find the best solution to improve page rendering while maintaining an optimal user experience.

Use CSS Media Queries

CSS media queries can unblock rendering by flagging resources that are only used some of the time and setting conditions on when the browser should parse the CSS (based on print, orientation, viewport size, etc.).

All CSS assets will be requested and downloaded regardless but with a lower priority for non-blocking resources.

Example CSS media query that tells the browser not to parse this stylesheet unless the page is being printed.
When possible, use CSS media queries to tell the browser which CSS resources are (and are not) critical to render the page.

Methods To Prioritize Critical Resources

Prioritizing critical resources ensures that the most important elements of a webpage (such as CSS for above-the-fold content and essential JavaScript) are loaded first.

The following methods can help to ensure your critical resources start loading as early as possible:

Optimize when critical resources are discovered. Ensure critical resources are discoverable in the initial HTML source code. Avoid only referencing critical resources in external CSS or JavaScript files, as this creates critical request chains that increase the number of requests the browser has to make before it can even begin to download the asset.
Use resource hints to guide browsers. Resource hints tell browsers how to load and prioritize resources. For example, you may consider using the preload attribute on fonts and hero images to ensure they are available as the browser starts rendering the page.
Considering inlining critical styles and scripts. Inlining critical CSS and JavaScript with the HTML source code reduces the number of HTTP requests the browser has to make to load critical assets. This technique should be reserved for small, critical pieces of CSS and JavaScript, as large amounts of inline code can negatively impact the initial page load time.

In addition to when the resources load, we should also consider how long it takes the resources to load.

Reducing the number of critical bytes that need to be downloaded will further reduce the amount of time it takes for content to be rendered on the page.

To reduce the size of critical resources:

Minify CSS and JavaScript. Minification removes unnecessary characters (like whitespace, comments, and line breaks), reducing the size of critical CSS and JavaScript files.
Enable text compression: Compression algorithms like Gzip or Brotli can be used to further reduce the size of CSS and JavaScript files to improve load times.
Remove unused CSS and JavaScript. Removing unused code reduces the overall size of CSS and JavaScript files, decreasing the amount of data that needs to be downloaded. Note, that removing unused code is often a huge undertaking, requiring significantly more effort than the above methods.

TL;DR

The critical rendering path includes the sequence of steps a browser takes to convert HTML, CSS, and JavaScript into visual content on the page.
Optimizing this path can result in faster load times, improved user experience, and increased Core Web Vitals scores.
Tools like PageSpeed Insights, Lighthouse, and WebPageTest.org help identify potentially render-blocking resources.
Defer and async HTML attributes can be leveraged to reduce the number of render-blocking resources.
Resource hints can help ensure critical assets are downloaded as early as possible.

More resources: 

Featured Image: Summit Art Creations/Shutterstock

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *