Gera Tools

HTTP Priority Header Reference

HTTP Priority, Urgency and Incremental field values with fetch priority mapping.

Reference for the HTTP Priority header from RFC 9218 with urgency levels (u=0..7), the incremental (i) flag, defaults and a fetchpriority mapping cheat sheet. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the HTTP Priority header?

Defined in RFC 9218 (Extensible Prioritization Scheme for HTTP), it lets a client or server signal how a response should be prioritised relative to others on the same connection. It uses structured-field parameters u (urgency) and i (incremental).

A simpler way to prioritise HTTP responses

The old HTTP/2 dependency-tree priority scheme was complex and widely unimplemented, so RFC 9218 replaced it with Extensible Priorities: two structured-field parameters carried in a Priority header. This reference lists the urgency levels, the incremental flag, their defaults, and how browser fetchpriority hints map onto them.

Background: why the old scheme failed

HTTP/2 introduced a dependency-tree priority model in RFC 7540 §5.3. Clients could declare that one stream depended on another and weight siblings relative to each other. In theory this allowed fine-grained scheduling. In practice, different browsers sent incompatible trees, server implementations ignored or misread them, and the complexity was disproportionate to the benefit. RFC 9218 deprecated the tree model and introduced a flat, two-parameter scheme that is much easier to implement and reason about. HTTP/3 (QUIC) never adopted the tree model at all; RFC 9218 is its priority system.

The two parameters

The Priority header is an HTTP structured-field dictionary with exactly two standardised members:

u — urgency (integer 0–7)

Urgency determines scheduling order on a contended connection. Lower numbers are served first:

u valueMeaningTypical resources
0HighestRender-blocking CSS, first <script>
1–2HighLCP image, critical <script>
3DefaultDocument requests, same-origin scripts
4–5NormalBelow-fold images, non-critical scripts
6–7BackgroundAnalytics, tracking, prefetch

If u is omitted the default is 3.

i — incremental (boolean)

When i is present (true), the response can be delivered and rendered progressively. The server may interleave bytes of this response with bytes of other responses of the same urgency level — useful for streamed HTML, progressive JPEG, or chunked responses. When absent (the default, false), the response is sent to completion before the server moves on to the next at the same urgency.

Priority: u=1, i

How it works in practice

A client sends Priority as a request header to ask the server how it would like that response scheduled. A server may echo or override by sending its own Priority response header, or via a priority parameter on a Link preload hint. Intermediaries (CDNs, proxies) that support RFC 9218 read the header and schedule multiplexed streams accordingly.

Mapping from the browser fetchpriority attribute

The HTML fetchpriority attribute on <img>, <link> and <script> is translated by browsers to a Priority request header:

fetchpriorityApproximate Priority
highu=1 or u=2
auto (default)u=3
lowu=5 or u=6

Practical recommendations

  • Mark the LCP image with fetchpriority="high" so it gets u=1/u=2 and is served ahead of below-fold images.
  • Mark analytics and tracking pixels with fetchpriority="low" to keep them from competing with visible content.
  • Add i (incremental) to streaming HTML responses and progressive images so the browser starts rendering as bytes arrive rather than waiting for the full response.
  • Omitting the Priority header is equivalent to Priority: u=3 — the correct default for most requests, but suboptimal for critical resources.