The Critical Request: How to Prioritise Requests to Improve Speed

Serving a website seems pretty straightforward: send down some HTML, the browser figures out what resources to load next. Then, we wait patiently for the page to be ready.

Under the hood, a lot is going on. How does the browser decide which assets to request, and in what order?

This post covers how browsers evaluate request priority and how to alter it to improve render speed.

What is asset prioritisation?#

Modern browsers parse HTML using a streaming parser, so assets are found within the markup before it has been fully downloaded. As the browser discovers assets, it adds them to a network queue with a predetermined priority:

The priority is one of Lowest, Low, Medium, High and Highest. It tells the browser which requests matter most for the page to load quickly.

Request priority can also be seen in Chrome’s Performance tab:

How does Chrome prioritise resources?#

Resources are added to the network queue in order of appearance or discovery. The browser then dedicates network activity to fetching the Highest priority resources as quickly as possible.

Each resource type has its own set of rules that dictate the priority assigned to it:

What makes a request critical?#

Critical Request is a resource that is displayed in the initial viewport of a page.

These resources have a direct impact on Core Web Vitals metrics like Largest Contentful Paint and First Contentful Paint. Using this article as an example, we can visually identify assets that are required for the viewport to be fully rendered:

For this page, the critical requests are:

1. HTML
2. CSS
3. Logo
4. Three webfont weights
5. Leading article image (Largest Contentful Paint element)

These assets (note the lack of JavaScript) are essential to the initial viewport’s visuals. They should be loaded first.

When auditing your pages, we recommend:

• Perform a visual audit of the page, note above-the-fold critical elements.
• The first 5 HTTP requests should be: HTML + 4 Critical requests.
• Make sure no critical requests are redirected.
• Update your site to ensure critical resources are optimised, compressed, served with caching & correct HTTP headers.

Critical request chains#

When a browser makes a request because another request referenced it (also known as a dependency), we call it a request chain. Lighthouse reports chained requests in its Network dependency tree insight, which replaced the older “Avoid chaining critical requests” audit in Lighthouse 13.

One of the most common examples of a critical request chain is a stylesheet that loads a font or background image that is displayed within the initial page viewport:

@font-face {
  font-family: 'Calibre';
  font-weight: 400;
  font-display: swap;
  src:
    url('/Calibre-Regular.woff2') format('woff2'),
    url('/Calibre-Regular.woff') format('woff');
}

.carousel-bg {
  background-image: url('/images/main-masthead-bg.png');
}

Use the Network dependency tree insight to diagnose and identify resource dependencies on your page.

Reducing the number of critical request chains results in faster Largest Contentful Paint.

To reduce the impact of critical request chains:

• Reduce the number of requests
• Reduce the size of resources using compression and minification
• Mark non-critical scripts as async
• Consider inlining @font-face declarations directly into HTML
• Avoid using CSS background images or @import
• Use preload to retrieve critical resources earlier
• Look for smaller library alternatives using bundlephobia

Technique: Control request priority#

Request priority can be influenced using preload. A preloaded resource takes the priority of the destination named in its as attribute, and is fetched earlier because the browser finds it in the HTML instead of waiting for CSS to be parsed.

<link rel="preload" href="Calibre-Regular.woff2" as="font" crossorigin />

With preload, you’re telling the browser: “You might not know it yet, but we’re going to need this.”

Preload helps, but if too many resources are preloaded, page performance can deteriorate.

Preloading can impact Largest Contentful Paint and Cumulative Layout Shift. In some cases, that impact can be negative. We recommend experimenting with preloading requests, but be sure to test before and after.

Technique: Lazy loading images#

By default, browsers load all images specified in HTML, even if users never actually view them. Lazy loading allows you to specify images that should only be fetched when a user scrolls near them. If the user never scrolls, the browser won’t load those images.

With this approach, you can improve overall rendering speed and save needless data transfer. Apply it below the fold only: lazy loading your Largest Contentful Paint image delays the very element LCP measures.

Historically, we implemented lazy load using third-party libraries or hand-crafted scripts. Today, it’s built into browsers.

Here’s how it works:

• loading="lazy" attributes are added to <img /> elements that are known to appear below-the-fold.
• As the page is scrolled, deferred lazy images are loaded, ready to be displayed.

Technique: font-display#

Most sites use web fonts, and in most cases they’re providing a sub-par experience.

Everyone has witnessed fonts that appear, then disappear, change weights and jolt the page. Those shifts are now measured by Cumulative Layout Shift metric.

As shown with <link rel="preload">, fetching fonts earlier has a large effect on render speed.

CSS font-display controls how text displays while web fonts are being requested and loaded.

There are five font-display options at your disposal. We recommend the swap option, which immediately renders text, then replaces the webfont as soon as it has loaded.

Given this font stack:

body {
  font-family: Calibre, Helvetica, Arial;
}

The browser will display Helvetica (or Arial, if your system doesn’t have Helvetica installed) until the Calibre font has loaded.

Without font-display#

Text appears after the HTML, CSS, and webfonts are loaded:

With font-display: swap#

Text appears as soon as the HTML is downloaded and evaluated, yielding a 1.6 second improvement:

font-display is supported in every current browser.

Critical Request checklist#

You should now be able to select the most critical assets for your site and prioritise them. To go further:

• Enable the Priority column in Chrome Developer Tools.
• Reduce the number of required critical requests where possible.
• Audit which requests must be made before users can see a fully rendered page. Prioritise these critical requests with <link rel="preload" />.
• Use link prefetching for assets that are likely to be used on the next navigation.
• Use Link Preload HTTP headers to declare resources to be preloaded before the HTML is fully delivered.
• Ensure image dimensions are correctly sized.
• Use Inline SVGs for Logotypes and Icons.
• Use better image formats like AVIF or WEBP.
• Use font-display: swap to display text on the initial render.
• Use compressed font formats like WOFF2 or variable fonts.
• Capture Chrome’s network events with chrome://net-export, then open the log in the NetLog Viewer.