Speed Lab: fetchpriority and finding the main image

The question

web.dev's guide to Largest Contentful Paint says that two things decide how soon the main image starts to load: when the browser finds it, and what priority the browser gives it. I tested both on the same page, with nine Lighthouse runs for each variant. The first test changes how the image is found: as a normal img in the HTML, as a CSS background, or inserted by a script, with and without a preload. The second test changes the priority of the image on a page where other images compete with it.

The 2025 Web Almanac gives the setting. fetchpriority="high" was on 17% of mobile pages that had an image as their Largest Contentful Paint element, and rel="preload" on about 2%. The Almanac adds that preload is only necessary when the image is not quickly discoverable in the HTML document, and that it should then be paired with fetchpriority="high".

How I tested it

I used the method set out in how the Speed Lab tests are run, and the lazy-loading lab has the script for running it yourself. In short: Lighthouse 13.5.0 and a headless Chrome for Testing 153, the Lighthouse mobile preset with devtools throttling (a 562.5 ms delay on each request, 1,474.56 Kbps, a processor four times slower, a 412 by 823 screen), and a small Node server on the same machine sending plain HTTP/1.1 with no compression and no caching. Tests 1 to 3 use that setup. Test 4 uses a shaped network, which it describes. The hero is a generated JPEG of 1,200 by 675 pixels and 189,585 bytes, with width and height set. Each variant ran nine times, taken in turns, and the tables show the median with the lowest and highest run in brackets.

Test 1: how the image is found

The page has a header, a heading, the hero, a paragraph, a small style sheet and a 52 KB script with defer. Six variants:

<!-- a. a normal img in the HTML -->
<img class="hero" src="hero.jpg" width="1200" height="675" alt="Spring collection">

<!-- b. the same, with a high priority -->
<img class="hero" src="hero.jpg" width="1200" height="675" alt="Spring collection" fetchpriority="high">

<!-- c. a CSS background: .hero-box { background: url(hero.jpg) center/cover } -->
<div class="hero-box" role="img" aria-label="Spring collection"></div>

<!-- d. the same, with a preload in the head -->
<link rel="preload" as="image" href="hero.jpg" fetchpriority="high">
<div class="hero-box" role="img" aria-label="Spring collection"></div>

<!-- e. an empty slot that app.js fills with the img after it has run -->
<div class="hero-box" id="hero-slot"></div>

<!-- f. the same, with the preload in the head -->
<link rel="preload" as="image" href="hero.jpg" fetchpriority="high">
<div class="hero-box" id="hero-slot"></div>

Results

First Contentful Paint was between 1,212 and 1,221 ms in every variant, Total Blocking Time and Cumulative Layout Shift were 0, and the page weight was 237.6 KiB for all six. Only the moment the image arrived changed.

Three results stand out.

1. `fetchpriority="high"` made no difference here. Variants a and b are within the noise of each other.
2. A CSS background cost about 300 ms and a script-inserted image cost about 590 ms. Their ranges do not overlap with variant a.
3. A preload brought both back to the baseline. Variants d and f are within 10 ms of variant a.

When the request started

The timeline in the Lighthouse report shows why. These are the median times, in milliseconds from the first request.

The normal image is requested at 613 ms, together with the style sheet and the script. The CSS background cannot be requested until the style sheet has arrived and been read: its request starts at 1,189 ms, 8 ms after the style sheet finished. The script version waits for the script to run: its request starts at 1,481 ms, 18 ms after the script finished. A preload in the head puts the request back at about 611 to 616 ms.

This matches web.dev's description. It lists the cases where the browser cannot find the image from the HTML alone: an img added by JavaScript, an address hidden in data-src and a CSS background. In each, the browser must run the script or apply the style sheet first. For those cases web.dev's advice is to preload the image with a high fetch priority.

What Lighthouse said

The "LCP request discovery" insight in Lighthouse 13.5 checks three things: whether fetchpriority="high" is applied, whether the request is discoverable in the first HTML, and whether the image is not lazy-loaded. Its score is 1 only when all three pass. Variants b, d and f scored 1 in all nine runs. Variants c and e failed the second check. Variant a passed the second and third checks and failed the first, so its score was 0, although it was as fast as variant b.

