Fix "Avoid Chaining Critical Requests" On Your Blog or Website

Fix "Avoid Chaining Critical Requests" On Your Blog or Website

"Avoid Chaining Critical Requests" Short Explanation

A critical request chain is a series of high-priority requests that the browser fetches. The Critical Rendering Path, which specifies the order in which requests are parsed and executed, determines this.

A chain of critical requests occurs when a website or script causes numerous resources to be downloaded with high priority. Until all of these crucial resources have been downloaded, a browser will not (completely) display and paint the page. As a result, any key resource can prevent a page from rendering for the first time.

According to the lighthouse, the larger or heavier the Critical Request Chain becomes, the greater influence the Critical Request Chain has on the website loading time. Reduced latency and faster page loading are achieved by reducing the number of important request chains. 

What factors go into determining the download priority?

The resources that are downloaded with a high priority during the initial page load are known as critical requests.

The browser determines the order in which downloads are prioritized. To determine the priority of each asset, the browser uses a set of rules. The structure of the page determines which items receive the most importance. The items that your browser considers to be most important for the first rendering of the page are given top priority.

Initially, your browser makes an educated estimate as to which items are the most significant. In general, the download priority is as follows: HTML is always first, followed by Style sheets, synchronous JavaScript, Fonts, images at the top of the page, images further down the page, and asynchronous JavaScripts.

You may examine which sources are given high attention on your page for yourself. Ctrl + Shift + J will open the dev-console. Select 'Priority' from the network tab by right-clicking on the column names. 

How does the critical Request Chain affect the page load time of a blog or website?

Chaining crucial requests will have a different impact on your site depending on the length of the chains and the size of each important resource being served.

Longer chains and greater resource sizes, in other words, may result in poorer page speed. This is because the browser will take longer to process and prepare each chain for pixel display on the page. As a result, the initial rendering of content on your web page will take longer.

Shorter chains and smaller resource sizes will make web pages load faster and improve the responsiveness of your page elements. This makes it easier for the browser to process and download all of the resources required to render the page's content. On the front end, this implies that when someone visits your blog or website for the first time, they will be able to see the material on the page right away.

How to fix "Avoid Chaining Critical Requests"?

There are three approaches to reduce the impact of critical requests:

  1. Reduce the number of critical resources. By deleting or deferring crucial resources, you can turn them into non-critical resources.
  2. Reduce the number of critical bytes.It may seem self-evident, but lowering the number of bytes in critical path resources speeds up download time. Gzip compression, javascript tree shaking, picture optimization, and font subsetting are just a few examples.
  3. Improve the download order of the critical path.To avoid resource discovery and guarantee that vital resources are received as rapidly as possible, use resource hints like preloading.

There are numerous options available. Which option is the best dependent on the resource's file type:


The HTML, which is the page you are viewing, is always downloaded first. The critical request chain always includes the page. As a result, while optimizing the important request chain, the first item to evaluate is the page itself.

  • Delayed content loading: Many large sites use this strategy to reduce the critical request chain. Parts of the content that aren't needed right away, for example, are loaded later via an AJAX request on the search results page.
  • Minify: Because smaller is always better, use HTML minification to remove unnecessary comments, spaces, and blank lines from your page.
  • Compression: Using Brotli or GZIP compression to correctly compress stylesheets is critical.


The importance of stylesheets at the head of the page cannot be overstated. A browser has no idea what the page will look like without styles. As a result, stylesheets are an integral part of the critical request chain.

Critical CSS: CSS stylesheets that are important can be rendered non-critical using a simple method in which the stylesheet is preloaded using resource hints and then added as a stylesheet after the preloading is complete.

Paste the following code on the page, and the stylesheet will now be downloaded with a lower priority. It will begin rendering immediately without waiting for the CSS to load.

<link rel="preload"
; onload="this.onload=null;this.rel='stylesheet';"/>

The page is displayed first, and then the CSS is loaded and the styling is applied. All content will now transition from unstyled to styled mode. This is something that crucial CSS can help us with. A compilation of all the CSS rules you'll need for the viewable section of the page is known as critical CSS. With NodeJS or a variety of web tools, you may generate crucial CSS on your own. Place this crucial CSS in the head of the page and prioritize the rest of the CSS.

