Fetchpriority to improve the wpo
WPO, or Web Performance Optimisation, involves finding and implementing ways to make a website faster and more fluid without compromising the content that the user ultimately receives.
One often-overlooked aspect of WPO is that it is not solely about improving each individual element downloaded by the user. The order in which elements are downloaded and executed in the browser is also a crucial factor in enhancing the user experience and the perception of speed and responsiveness.
For this reason, technical SEOs frequently work with preloading and deferred loading strategies.
By default, the order of resource loading is determined by what the browser encounters when parsing the initial HTML. The browser assigns priority based on the resource's weight and type. While browsers generally attempt to optimise this process for the best experience, they do not always do so in the most efficient way.
In addition to various preloading methods such as preload, prefetch, and preconnect, there is a technique called FetchPriority, which is applied as an attribute within HTML tags.
However, this attribute can be difficult to understand and implement correctly, so I will simplify it for clarity.
Fetch Priority modifies the default priority assigned to an HTML-marked element based on its relevance and importance in resource loading.
A key point to consider is that while browsers are generally effective at establishing priorities, they are sometimes unaware of an element’s importance until they encounter it. In some cases, whether initially or later in the process, they may assign an incorrect priority.
Would you like to check the priority of elements on your website?
You can use Chrome DevTools > Network > Settings > Large Request Rows and enable the priority column to view the difference between initial and final priority assignments.
Understanding this information helps identify which elements may require priority adjustments, complementing our expertise in making well-informed decisions.
It is essential to understand how browsers assign default priority to elements. Before using such a powerful modifier, we must be aware of the typical priorities for different elements.
The “very high” and “high” priorities are activated during the “Layout Blocking Phase” (LBP), meaning we must be cautious not to overload this phase with excessive resources.
The Layout Blocking Phase (LBP) in web rendering refers to the part of the process where the browser delays the visual presentation of a page due to the loading and execution of certain resources, particularly CSS and scripts that affect layout.
Fetch Priority is simply an HTML attribute that applies to link, img, or script elements—typically those associated with heavy multimedia files.
There is no official documentation regarding its use with iframe elements. While lazy loading does work for iframes in most browsers, FetchPriority does not seem to have a defined standard for iframes.
The Fetch Priority attribute has only three possible values:
Examples:
<img src="/images/logo.svg" fetchpriority="high"><link href="/css/styles.css" fetchpriority="low"><script src="script.js" fetchpriority="high"></script>
It is important to note that the impact of Fetch Priority on resource loading depends entirely on the browser being used.
In other words, while Fetch Priority is an HTML standard, it serves as a suggestion rather than a directive. The browser attempts to respect the developer’s preference but may also apply its own resource prioritisation logic to resolve conflicts.
These elements have their own automatic designation and a default loading priority. Below, I have included a table showing how Chrome assigns priority and how these attributes affect it. For instance, if there is a <link> tag with a CSS file in the <head>, using the fetchpriority="low" attribute will not reduce its priority to load after the design-blocking phase.
To better understand the upcoming table, which outlines the priority of each element and how we can modify it, we will divide these five priority levels into two phases: the LBP (Layout Blocking Phase) and the post-LBP phase.
This means we can adjust the priority of elements to load before the visual rendering occurs—improving CLS—or delay an element’s loading to avoid impacting LCP.
Since each element has a different default priority, we cannot freely change an element’s priority, but rather, we can only make a suggestion. Each element has a limited "priority adjustment range." Let’s explore how we can work with each of them.
| Load before LBP | Load after LBP | ||||
|---|---|---|---|---|---|
| Priority | Very High | High | Intermediate | Low | Very Low |
| Main Resource | ◉ | ||||
| CSS (early**) | ⬆◉ | ⬇ | |||
| CSS (late**) | ⬆ | ◉ | ⬇ | ||
| CSS (@media not affecting***) | ⬆ | ◉⬇ | |||
| Script (early **) | ⬆◉ | ⬇ | |||
| Script (late**) | ⬆ | ◉ | ⬇ | ||
| Script (async/defer) | ⬆ | ◉⬇ | |||
| Font | ◉ | ||||
| Image (viewport/above the fold) | ⬆◉ | ⬇ | |||
| Image (first 5 images > 10,000 px2) | ⬆ | ◉ | ⬇ | ||
| Image | ⬆ | ◉⬇ | |||
| Multimedia content (video/audio) | ◉ | ||||
While there are countless possibilities, here are a few examples.
Preload allows you to inform the browser about resources you want to download and load before the browser naturally discovers them. This is particularly useful for fonts loaded via an external CSS file, enabling their download and rendering earlier in the process.
However, preloading is not always advisable. Sometimes, we only want to indicate whether a resource is initially important or not when the browser encounters it.
It is crucial to distinguish between load priority and preload, as:
Preloading is mandatory.
Preloading initiates downloads earlier but does not change priority.
Fetchpriority only changes priority, not visibility.
Sometimes, fetch priority is preferable; other times, preload is the better option—it depends on the context.
Although Google’s documentation states that they can be combined, it is not always recommended.
Using preload with fetchpriority can be contradictory and should be implemented with caution. Testing in a local environment is essential to determine whether it is optimal and necessary (across all browsers used by your audience).
The script implementation shown below should not be merged with the attribute in the documentation, as they cover slightly different topics. The underlined section of the documentation indicates: "I want the resource to be downloaded before it is needed in the DOM," but "I want the priority to be low." In other words, "be a priority, but not too much."
While it may serve to slightly lower priority among critical resources, it is not the best practice. If something is critical, it should be prioritised accordingly. If not, it should not be prioritised at all. If you want to lower an element’s priority, consider whether it needs a preload in the first place.
The loading attribute determines when an element is retrieved, while fetch priority determines how important it is to retrieve it.
According to CanIUse, it is compatible with the most widely used modern browsers:
Fetchpriority is yet another tool for improving the speed and performance of our websites, thanks to the standardisation of these attributes by the leading web browsers.
It is not an attribute that must always be implemented, but it can be highly useful—for instance, for hidden images in a navigation bar or sliders, or for scripts that load after an element in order to function, but whose code affects the layout, potentially harming user experience.
The world of WPO is vast and complex, and understanding all these tools that allow us to gain small performance advantages provides flexibility in our web optimisation strategies, ensuring sites remain fast without compromising functionality.
I currently offer advanced SEO training in Spanish. Would you like me to create an English version? Let me know!
Tell me you're interestedIf you liked this post, you can always show your appreciation by liking this LinkedIn post about this same article.
