Using fetchpriority to move Largest Contentful Paint

What fetchpriority does

fetchpriority is the browser hint that tells it which resources matter most, and fetchpriority="high" on the Largest Contentful Paint image asks the browser to prioritise fetching that image over lower-priority resources such as below-the-fold images or scripts that are not blocking.

<img src="/hero.webp" width="1200" height="800" fetchpriority="high" alt="Office interior">

The hint matters because a browser has a finite network priority budget early in page load. The LCP image competes with fonts, scripts, and other images for that budget, and by default an image discovered late can wait behind items the browser considered more urgent. Giving the LCP image high priority pulls its fetch forward.

The distinction that keeps the fix honest

A priority hint changes when a resource is fetched, not how much it weighs. This is the same distinction as the preload hero article makes, and it is worth stating plainly because it is the most common source of wrong advice:

• fetchpriority="high" affects fetch order and whether the request can start earlier.
• It does nothing about the image's size, so a hero that is 400 KB stays 400 KB, and the LCP optimisation article is where real byte savings come from.

A priority hint is only the tie-breaker that lets an already-lean image get fetched promptly. If the image itself is slow, hinting it early helps the browser start it sooner, but the old advice stands: it is the actual LCP element and its weight that dominate the metric.

When it objectively helps, and when not

Add fetchpriority="high" to the LCP image only, and remove it from non-LCP images, because an attribute on a below-the-fold image that is not the LCP candidate merely demotes the items that genuinely need priority:

• Helps: a hero or first-content image that is clearly the LCP candidate, loading above the fold alongside slower resources; the hint lets it start fetching in parallel with the critical path.
• Little effect: text-only LCP where no image is the LCP element, or a tiny image where the fetch was already fast.
• Harms: broad use across several images dilutes the priority signal, and a high on a non-LCP item can push fonts or scripts later.

Practice is to confirm the LCP element first, because the web performance audit and the LCP debugging tell you what the actual LCP is rather than guessing. fetchpriority and preload overlap but are not the same, and for an image the attribute is usually the right tool, while a <link rel="preload"> is the heavier intervention reserved for cases where you also need to force the discovery order.

Verifying the effect

1. Identify the LCP element on the page you care about.
2. Add fetchpriority="high" to that image.
3. Compare LCP before and after over a small set of runs, being careful the network and cache conditions are comparable.
4. Keep an eye on overall page timing, so the gain to LCP is not paid for elsewhere.

A single fetchpriority="high" on the true LCP image is a cheap, well-supported step that moves a real-world share of pages. Pair it with the byte-level and render work and a full audit and it becomes part of a coherent performance posture rather than a magic attribute.