TL;DR: Chaining occurs when one critical resource depends on another, causing delays. To mitigate this, use techniques like asynchronous loading, optimizing critical paths, and leveraging browser caching to prevent critical request chains, ensuring faster page rendering and performance.
Are you getting the "Avoid chaining critical requests" warning every time you run a PageSpeed Insights test?
Well, this ends today.
After reading this guide, you will know everything about critical requests, how chaining them impacts your performance, and most importantly - how to fix the “Avoid chaining critical requests” warning.
- What is considered a critical request?
- What does “Avoid chaining critical requests” mean
- How chaining critical requests affects your performance
- How to avoid chaining critical requests on WordPress
- Bonus: Other best practices to fix “Avoid chaining critical requests”
Read on.
What is considered a critical request?
A critical request is a resource that is essential for rendering the initial view of a web page. In other words - everything that it’s loaded above the fold.
For instance, here’s what I see on my laptop when I load NitroPack’s home page:
All of the above-the-fold elements are considered critical because depending on how fast they are loaded, the user can have a great experience or bounce immediately.
What does Avoid Chaining Critical Requests mean?
Simply put, the “Avoid chaining critical requests” warning means that the critical resources needed to render your page are too large.
In terms of the chaining part, a critical request chain is a sequence of requests that depend on each other, and are essential for rendering the page. The order the requests are parsed and executed is determined by the Critical Rendering Path (CRP).
The Critical Rendering Path refers to the sequence of steps that a web browser takes to convert HTML, CSS, and JavaScript code into a visual representation on a user's screen.
When the browser starts to parse the code, it processes the critical requests based on the assigned priority:
Now that you know what CRP is and how browsers assign priorities, let’s get back to the definition of “critical request chain.”
Since it’s a sequence of requests that depend on each other, loading large, unoptimized critical requests will inevitably result in longer critical chains, slowing down your page load.
To illustrate this statement, let’s take a look at the following example:
Imagine a simple web page that includes the following resources:
- index.html – the main HTML file that defines the structure of the page.
- styles.css – defines the visual appearance and layout of the page.
- main.js – contains scripts that add interactivity and functionality to the web page.
- logo.png (Image file)
Consider a situation where each resource is part of a long critical request chain. For instance, imagine the HTML file references several CSS and JavaScript files, and each of those files, in turn, references other resources, leading to a chain of dependencies.
In such a scenario, a delay in loading any one of the resources in the chain will have a cascading effect on the critical path latency and the overall performance of your page.
And speaking of web performance, let’s see which metrics will take the biggest hit from chaining critical requests…
How chaining critical requests affects your performance
The longer the chain is, the longer it takes for the browser to render the resources needed to display your content.
In terms of web performance metrics, this translates to poor First Contentful Paint (FCP) and Largest Contentful Paint (LCP).
Failing First Contentful Paint (FCP)
FCP measures how long it takes the browser to visualize the first piece of DOM content (e.g., image, SVG, non-blank canvas element) on a page.
These elements might seem insignificant, but they are pivotal to the user experience of your site. They tell your visitors their input is being processed and the site is loading. If a page stays blank for a few seconds before it loads, users don’t know whether something is happening or not.
To guarantee that the browser can render this first piece of DOM content as soon as possible, the critical request chains must be short and light. Otherwise, the chances of your visitors bouncing off due to a blank screen and failing FCP are much HIGHER.
Failing Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest above-the-fold element to load on a page.
It is one of the three Core Web Vitals (CWV) which are a set of user-centric metrics measuring your site’s loading time, visual stability, and interactivity. They are also a Google ranking factor.
So, having a poor LCP score due to loading long critical request chains not only means you’re failing some performance metric but you’re also:
- Lowering your chances of passing CWV
- Hurting your site’s ranking
- Providing a bad user experience
The surefire way to avoid all that is to shorten the critical path by optimizing your resources’ number and size.
And here’s how to do it…
How to avoid chaining critical requests (on WordPress)
If there’s a single go-to strategy for fixing “Avoid chaining critical requests,” it would be eliminating render-blocking resources.
Render-blocking resources are files which when the browser encounters them, it must download, parse, and execute them, before doing anything else, including rendering.
The main culprits most commonly flagged as “render-blocking” are unoptimized CSS and JavaScript files.
The following techniques will help you successfully handle both of them:
Remove Unused CSS
The term Unused CSS refers to CSS rules that aren’t used on the current page.
These rules make files larger than necessary, bloating your code, and creating long critical request chains. As a result, your files and page take forever to load.
If you’re comfortable fine-tuning your code, you can use an online tool like PurifyCSS.
Enter your page’s URL and the tool automatically strips the unnecessary code. Then, you can download the “purified” CSS and upload it on your site:
Important: Altering your code hides the risk of breaking your site’s design and functionality. If you do not have previous tech experience, contact a web developer or install a plugin that will automatically do it for you.
Defer JavaScript
Deferring JavaScript files allows you to load them only when necessary, so the browser can focus on serving the most critical content (above the fold) first.
You can lazy load your JS files using the async and defer attributes.
Asynchronous loading means that the script will be fetched in the background while the HTML parsing and rendering of the page continue.
When the script is downloaded, it will pause the HTML parsing, execute the script immediately, and then resume parsing. As a result, the order in which scripts with the async attribute execute can be unpredictable since they may complete loading at different times.
The async attribute is perfect for third-party scripts that you don't want to block the loading and rendering of your page.
The defer attribute, like async, also loads the script asynchronously, but it differs in the way it is executed.
Scripts with the defer attribute will be downloaded in the background while the HTML parsing continues, but the script execution will be deferred until after the HTML parsing is complete. The order of execution of scripts with defer is maintained in the order they appear in the HTML.
Use the defer attribute when you want to maintain the order of script execution as they appear in the HTML.
Code compression and minification
Another layer of critical request chain optimization is to reduce your resources’ overall size as it will help the browser download, parse, and render them faster.
And the way to do it is by compressing and minifying your files.
Applying compression will rewrite your files’ binary code and encode the information using fewer bits than the original.
The most popular compression tool is gzip. Gzipping works by finding the repetitive strings and replacing them with pointers to the first instance of the string. The benefit is that pointers use less space than text.
Minification, on the other hand, removes unnecessary code elements like comments, line breaks, or whitespace:
Source: KeyCDN
By trimming your code, you can shorten your critical requests, leading to a speed improvement for your website.
There are tons of free tools online that could help you optimize your code size. Using them will require you to enter your code, then copy the minified/compressed version and paste it back into your site. Here are a couple of suggestions:
Other best practices to fix “Avoid chaining critical requests”
Font subsetting
After taking care of your site’s CSS and JavaScript resources, the next best candidate for optimization is your web fonts.
Mostly overlooked, web fonts are often large files that take a while to load and can even block the rendering of the text.
To avoid that you need to reduce their size so the browser can load them immediately.
Enter font subsetting.
Font subsetting is an optimization technique that removes the unused glyphs (characters) from a font to reduce its size massively.
For instance, think about how many unique glyphs your homepage uses. We’re willing to bet you they aren’t more than 100.
To put that into perspective, Font Awesome, the second most used font (7% of all websites use it), has 26,107 characters.
Source: Web Almanac
Imagine how much time you could save the browser and your visitors by loading only what’s absolutely necessary for the particular page.
There are some online tools that could help you apply font subsetting. You will need to upload your font file and select the glyphs you want to be removed. Then, get back to your site and upload the subsetted file.
Also, you need to make sure you go through the process every time you update your content.
Important: Subsetting your font files via online tools hides the risk of missing characters on your page after optimization. If you haven’t worked with fonts before, we strongly recommend contacting a web performance specialist or installing a plugin that will do it automatically for you.
Preload key requests
Using the link rel=preload attribute to preload critical requests is another optimization strategy that will improve your FCP and LCP, and shorten the critical path.
To identify your most critical request, run your site through PageSpeed Insights and check the “Preload key request” warning:
Then, go to your code and add the link rel=preload tag to the specific resource:
Don’t forget to include the as attribute so the browser can set the priority of the prefetched resource according to its type and determine whether it already exists in the cache.
Additional resources: Check the complete list of as values.
How to avoid chaining critical requests with NitroPack
Optimizing your critical request chains might be a tedious task if you aren’t armed with the right tools.
As you already know, there are several occasions when fine-tuning your code can backfire and break your site’s functionality and design.
But fixing a single PSI warning shouldn’t be such a headache.
Or at least it isn’t with NitroPack.
NitroPack is an all-in-one speed optimization tool that will boost your site’s performance by applying:
- Remove Unused CSS
- Defer JavaScript
- Font subsetting
And 32+ other proven optimization techniques for you.
With NitroPack, no coding or previous tech experience is required to boost your site’s performance.
Sounds too good to be true?
Let’s take a look at one of our client’s websites with and without NitroPack.
Here are their results without NitroPack:
41 Performance score on mobile, 47 chains, and critical path latency of 3,781 ms.
Without NitroPack
And here are the results with NitroPack:
95 Performance score, 1 chain, more than 2x shorter critical path latency:
With NitroPack
You can experience this and a bunch of other performance improvements as well. Install NitroPack today and let us take care of your site’s lightning speed.
