What Is It?

Critical request chains are a series of dependent network requests important for page rendering. The more prominent the length of the chains and the bigger the download sizes, the more critical the effect on page load execution.

Browsers typically parse HTML utilizing a streaming parser—resources are found inside the markup before they are delivered. As they are identified, they’re assigned a priority, from Very High to Very Low. The items with the highest priority are loaded first. 

Unless specified, HTML usually gets the highest priority, then CSS, then Images, then Scripts… You can see this in Chrome’s Dev Toolkit. Let’s analyze the critical request chain of our favorite WordPress host, Cloudways:

As you can see, the Home.php file has the highest priority, then the CSS (which is cached), then the JS is loaded. The priority matches the order that they were loaded in. 

Why Does It Display?

If Google determines your CRCs to be overly large in length or size AND/OR have noticeable latency, it will display this Performance opportunity. 

Lighthouse will display all critical requests loaded with a high priority, like so:

As you can see, it shows which scripts, files and classesheets are loaded, and in what order. Remember, these are a series of dependent network requests, so the latency displayed (in ms) adds up to the maximum critical path latency. 

How Do You Fix It?

If you failed this audit, your website is doing something incorrectly, as Google compares your data to other similar sites. 

Use the critical request chains audit results to target the resources that have the biggest effect on page load first:

• Minimize the number of critical resources: eliminate them, defer their download, mark them as async, and so on.
• Optimize the number of critical bytes to reduce the download time (number of round trips).
• Optimize the order in which the remaining critical resources are loaded: download all critical assets as early as possible to shorten the critical path length.

So in simpler terms, identify which file is loading slowly due to its latency or size, then address it. You identify it by looking at your Lighthouse report and finding files in the “Minimize Critical Requests” that are large, perhaps unnecessary 

On WordPress, there are a collection of lovely plugins that will help you with this. Say you’re loading a stylesheet for a plugin that’s unneeded during this critical phase, call it plugin.css. 

Because your visitor doesn't need it until they scroll halfway down the page, there’s no reason to load it in the first 2000ms of page load, which is when critical content is loaded. Say it’s a large file, so it takes a total of 500ms to load. Removing it from the critical request chain removes 500ms from the total loading time of critical assets, which is a hefty 25% of the total.

If the stylesheet isn’t needed on the page, then you can remove it completely from loading on the specific page. 

If it is needed, you can defer or async it. You can also simply move it to the footer, so it loads slower. 

There’s an awesome WordPress plugin that we use in all of our sites called Asset Clean Up. In many cases, the free version of the plugin works super well. It allows you to individually toggle on and off various scripts, files and stylesheets, or choose to defer or asynchronously load them. Here’s an example:

Say you don’t need the JS for Stripe, a payment processor, and that it’s really impacting the critical requests change, because it takes 200ms to load for no purpose. With WP Asset Clean Up, you simply click the toggle to “unload” or turn off on the specific page. You can even test the effect that this would have on your site before pushing it live through the included “Test mode”.
The pro version is even more helpful. It’ll allow you to load the asset asynchronously or defer it. You can even move it to the footer.