阅读中文版本

Fetch Priority Signals

The fetchpriority attribute tells the browser which resources matter most, letting it reorder network fetches so critical images beat lower-value work.

Definition

Fetch priority is a hint, expressible as an HTML attribute or a JavaScript option, that raises or lowers a resource’s scheduling priority relative to the browser’s default assumption.

It is used to accelerate the largest contentful paint image or defer below-the-fold media during load. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Browsers derive a default priority per resource type, and fetchpriority lets the author override that judgement based on layout knowledge the browser lacks.

Setting high priority on a hero image often improves the largest contentful paint, while downgrading non-critical media frees bandwidth for scripts and styles.

Trade-offs and alternatives

The hint only influences scheduling among competing fetches; it cannot overcome a slow origin or a bandwidth limit, so it works best alongside proper caching and compression. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that fetchpriority guarantees a faster transfer. Another is that it changes the order in which the HTML parser encounters elements. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to marking every image as high priority so none stands out and to lowering priority on resources that block the first render. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Speculative Parsing and Preload Scanner, Render-Blocking Resources, Native ES Modules in the Browser.