The same test on a shaped network

A chain of requests, such as the style sheet and then the image, looks long in the lab, which adds 562.5 ms to each request. So I ran the six variants a second time on the shaped network of Test 4 below, five runs each.

The preload still took away all of the cost. The cost itself was smaller, and for the CSS background it fell inside the noise: 16 ms against 298. The hero is 189 KB on a link of 1.6 Mbit/s, so the page is limited by the link. The CSS background asked for the hero 174 ms later, but the link was busy with the script in the meantime, and the hero finished at about the same time. A late request costs most when the link would otherwise sit idle. The script-inserted image still lost 258 ms, because the script that adds it finishes later than the style sheet does.

Test 2: priority on a crowded page

The first page had no competition, so a priority hint had little to decide. This page has six thumbnails, each about 53 KB, in a two-column grid under the hero. All six sit inside the first screen of the test phone, so the browser treats them as important too. The pages are otherwise the same: the style sheet, the 52 KB script and the 189,585-byte hero, in 550.4 KiB and 11 requests, one of them the favicon. Four variants:

<!-- a. default: no hints -->
<img class="hero" src="hero.jpg" width="1200" height="675" alt="Spring collection">
<img src="thumb1.jpg" width="600" height="400" alt="Sample 1"> <!-- and five more -->

<!-- b. high priority on the hero only -->
<img class="hero" src="hero.jpg" width="1200" height="675" alt="Spring collection" fetchpriority="high">

<!-- c. low priority on the six thumbnails only -->
<img src="thumb1.jpg" width="600" height="400" alt="Sample 1" fetchpriority="low">

<!-- d. both -->

The four ranges overlap completely. The hints did not change when the hero arrived.

The timeline shows that the hints did change something. In the default page, the browser rated the hero and all six thumbnails High, and requested the first three thumbnails at the same moment as the hero, at about 620 ms, and the last three at about 1,200 ms.

When I marked the thumbnails Low, the browser still requested the first four thumbnails as before, but it held back thumbnails 5 and 6 until about 2,700 ms. The hero was requested at 617 ms in both pages, and it finished at 4,190 ms in both. Over plain HTTP/1.1 with Lighthouse's throttling, the hero shares the limited connection with whatever else is downloading, and delaying the last two thumbnails did not shorten its download. I did not work out why. What I can say is that the hint changed the order of the queue and not the result.

Two points follow. Chrome already treats images that sit in the first screen as important, so a hint on one image of several equals gives little. And over HTTP/1.1 with this throttling there is nothing for a server to schedule: the limit is applied inside the browser, after the bytes have arrived. Test 4 repeats the page over HTTP/2 with a server that follows priorities. This result is "no effect in this setup", not "never an effect". web.dev's advice stands: use the hint on the one or two images most likely to be the main element, and check the effect on your own page.

Test 3: the CSS background on the crowded page

Test 1 found that a CSS background costs time on a page with nothing else to load. I repeated it on the crowded page of Test 2, with the hero as a CSS background in the first four variants and the plain img as the reference.

The background cost 366 ms more than the plain image, close to the 298 ms on the page with nothing else. The request for it started at 1,210 ms, 20 ms after the style sheet finished. With a preload it started at about 615 ms. The preload took away all but 18 ms of the cost. The high priority on the preload added nothing measurable: 13 ms, inside the noise. The thumbnails at low priority changed nothing further.

Test 4: the crowded page over HTTP/2, on a shaped network

The tests above ran over HTTP/1.1 with Lighthouse's usual throttling, which limits the download inside the browser, after the bytes have arrived. A server's choice of what to send first cannot show there. So I ran the crowded page of Test 2 again on a shaped network: a round trip of 150 ms, one download link of 1,638.4 Kbps shared by all connections, and slow start. The test of many small files has the details and the code. I used HTTP/1.1, and HTTP/2 from Hypercorn, a server that schedules its responses by the priorities the browser sends. Seven runs per variant.

Three results stand out.

