Loading the most important resources first is key to improving website performance. However, even when resources are correctly prioritized, servers don't always adhere to the request priorities provided by the browser.
In this article we'll take a look at how server-side prioritization support impacts page load time, how well different content delivery networks support HTTP prioritization, and what browsers and developers can do to work around server limitations.
Request priorities and web performance
When loading a website, browsers request many different resources from the server. Each of these has a request priority between Low and Highest.
For example, a stylesheet that's required to start rendering page content will be high-priority. In contrast, most images are low-priority by default.
This request waterfall shows an example of different resources downloaded during the page load process, along with the priority of each request.
Unimportant resources can outcompete more important requests, delaying the page load process.
This can happen for two reasons:
- The browser assigns an incorrect priority to the request
- The server doesn't adhere to the priority provided by the browser
When the browser doesn't correctly guess the priority, developers can use the fetchpriority HTML attribute to tell it to load a specific resource earlier.
However, in this article, we'll take a look at the second reason low-priority requests can delay high-priority requests.
HTTP prioritization
Since HTTP/2, the HTTP protocol supports multiplexing. That means the ability to load multiple resources over the same server connection.
Ever since, HTTP has also included support for specifying the priority of a resource. This request priority is determined by the browser and the server then knows what order to send response data in.
Here's an example of how that works in practice. On our test page, we have a high-priority image at the top, and a low-priority image a bit further down.
You can see when data chunks for each resource arrive in dark blue. Both requests start at the same time, but the server sends the response data for the high-priority request first.
What happens when servers don't correctly support HTTP prioritization
In our previous example everything worked as expected. But when we serve the same page from different serves that's not always the case!
Instead, we see that both files are downloaded at more or less an equal rate.
This also impacts what users see:
- It takes almost twice as long for the main image to finish loading
- The secondary image starts rendering at the same time
I first learned about server-side HTTP prioritization at performance.now() in 2023: you can find Robin Marx's amazing presentation on Resource Loading at the Cutting Edge on Youtube!
What does HTTP prioritization support look like today?
Hasselt University published a paper on real-world HTTP/3 prioritization support in 2024. Here's the key table showing what aspects of HTTP prioritization different servers and content delivery networks (CDNs) support.
Many widely used platforms don't fully support correct prioritization.
In addition to the priority the browser provides when first requesting a resource, priority changes are also common on the web. For example, once the page starts rendering the browser might realize that an image is in the viewport and increase its priority. Or more simply, the user might scroll down the page causing new images to enter the viewport.
Even when a server supports setting the initial priority it might still not support later priority changes.
The table above shows support for HTTP/3 prioritization support, and HTTP/2 support might look different. HTTP/2 also had many issues with request priority support, although the data I could find wasn't updated since 2018.
What this means for browsers and developers
In practice, correct HTTP prioritization can't always be relied upon. That means sometimes it's best to avoid making a request entirely. A server that doesn't know you want to load a specific file won't use up any bandwidth to send it to you!
Tight mode in browsers
Many browsers divide the page load process into two separate phases: tight mode and a later loading phase.
During tight mode the browser avoids requesting low-priority resources and instead only tells the server about the files it thinks are most needed.
That shows up as "wait time" in a request waterfall. The browser is waiting for other resources to finish loading before making additional requests.
Lazy loading and JavaScript logic
In theory you could expect images below the fold to not delay above-the-fold content. But in practice, deferring off-screen images can be an effective strategy to improve page speed.
Likewise, prefetched resources are low-priority, but prefetching can still have a negative impact on the initial page load.
How to test HTTP prioritization on your own website
Page speed testing tools like the DebugBear website speed test or WebPageTest can show you the priority of each resource and when different data chunks arrive.
Make sure to use a low-bandwidth (usually mobile) connection for testing, as it can be difficult to see on a fast network.
Conclusion
Assigning the right request priority in the browser isn't enough to ensure correct load order. Your server or CDN also needs to correctly support HTTP prioritization.
If you are working on web performance optimizations, try out DebugBear to measure and optimize your page speed.
Monitor Page Speed & Core Web Vitals
DebugBear monitoring includes:
- In-depth Page Speed Reports
- Automated Recommendations
- Real User Analytics Data