Only load the styles that are appropriate for your device using media queries. Your page receives a lot of mobile traffic. As a result, you don't need to download the styles for Desktop. This saves time and shortens the lighthouse's critical request chain.

The media attribute should be used. The media property ensures that a stage is only downloaded if the media from the home differs from the media you're utilizing right now.

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

Minify: Remove any CSS that isn't in use. Many blogs and websites make use of CSS libraries like bootstrap. These libraries are frequently over-inclusive, with not all style declarations being used. Using a CSS preprocessor, you can easily alter these libraries (such as SASS ). Simply delete the unnecessary style groups and replace them with what should be included to make them much smaller. You may also use these preprocessors to minify your CSS by deleting all spaces and newlines. 

Compression: It is essential to use Brotli or GZIP compression to correctly compress stylesheets. 


By default, Javascript in the head of the page is downloaded with a high priority, preventing the page from rendering while they are downloaded and run. As a result, Javascript is an integral part of the critical request chain.

Avoid Chaining Critical Requests Jquery

<link as='script' href='' rel='preload'/>

Defer and Async

The async and defer attributes are used to adjust the priority of Javascript files by loading them asynchronously. Asynchronous script files are downloaded in parallel but with a lower priority than synchronous script files. Deferred JavaScript is also loaded in parallel, with the execution of the Javascript file postponed so that it does not interfere with the page's initial loading. 

Loading and execution of blocks

<script src="script.js">

While async does not block while loading, it does throughout execution.

<script async src="script.js">

Neither during load nor execution, defer does not block.

<script defer src="script.js">

Splitting JavaScript into many files and preloading it: If the page does not allow asynchronous loading of JavaScript, it may be a good idea to break JavaScript into numerous files. Preload the part of the JavaScript that is crucial during page loading into a tiny file. Put the non-critical javascript in an other file and run it deferred or async.

Minify: Using a JavaScript Minifier Tool, reduce the number of bytes. This is a clever tool that analyzes Javascript and compresses it to the smallest size possible.

Additionally, compress Javascript using Gzip or Brotli to reduce the number of bytes. 


The last files in the critical request chain are usually web fonts. This is because web fonts rely on user discovery. They are loaded only when a browser determines that they are required. To do so, a browser must first evaluate the HTML and then look up the font name in the style sheet.

Preloading: When you know you'll be using a typeface frequently, it's usually faster to preload it. The typeface is then downloaded as soon as feasible, which has the least amount of impact on the essential request chain. Preload a font by placing this code at the top of the page as soon as possible.

<link as='font' crossorigin='' href='' rel='preload' type='font/woff2'/>

AJAX Request

Ajax requests are given first priority at all times. As a result, Ajax requests should be postponed until the page has finished rendering. Wait until the "load" event has been sent by the page.

If deferring the AJAX request is not possible, you can ensure that it is available to the browser by preloading it.

window.addEventListener('load', (event)=>{
  console.log('this is a good time for an AJAX request');


Iframes are normally downloaded as quickly as possible. Because an iframe is a page within a page, it can add a substantial amount of time to the time it takes for a page to load. The iframe's resources may likewise be downloaded with a high priority, forming its critical request chain. As a result, the use of iframes might have a major impact on your lighthouse score.

The loading = "lazy" attribute can be used to delay the loading of an iframe. When the iframe isn't visible right away during loading, this can make a big difference. It's usually faster to use JavaScript to inject the iframe into the page. This gives you more control over time so it doesn't get caught up in the critical request chain.


It can be difficult to avoid chaining crucial requests.

After following this guide and its method, you should be able to speed up your website, and the "Avoid chaining critical request" alert should be gone when you test it with PageSpeed Insight or any other tool. 

Because page speed is the major reason you're reading this article, I strongly advise you to read our other Blogger PageSpeed Optimization articles. We've attempted to fix every PageSpeed warning, and you should be able to notice a significant improvement in your site's speed.

Next Post Previous Post
No Comment
Add Comment
comment url