fetchpriority

Definition and purpose

fetchpriority is part of the Priority Hints specification, giving developers a lightweight way to influence a browser’s network queue. Without it, the browser relies entirely on built‑in heuristics (e.g., element type, discovery timing, viewport proximity) to decide which requests start sooner, which are delayed, and which are deprioritised under congestion.

For image optimisation and SEO adjacent performance work, the attribute helps surface the most meaningful content—often the hero/LCP image—earlier in the fetch pipeline. It complements, rather than replaces, other discovery and connection signals such as preload, preconnect, and responsive image markup. The result is more predictable loading of critical media without resorting to heavier workarounds.

Allowed values

The attribute accepts three values: auto, high, and low. auto is the default state and defers entirely to the browser’s heuristics. high raises the relative urgency of the request, placing it ahead of similarly timed resources of the same class. low reduces urgency, signalling that the request can yield bandwidth to more important work. The hint is supported on img, link rel=preload, and script. On link, it applies to the preloaded resource; on img and script, it applies to the element’s own fetch.

The hint does not override higher‑level constraints such as render‑blocking CSS, connection limits, or prioritisation of critical CSS and HTML. It also does not force download order across types—e.g., a stylesheet may still outrank an image regardless of fetchpriority. Browsers may cap how many items can be promoted to high at once to prevent priority inflation.

How LCP is determined and why priority matters

Largest Contentful Paint measures when the largest content element within the viewport is rendered. For many pages, this is a hero image or a prominent block-level image. The clock starts at navigation and stops when the element is painted with its final renderable bytes. If the LCP image arrives late due to queue contention or bandwidth competition, LCP is delayed even if markup appears early.

By marking the expected LCP image with fetchpriority="high", the browser can promote that request ahead of other non‑critical images, third‑party scripts, or background fetches. This reduces head‑of‑line blocking within the image class and can shave tens to a few hundred milliseconds off LCP on real networks, depending on contention and connection quality. Overuse, however, dilutes the benefit—if many resources are marked high, the queue reverts to a congested state and criticality is lost.

Relationship to preload

preload and fetchpriority solve related but distinct problems. preload ensures early discovery of a resource before the parser would normally encounter it; fetchpriority affects the scheduling of the resource once it is known. Using both can be appropriate for the hero image: preload (as=image, matching src/srcset) to eliminate discovery delay, plus fetchpriority="high" on the img to keep it near the front of the queue. In contrast, preload alone does not guarantee top priority under congestion, and fetchpriority alone cannot make up for late discovery.

Care is required to avoid duplicate requests: the preload’s URL and descriptors must match the img’s eventual candidate selection (including imagesrcset/sizes). For non‑critical images, avoid preload and consider fetchpriority="low"—or native lazy-loading—to let bandwidth favour CSS, fonts, and the LCP path.

Overall support

fetchpriority is supported in Chromium‑based browsers and recent versions of Safari. As of 2025, Firefox support is limited; the attribute is safely ignored where not implemented, leaving default heuristics in place. Because it is an advisory hint, it does not change page correctness when unavailable, and it can be deployed progressively without user‑agent targeting.

CDNs and optimisation layers often pass the attribute through unchanged. Some may add or adjust it automatically for the detected LCP image. Validation is straightforward: browser DevTools typically expose request priority and the presence of the hint in the network waterfall, allowing verification without synthetic instrumentation.

What “defaults” mean

With no explicit hint, browsers assign priorities based on type, render‑blocking status, discovery timing, and viewport relevance. HTML, render‑blocking CSS, and critical preloads usually occupy the highest tiers. Non‑lazy images discovered early and likely above the fold get moderate to high treatment once layout information is available; offscreen or lazy images are pushed to lower tiers. Third‑party and async scripts generally compete at lower priorities unless elevated by heuristics or timing.

fetchpriority="auto" explicitly requests this default behaviour. It can be useful when templating to reset a previously set hint without removing the attribute. The precise priority levels are user‑agent specific, and may vary by connection state, power mode, HTTP/2 or HTTP/3 prioritisation, and ongoing experiments in the networking stack.

Implementation notes

Typical usage elevates the expected LCP image: an img element in the hero region with fetchpriority="high". Combine with responsive markup (srcset/sizes) and, when discovery would otherwise be late, an early link rel=preload for the same candidate. Avoid marking multiple images as high on the same view; pick the single most likely LCP candidate. For non‑critical decorative or below‑the‑fold images, consider fetchpriority="low" or lazy-loading to free capacity for CSS, fonts, and the hero path.

Check results in DevTools: confirm the LCP request appears near the top of the image queue and that its effective priority is elevated. Watch for pitfalls such as mismatched preloads (causing duplicate downloads), marking lazy images as high (contradictory signals), or promoting many third‑party resources that compete with core rendering. Measure the impact on LCP and Total Blocking Time holistically—starving critical CSS or long tasks can negate gains from faster image fetches.

• Hero image pattern: <img fetchpriority="high" ...> and, if needed, <link rel="preload" as="image" imagesrcset="..." imagesizes="...">.
• Do not over‑promote: keep high limited to one primary visual per view to avoid priority inflation.
• Align hints with intent: pair fetchpriority="low" with loading="lazy" for non‑critical images.

Comparisons

fetchpriority vs. preload

preload accelerates discovery; fetchpriority influences scheduling. Preload can still contend with other high‑priority work, while fetchpriority without preload cannot compensate for late discovery. Used together for the hero image, they address both bottlenecks.

fetchpriority vs. HTTP/2 and HTTP/3 priorities

HTTP priorities operate at the transport layer, while fetchpriority is a page‑level hint feeding into the browser’s scheduler. Browsers map their internal priorities onto HTTP/2 or HTTP/3 signals as supported by the server. You do not control wire‑level weights directly with fetchpriority, but it steers the inputs that inform them.

fetchpriority vs. the deprecated importance attribute

An earlier Chrome‑only attribute named importance provided similar hints but was not standardised and has been superseded. fetchpriority is the standardised, cross‑vendor path with broader adoption and should be used instead.

FAQs

Should every hero image use fetchpriority="high"?

It is appropriate for the single most likely LCP image on a view. If multiple images compete for bandwidth with high priority, the advantage diminishes. For carousels or rotating heroes, promote only the initially visible slide’s image and keep others default or low.

Does fetchpriority affect SEO rankings directly?

There is no direct ranking signal for the attribute itself. The benefit is indirect: by helping improve LCP and overall loading behaviour, it can contribute to better Core Web Vitals performance, which is a lightweight page experience signal.

How does it interact with loading="lazy" and decoding?

lazy-loading and low priority both defer work, but for different reasons. Combining loading="lazy" with fetchpriority="low" is coherent for non‑critical images. Avoid mixing lazy-loading with fetchpriority="high"; the signals conflict and the browser may prioritise laziness over urgency. The decoding attribute (e.g., decoding="async") affects decode timing, not network scheduling, and is orthogonal.

Does it work with responsive images (srcset/sizes)?

Yes. Apply fetchpriority to the img element; the selected candidate inherits the hint. If you also preload, use imagesrcset and imagesizes on the link so the browser can choose the correct candidate early. Mismatches between preload and the eventual candidate can cause duplicate downloads or wasted bytes.

Is it honoured for cross‑origin resources and on HTTP/3?

Yes, as an internal scheduling hint it applies regardless of origin or HTTP version. The browser maps its scheduling decisions onto transport‑level priorities when available. Servers that ignore HTTP priorities will still deliver the resource; the main effect remains within the browser’s own request queue.