fetchpriority Explained: Priority Hints for Faster Loads

The fetchpriority attribute is an HTML hint that tells the browser how important a resource is relative to others of the same type. You can set it to high, low, or auto on images, scripts, stylesheets, iframes, and <link> elements, and the browser adjusts the order in which it requests and processes them. Its most common use is a single line on a page’s hero image that can noticeably improve Largest Contentful Paint.

Why browsers need priority hints

Every page load is a scheduling problem. The browser discovers dozens or hundreds of resources and must decide what to fetch first over a connection with limited bandwidth. It already has a built-in priority system. Render-blocking CSS in the <head> is fetched at high priority, synchronous scripts are high, async scripts are lower, and images usually start at low priority until the browser works out which ones are visible in the viewport.

That last point is the gap. When the HTML parser first encounters an <img>, layout has not happened yet, so the browser cannot know whether the image is the large hero banner at the top of the page or a thumbnail far below the fold. It often starts the hero image at low priority and only raises it after layout, by which time other requests are already in flight. Because the hero image is frequently the Largest Contentful Paint element, that delay goes straight into one of the Core Web Vitals.

fetchpriority lets you supply the knowledge the browser lacks.

The three values

• high raises the resource’s priority compared with the default for its type.
• low lowers it.
• auto is the default and lets the browser decide.

These are relative hints, not absolute commands. A high-priority image does not jump ahead of render-blocking CSS; it moves ahead of other images and similar resources. The browser is free to weigh the hint against its own heuristics.

Boosting the LCP image

The single most valuable use is marking the main above-the-fold image:

<img
  src="/images/hero.jpg"
  alt="Product dashboard on a laptop"
  width="1200"
  height="630"
  fetchpriority="high"
/>

With this hint the browser requests the hero image at high priority from the moment it parses the tag, instead of waiting for layout to discover that it matters.

Two rules go with it. First, never combine fetchpriority="high" with loading="lazy" on the same image. Lazy loading delays the request until the image approaches the viewport, which contradicts asking for it urgently. Our guide to lazy loading images explains why the LCP image should always load eagerly. Second, apply high to one or two resources at most. If everything is high priority, nothing is.

For responsive images, fetchpriority sits alongside srcset and sizes without any conflict. The browser still picks the right candidate, as described in our explainer on responsive images, and then fetches it at the requested priority.

Lowering what can wait

Lowering priority is just as useful and often overlooked. Good candidates include:

• Carousel slides after the first. Only the first slide is visible on load. Marking the others low keeps them from competing with the hero.
• Non-critical scripts. An analytics or chat widget loaded with async can also be marked low so it does not compete with scripts that drive the main interaction.
• Below-the-fold iframes, such as embedded videos or maps.

<script src="/js/chat-widget.js" async fetchpriority="low"></script>

fetchpriority with preload

fetchpriority complements resource hints rather than replacing them. A <link rel="preload"> makes the browser discover a resource early, which matters when the resource is not in the initial HTML at all, for example a background image referenced only from CSS or an image injected by JavaScript. fetchpriority sets how urgently to fetch it once discovered. They combine naturally:

<link
  rel="preload"
  as="image"
  href="/images/hero.jpg"
  fetchpriority="high"
/>

Our guide to preload, prefetch, and preconnect covers when early discovery is worth it.

	preload	fetchpriority
Purpose	Start fetching a resource early	Change a resource’s relative priority
Solves	Late discovery	Wrong default priority
Where it goes	A <link> in the document head	On the element itself, or on a <link>
Risk if overused	Wasted bandwidth on unused resources	Priorities flatten and lose meaning

If the resource is already in the HTML as an <img> tag, it is discovered early, and fetchpriority alone is usually enough.

Priority in JavaScript fetches

The same idea applies to network requests made from script. The Fetch API accepts a priority option:

// User-facing data needed for the next paint
const res = await fetch("/api/profile", { priority: "high" });

// Background prefetch that can wait
fetch("/api/recommendations", { priority: "low" });

This helps single-page applications that fire several requests at once on navigation and want the visible content to win.

How it interacts with the network

Priorities matter most when requests share a connection. With multiplexed protocols, many requests travel over one connection at once and the browser signals their relative importance to the server; our comparison of HTTP/2 vs HTTP/3 covers how that multiplexing works. How faithfully a server or CDN honors those priority signals varies, so measure rather than assume.

Older browsers that do not recognize fetchpriority simply ignore it, which makes it safe to add as a progressive enhancement.

Measuring the effect

Treat fetchpriority as an experiment. In your browser’s developer tools, the network panel can show a priority column; check that the hero image starts at high priority and starts earlier in the waterfall. Then compare LCP before and after in lab tests and, where possible, real-user data. The hint reshuffles a page’s critical rendering path, and on pages where the LCP element is text rather than an image, it may make no difference at all.

The takeaway

fetchpriority gives the browser information it cannot work out on its own: which resources matter most to what the user sees first. Put fetchpriority="high" on the one image most likely to be the LCP element, never alongside lazy loading, and use low on carousels, widgets, and other content that can wait. Pair it with preload only when a resource would otherwise be discovered late, and confirm the gains with measurement.