fetchpriority and preload for the LCP Image: When They Help

fetchpriority="high" on the main image and <link rel="preload"> in the document head are two of the most common recommendations for a faster Largest Contentful Paint. Can we measure their effect in a controlled lab, and under which conditions do they help? We ran 224 page loads across two protocols, two levels of competition and five variants. The result was not the one we expected, and the reason is as useful as the number.

The test

The page shows a 1600 × 900 hero photo (CC0, WebP, 145 KB) after a row of six other images that appear earlier in the HTML, so that they compete with the hero for bandwidth. Two levels of competition:

• Light: six 480-pixel thumbnails (about 110 KB together).
• Heavy: six 1024-pixel photos (about 390 KB together).

Five variants change only the hints: a baseline with none; fetchpriority="high" on the hero; a <link rel="preload" as="image" fetchpriority="high"> for the hero; the hero with loading="lazy"; and, for heavy competition, fetchpriority="low" on the six other images. Every variant was served over HTTP/1.1 and over HTTP/2 (with TLS) from a local server and loaded seven times per viewport in fresh Chrome 155 profiles on our slow mobile profile (150 ms latency, 1.6 Mbit/s, 4× CPU). We recorded LCP, the priority Chrome assigned to the hero request and when its download started and ended (methodology).

What went wrong first: our first version of the script read the timing of a 480-pixel thumbnail of the same photo instead of the hero, because both file names started with the same word. The LCP values were correct, but the request times were not. We fixed the script and re-ran every variant.

Results

The hints changed the priority, not the outcome. Without hints, Chrome first gave the hero request Low priority, as it does for images before layout. With fetchpriority="high" or the preload, the hero was requested at High priority, as documented. But in every one of the eight conditions, the median LCP of all variants fell within about 20 milliseconds of each other, well inside the spread between repeated runs. With light competition LCP was about 1.7 seconds and with heavy competition about 3.1 seconds, whatever the hints.

The download timings show why. In every variant, the hero request started at about the same moment (170–260 ms after navigation), and it finished at almost the same time regardless of its priority, because it shared the connection equally with the other images until all of them were done. Even lazy-loading the hero, which delayed its request by 50 to 65 ms, made no difference to LCP here, unlike in our lazy-loading test where twelve images competed.

Why a lab like ours cannot show the benefit

Priority hints work by changing the order in which the server sends data when the network is the bottleneck. In our test, the bottleneck was artificial: Chrome’s built-in network throttling sits inside the browser and shares the simulated bandwidth between requests, while the local server hands over every byte almost instantly. So the server never had a queue to reorder, and the browser’s throttle did not favour high-priority requests. HTTP/2 did not change that.

That has two consequences. First, a negative result from DevTools-style throttling does not prove the hints are useless on real networks, where a server or CDN that honours priorities can send the hero first. Second, a positive result from the same kind of lab would be just as suspicious. To measure these hints you need a real constrained connection (a real phone network, or traffic shaping between a remote server and the device) or, better, field data from real visitors.

Practical conclusion

• Adding fetchpriority="high" to the one image that is your LCP element is cheap and correctly raised its priority in Chrome 155. Do not add it to several images: priority is relative.
• Do not expect a lab with simulated throttling to show the gain. We could not measure one in 224 loads over HTTP/1.1 or HTTP/2.
• The changes that did move LCP in our lab were structural: not lazy-loading the hero when many images compete, keeping its URL in the HTML rather than in an external stylesheet (CSS background test) and sending fewer bytes (srcset test). Fix those first.
• Judge priority hints with field data, such as the LCP your real visitors experience, before and after the change.

Repeat this test on your own images

If you want to evaluate priority hints on your own site, use measurements from real visitors rather than a throttled lab. Chrome’s User Experience Report (visible in PageSpeed Insights for sites with enough traffic), or your own analytics with the web-vitals library, will show whether the LCP of real visitors changes after you add fetchpriority="high". In the lab, you can still confirm that the hint is applied: open the Network panel, add the Priority column, and check that the hero request is listed as High from the start. Our script run_loading.mjs (the priorityall step) contains the HTTP/1.1 and HTTP/2 servers and the five variants used here, if you want to reproduce the negative result.

Limitations

A local server, simulated throttling and one browser version. We did not test a real mobile network, a CDN with priority scheduling, or HTTP/3. Those are exactly the conditions where the hints are expected to matter, and where we would like to test them next.

Data and files

Download loading-priorityall.csv (32 rows, 6.7 KB) · Method: testing methodology. Photos: image credits.