fetchpriority

fetchpriority is an attribute that lets you override the browser’s own guess about how urgent a download is. It takes three values, high, low and auto, and it works on <img>, on <link rel="preload">, on <script> and on fetch(). It does not make anything download faster. It changes the order things are asked for, which on a throttled connection is most of what “faster” means.

What the browser guesses when you say nothing

Chrome assigns every request an internal priority from its own heuristics, and for images those heuristics are cautious by design. An image starts at a low priority, because at the moment the request is queued the browser does not yet know where the image will land on the page. Only after layout does it discover which images are in the viewport and raise them.

That delay is the whole problem. The hero and the footer icon are queued together, as equals, during exactly the window that decides your LCP.

Almost nobody sets it, and platform decides who does

This is the most common single correction our proxy makes. In our snapshot of audited sites (2026-07-23), the share where the largest above-the-fold image carried no priority of its own:

Platform	Main image not prioritised
Duda	48 of 49
Wix	24 of 30
Bitrix	24 of 30
WordPress	43 of 57
Webflow	22 of 32

The exception is instructive. When we went back through the 261-site hero study and looked at the pages where our filter found nothing to do, 16 of the 18 Squarespace and Wix sites in that group had already set fetchpriority="high" themselves. Their platform does it for them, which is why we find no work there and why their apparent “problem” in a raw count is an artefact of the job being finished.

Two ways it does nothing at all

Being honest about the limits is what keeps the attribute from being cargo-culted:

• If the element is not in the served HTML, no hint helps. A priority is a fact about a request the browser knows how to make. When the hero arrives only after JavaScript runs, the preload scanner has nothing to hint at, and the fix is architectural rather than one attribute.
• If everything is high, nothing is. Priority is relative. Marking six assets high divides the same bandwidth six ways and can push your first paint later, not earlier. Our own pipeline caps how many high-priority hints it will inject per page for exactly this reason.

In code

On the hero image itself, and on a preload for a background the scanner cannot see:

- <img src="/hero.webp" alt="…">
+ <img src="/hero.webp" fetchpriority="high" alt="…">

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

The inverse is just as useful and much less used. Deprioritise things that are visibly important to a designer and not to the first paint, such as a carousel’s second slide:

<img src="/slide-2.webp" fetchpriority="low" alt="…">

What WebSpeed does with it

We detect the real above-the-fold image, mark it fetchpriority="high", remove any loading="lazy" it was carrying, and add a matching preload. The count of hints per page is capped, and the whole step is skipped when a JavaScript slider owns the first screen, because there the largest paint is drawn by code and the first static image is somewhere below the fold.