Chaining critical requests can have a significant impact on your website's performance and impact page load metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP).
The browser having to wait for a resource to finish loading before being able to load the next request leads to content rendering slower. This can be a frustrating experience for the user and affect SEO rankings.
In this article, we'll explore strategies to optimize critical requests to improve page load times.
What is a critical request?
A critical request refers to any resource that is essential for rendering the content of a web page. These typically include CSS and JavaScript files that must be fully loaded before the browser can display the page to the user.
If these resources are delayed or take too long to load, the entire page rendering process is stalled. These requests are considered render-blocking because they prevent the browser from completing the task of painting the content on the screen.
Why critical requests should not be chained
As mentioned earlier, critical requests are essential for rendering a page. When these requests are chained, content delivery will be delayed. Each dependent request in a chain adds to the overall delay.
Identifying request chains in Lighthouse
One of the key steps in optimizing page load is being able to view the request chain. Lighthouse includes an audit called "Avoid critical request chains", which provides the number of chained requests in the performance recommendations.
Viewing the request chains helps to identify bottlenecks makes and optimizing the loading sequence much easier.
How to avoid chaining requests
Here we can see an Lighthouse test result with just one critical request chain. Almost every resource is linked directly to the initial HTML document request. This structure minimizes delays and allows the page to load quickly.
There are several optimizations that have made this single request chain possible. The first optimization is preloading the fonts. When a request is preloaded, Lighthouse does not consider the request to be part of the critical request chain.
JavaScript files have been deferred so they don't block page rendering and only run after the HTML is loaded. Using defer or async on JavaScript requests prevents these requests from blocking the rendering process, so these requests aren't critical.
Lastly, the LCP image is requested directly from the HTML document. Ensuring that this critical resource loads as soon as possible. While this request isn't considered critical by Lighthouse, it's still important for user experience.
Along with the strategies in this example, other techniques can help avoid chaining critical requests or reduce its impact, such as:
-
Minifying CSS and JavaScript: Reduce file sizes to make critical resources load faster, minimizing delays. This is known as reducing the number of critical bytes.
-
HTTP/2 Multiplexing: Use HTTP/2 to send multiple requests in parallel over a single connection, reducing wait times for resources.
-
Lazy Loading: Load non-essential elements like images and videos only when they’re needed, keeping the critical request chain shorter.
-
Prefetch and Preconnect: Anticipate future requests by prefetching resources or pre connecting to external domains, so resources load faster when needed.
Now we understand how critical request chains work and how they can be reduced or optimized. Let’s take a look at some real world examples based on DebugBear speed tests.
Example 1: Defer JavaScript requests
One of the most effective ways of reducing critical chains is by deferring JavaScript requests. When using defer, the browser downloads the JavaScript file in the background without blocking the rendering of the HTML. This means the browser can continue to render the page while the JavaScript is being fetched.
On this page we can see several JavaScript requests that are render blocking.
With DebugBear, we can run an experiment to defer these JavaScript requests.
After running the experiment and analyzing the request waterfall, we can see only one of the JavaScript requests remaining as a critical request. Most notably, all of the previously highlighted requests are now non render blocking.
Now that the JavaScript requests have been deferred, the page is able to load sooner. The FCP score has improved by 750 ms and the LCP score has improved by almost 1 second. This optimization leads to a better experience for the user as content is being provided faster.
Example 2: CSS import chain
On this page we can see many render blocking requests which prevent the page from rendering sooner.
Looking at the final render blocking request, we can see that there is a CSS import. The request chain shows that once the build/style.css request has finished, the fonts.google request can begin.
After running an experiment preloading the stylesheet, we can see that the request has now become non-blocking and is no longer part of the request chain.
This has resulted in the FCP improving by over 500 ms.
Conclusion
In conclusion, avoiding chained critical requests is key to better web performance. Strategies like deferring JavaScript, preloading resources, and loading the LCP image directly from the HTML help improve page load times.
DebugBear can automatically highlight potential optimizations for your website. Some of these recommendations can be tested with an experiment, including deferring scripts and preloading resources.
DebugBear is a page speed testing tool that helps you keep track of your website performance in the lab and with real-user analytics.
Start your free 14-day trial and start optimizing today.