Priority proxy both

What it does

Priority lets clients signal the relative importance of a request to servers and intermediaries. A browser can tell the server "this request is urgent (blocking render)" vs "this request is low priority (background prefetch)". The server can use this to schedule responses or allocate resources accordingly.

It's part of RFC 9218 — the Extensible Prioritization Scheme for HTTP — which replaced HTTP/2's built-in (but poorly adopted) stream priority mechanism.

Syntax

Priority: u=<urgency>[, i]

Two parameters:

• u — urgency level, integer 0–7 (0 = highest, 7 = lowest, default = 3)
• i — incremental flag (presence means true; absence means false)

Examples:

Priority: u=0
Priority: u=3, i
Priority: u=7
Priority: u=1, i=?1

Urgency levels

The incremental flag

i (incremental) tells the server whether partial responses are useful:

• i absent (default) — send the full response before moving to lower-priority requests. The entire response is needed before the client can use it (e.g., JavaScript files).
• i present — partial responses are useful, interleave with other responses. The client can process chunks as they arrive (e.g., progressive images, streaming JSON).

Priority: u=2        # High urgency, non-incremental (CSS file — need the whole thing)
Priority: u=3, i     # Normal urgency, incremental (progressive image — chunks are useful)

Why it replaces HTTP/2 stream priority

HTTP/2 had a complex tree-based dependency priority system that almost no server or CDN implemented correctly or consistently. It was technically powerful but practically useless — implementations varied wildly, and the complexity made it hard to reason about. RFC 9218 replaced it with this simpler scheme: just two meaningful parameters that servers can actually implement correctly.

HTTP/3 never adopted HTTP/2's priority scheme — it went straight to this extensible scheme. HTTP/2 implementations are gradually updating too.

Server response header

Servers can also send Priority in responses to indicate their assessment of the resource's priority or to signal changes:

HTTP/1.1 200 OK
Priority: u=2

This can be used by intermediaries to schedule forwarding to downstream clients.

Real-world examples

Browser requesting a render-blocking stylesheet:

GET /styles/main.css HTTP/2
Priority: u=2

Low-priority prefetch:

GET /next-page.html HTTP/2
Priority: u=6, i

Streaming response where partial data is useful:

GET /api/large-dataset HTTP/2
Priority: u=3, i

FAQ

Do browsers automatically set Priority?

Chromium-based browsers set Priority automatically based on resource type and position in the page. You don't need to set it manually in most cases. It's more relevant when building custom HTTP clients, CDNs, or proxies that need to schedule request handling.

Is Priority the same as HTTP/2 stream priority?

No — they replaced it. HTTP/2 stream priority (PRIORITY frames) was complex and widely ignored. RFC 9218's Priority header is simpler, works across HTTP versions (HTTP/1.1, HTTP/2, HTTP/3), and is what current browsers and servers implement.

Fun fact

The failure of HTTP/2's priority system is one of the web standards' cautionary tales about over-engineering. The HTTP/2 dependency tree was theoretically capable of expressing any priority relationship between streams, but its complexity meant browser vendors implemented it differently, server vendors implemented it partially or incorrectly, and CDNs mostly ignored it. A 2020 study found that the majority of HTTP/2 servers either ignored priorities entirely or implemented them incorrectly. The lesson taken into RFC 9218: two parameters that everyone will implement correctly beat ten parameters that no one will.