Resource Priority Hints

Resource Priority Hints let a frontend developer tell the browser that a particular external resource is relatively more or less important to fetch early. The `fetchpriority` hint can complement normal browser prioritization and other loading techniques, but it does not force a specific network schedule.

Browsers already assign internal priorities to resources such as images, scripts, and stylesheets. `fetchpriority` lets the developer provide additional information when the browser's inferred priority does not match the resource's importance to the user experience. The permitted values are `high`, `low`, and `auto`, with `auto` meaning that no explicit preference is supplied.

A common Core Web Vitals use case is an image that is likely to become the Largest Contentful Paint element. If the browser can discover that image early but would otherwise give competing resources similar or greater priority, `fetchpriority="high"` can signal that the image matters more. Conversely, below-the-fold or otherwise noncritical resources can sometimes use `fetchpriority="low"`.

The attribute can be used on HTML `<img>`, ``, and `<script>` elements. JavaScript also exposes corresponding `fetchPriority` properties on these element interfaces. This makes the mechanism useful for both declarative HTML and dynamically created resources.

Priority hints are not the same as `preload`. `preload` helps the browser discover a resource earlier, while `fetchpriority` communicates its relative importance to the fetch scheduler. They can be combined when appropriate, but both should be used selectively because unnecessary prioritization can compete with genuinely critical resources. Browser behavior remains implementation-dependent.

Key points

Interview questions

Does `fetchpriority="high"` guarantee that a resource loads first?

No. It is a developer hint that influences the browser's resource prioritization rather than an absolute scheduling command. The browser considers this hint alongside its own prioritization logic and other constraints. Therefore, performance improvements should be validated in the target browsers and network conditions.

What problem does `fetchpriority` solve?

It lets developers provide the browser with additional information about how important a resource is to the user experience. For example, a prominent hero image may deserve earlier fetching than a decorative image. The browser still makes the final scheduling decision, so the attribute is only a hint. The goal is to correct cases where the browser's inferred priority is not ideal.

When would you use `fetchpriority="high"` on an image?

A strong case is an image that is important to the initial viewport and is likely to contribute to LCP, particularly when the browser might otherwise prioritize competing resources ahead of it. The hint can increase that image's relative fetching priority. It should be used selectively rather than on every above-the-fold image. I would verify the effect with browser performance tooling rather than assuming it improves every page.

How do `preload` and `fetchpriority` work together?

`preload` primarily solves early discovery: it tells the browser about a resource before normal discovery would necessarily find it. `fetchpriority` supplies relative importance for its fetch, which can be useful when the browser's normal priority would not reflect its user impact. For a critical resource, combining them can therefore address both discovery and prioritization. However, adding both indiscriminately can create unnecessary competition for bandwidth, so the combination should be based on measured loading behavior.

Where can `fetchpriority` be used, and how would you set it dynamically?

The HTML attribute is supported on `<img>`, ``, and `<script>`. Corresponding DOM properties expose `fetchPriority` on the relevant element interfaces, so dynamically created elements can receive a priority hint through JavaScript. For example, an `HTMLImageElement` can have `img.fetchPriority = "high"` before its source is requested.