1. Over HTTP/1.1 the hints changed nothing, as in the first tests: about 3,345 ms in all four variants. The hero is the biggest file on a link shared by up to six connections, and it finishes last whatever the order of the queue.
2. HTTP/2 brought the main image in 1,171 ms sooner with no hints at all (2,175 ms against 3,346 ms).
3. Marking the six thumbnails as low priority helped by a further 264 ms (1,911 ms against 2,175 ms). In six of the seven runs of each variant the two do not meet: the default page finished its hero at 2,142 to 2,162 ms, and the page with low thumbnails at 1,882 to 1,908 ms. A few runs of three variants finished the hero near 1,650 ms, and I did not find out why. fetchpriority="high" on the hero did not help: its median was later (2,425 ms) and its runs were spread from 1,671 to 3,457 ms.

The request timelines show what the server did. In the default page the hero, the first thumbnail and the 52 KB script finished together at about 2,150 ms, the second thumbnail followed at 2,400 ms and the last four at 3,420 ms. With the thumbnails marked low, the hero and the script finished together at 1,887 ms, and the thumbnails came after them, from 2,140 ms to 3,410 ms. The hint changed what the server sent first, which is what it is for. Lighthouse's usual throttling could not show this: with Node's HTTP/2 server the median LCP was 4,223, 4,229, 4,224 and 4,217 ms in the four variants.

What these tests do not show

• A small, simple page. Real pages have more files competing, a CDN, compression and HTTPS, so the size of any gap will differ.
• A quick style sheet. The CSS background and the script-inserted image had to wait for it. A bigger or slower one would lengthen the wait. That is my reading of the timeline, and I did not measure it.
• Lab conditions. A simulated phone on a simulated network, in one browser build, says little about your visitors. See lab data and field data.
• A generated image. Its bytes decide how long it takes to arrive, but its picture does not matter.
• One HTTP/2 server. Test 4 used Hypercorn. Other servers and CDNs order files in their own ways, as the test of many small files shows, and a hint works only where the server acts on it.
• Other browsers. They set priorities in their own ways.

What Chrome does with priorities by itself

In a separate check of ten tiny pages in Chrome for Testing 153, I recorded the priority of the hero request. A plain img started at Medium and rose to High once layout showed it was in the viewport. fetchpriority="high" started it at High. A CSS background, a script-inserted image and a bare preload all started at Low and rose to High later. loading="lazy" started at Low and stayed there. The image attributes cheat sheet lists all ten cases. These are observations of one browser build, not rules.

What to do

1. Find your LCP element. The Lighthouse report names it.
2. Make it a real `img` in the HTML, with its address in src and its size in width and height.
3. If it must be a CSS background or must be added by a script, preload it in the head with fetchpriority="high".
4. Add `fetchpriority="high"` to the one image that is likely to be the LCP element, after checking that it helps your own page. Do not add it to many images.
5. If many images compete in the first screen, such as a grid of thumbnails, mark the ones that matter less with fetchpriority="low". Over HTTP/2 this moved the main image 264 ms sooner in Test 4, and over HTTP/1.1 it did nothing. Measure it on your own page.
6. Read Lighthouse's "LCP request discovery" insight as a prompt to check, and use your own measurement to decide.

See how to fix a slow LCP and resource hints for the full set of steps.

Mistakes to avoid

• Putting the main image in CSS because it was convenient for the design.
• Preloading without `fetchpriority="high"`. The Almanac notes that a bare preload does not guarantee a high priority.
• Adding `fetchpriority="high"` to many images. If everything is high, nothing is.
• Trusting a single run. The ranges in the tables above show how much the same page moves.

Check your own page

Run the free audit and find the Largest Contentful Paint element. Check whether it is an img in the HTML. If it is a background or is added by a script, add a preload, run the audit again and compare the time.

Sources

• Optimize Largest Contentful Paint on web.dev: discovery and priority as the two factors, the cases where the browser cannot find the image from the HTML, and the advice to preload with a high fetch priority.
• Performance chapter, Web Almanac 2025: the use of fetchpriority="high" and preload on LCP images, and the note that preload is only needed when the image is not quickly discoverable.
• The Lighthouse 13.5.0 "LCP request discovery" insight and its checks, as reported on the test pages.
• Network throttling in the Lighthouse documentation: simulated, request-level and packet-level throttling, and how to run Lighthouse with a shaper in front of it (Test 4).