fetchpriority: Speed Up LCP with Priority Hints

When loading a page the browser is a planner that assigns each resource a priority and decides what loads first. For images it applies a blanket assumption: they start at low priority, because many images sit below the visible area or are hidden in collapsible menus. Only once the browser has computed the layout and recognizes that an image is visible in the viewport does it raise the priority afterwards (web.dev). That promotion, however, comes late -- the browser must first process the CSS and compute the layout before it knows which image is visible.

For the LCP image this is a problem. It is the largest and therefore most important image for the first impression, yet it is initially treated like any other. In the network waterfall this shows as a long gray bar: the browser already knows the resource but has not begun the download because other, higher-rated resources take precedence (DebugBear). Only after the first render does the priority switch from low to high -- and precious time has passed before the most important image even begins to load.

The fetchpriority attribute tells the browser the relative importance of a resource before it has computed the layout. The value high pulls a resource forward, low pushes it back, auto leaves the default decision to the browser. Set on the LCP image, fetchpriority='high' makes the browser recognize its importance immediately and load the image right after the document request, instead of queuing it behind lower-rated resources. In the waterfall the long gray waiting bar disappears, and the priority no longer switches from low to high -- it is high from the start (DebugBear).

The effect is documented in several cases. In a test with a flight search the hint improved the Largest Contentful Paint from 2.6 to 1.9 seconds (web.dev), a 0.7-second gain. DebugBear documents a case in which the LCP image loaded immediately after the document request once the attribute was set and LCP dropped from 4.2 to 1.9 seconds (DebugBear). Addy Osmani reports that priority hints sped up the LCP of a large commerce platform by 4 percent (Addy Osmani) and that some pages reached 20 to 30 percent (Addy Osmani) faster LCP values in their lab tests. The exact saving depends on how late the browser would otherwise have discovered the image -- the larger the waterfall in front of it, the bigger the lever.

An important caveat: fetchpriority is a hint, not a directive. The browser tries to follow the developer's preference but may weigh it against its own heuristics to resolve conflicts (web.dev). In practice this means the effect is most reliable where the browser would otherwise have made a recognizably wrong decision -- such as the late-promoted LCP image. If, on the other hand, you have already preloaded the image as one of the first elements in the document head, the additional gain from fetchpriority is smaller, because the browser has already triggered the download early. We look at exactly this interplay of preload and fetchpriority in detail below.

The most important principle of the priority hint is: exactly one element gets high. The temptation is great to mark several important images up at once -- the hero, the slider images, the logos. But that tips the effect into its opposite. Bandwidth is limited, especially on mobile networks. If several resources are requested as high priority at the same time, they compete for the same line and slow each other down. DebugBear describes a case in which seven slider images below the visible area carried fetchpriority='high': only when the attribute was removed from them and kept only on the LCP image did that one load faster -- LCP improved in total by almost 4 seconds (DebugBear).

The high therefore belongs exclusively on the element that determines the Largest Contentful Paint. Which one that is cannot be guessed, only measured -- a lab test or the field data show which element counts as LCP on most devices. With responsive layouts this can vary by screen size; here field data help identify which image serves as the LCP element across the large majority of visits. How lab and field data sensibly complement each other is explored in our article on RUM, CrUX and performance budgets.

Lazy loading is one of the most effective techniques for images below the visible area: with loading='lazy' the browser loads an image only when it scrolls near the viewport. On a page with ten images, of which only the first -- the LCP element -- is visible in the first viewport, lazy-loading the remaining nine images can even speed up loading the first (MDN), because they no longer steal its bandwidth. But this is exactly where the trap lies: the LCP image itself should specifically not be lazy-loaded.

If loading='lazy' is accidentally set on the hero image -- for example because a theme or plugin lazy-loads all images across the board -- it delays exactly the content fetchpriority is meant to speed up. The browser then waits until it knows whether the image is in the viewport, instead of loading it immediately. The LCP image therefore belongs loaded eagerly, that is, without the lazy attribute, and additionally marked with fetchpriority='high'. This combination is the standard case: the most important image eager and high-priority, all the others lazy.

In practice this single mistake -- the lazy-loaded hero image -- is one of the most common reasons for an unnecessarily high LCP. Many content management systems and theme builders now enable lazy loading across all images by default, because below the fold it usually helps. For the one image in the visible area, however, the benefit reverses. That is why, in every optimization, we first check whether the LCP image is accidentally stuck in lazy loading before we even think about the priority hint -- because a high attribute on a lazy-loaded image cancels itself out.

fetchpriority and preload solve two different sub-problems and unfold their full effect together. The problem of late discovery -- the browser finds an image only late in the markup, or because it is loaded as a CSS background -- is solved by preload, which triggers the download early. The problem of wrong priority is solved by fetchpriority. If an image is only preloaded, it keeps its low default priority; only fetchpriority='high' on the preload tag raises it. The two therefore belong together when the LCP element is discovered late, such as a CSS background image.

For responsive images with srcset and sizes the attribute belongs on the img element itself, not on the surrounding picture element (DebugBear). The browser first selects the matching image variant based on srcset and sizes and then loads it at high priority. That way the LCP image can be served responsively and prioritized at the same time -- the two optimizations do not exclude each other. Anyone who also shrinks the LCP image, for example with a modern format, gains twice: an image saved as AVIF at 80 percent quality reached a 95 percent (MDN) saving in one example, shrinking from 1 MB to 46 KB.

The first and most consequential mistake is over-prioritizing: setting several images to high at once. As described, they then compete for bandwidth and slow down the truly important image. The second mistake is accidentally lazy-loading the LCP image, often caused by a theme or plugin that lazy-loads all images across the board. The third mistake is setting the attribute on the wrong element -- not every hero image is the LCP element on every device, and without measurement it is easy to miss here.

The fourth mistake is viewing fetchpriority in isolation. The hint speeds up the moment the browser loads the image -- but it does not replace the other building blocks of a fast LCP. A slow server response delays every resource equally, as our article on TTFB optimization shows. An oversized, uncompressed image loads slowly even at high priority. And a layout that still shifts after the image loads does not hurt LCP but stability, which we cover in the article on the Visual Stability Index as the CLS successor. The priority hint is a building block, not a substitute for the whole picture.

The great advantage of fetchpriority is that it is purely declarative in the markup. It needs no new infrastructure, no additional build step and no server configuration -- one attribute on one element suffices. This makes the priority hint one of the cheapest measures to improve the Largest Contentful Paint, and at the same time one with the best ratio of effort to effect. In our frontend optimization it is usually one of the first moves once we have identified the LCP element beyond doubt.