HTTP/2 prioritisation is mostly ignored
2026-09-27
The HTTP/2 specification defines a fairly elaborate priority scheme: streams declare a dependency on another stream and a weight, forming a tree that a server is supposed to honour when scheduling frames.
Almost nobody implements it.
Why the design failed
The scheme had two problems from the start. It was complex enough that writing a correct scheduler was a significant piece of work, and it was advisory — a server could ignore the tree entirely and still be conformant, because there was no way for a client to detect the difference.
Browsers built the trees. Servers, overwhelmingly, did not read them. The result is a feature that costs bytes on every request and delivers nothing.
The eventual fix
The replacement is Priority header in HTTP/2, and its direct analogue in HTTP/3:
a simple urgency level from 0 to 7 with an incremental flag. No tree, no weights, no mutual
dependencies. It is far less expressive and far more likely to actually be honoured.
Practical advice
- Do not spend time tuning dependency trees. Nothing is reading them.
- If you control the server, implement the
Priorityheader scheme instead. - If you are worried about head-of-line blocking, prioritisation is not the lever — the connection count and the stream count are.
The broader lesson generalises: a protocol feature that servers may ignore is a protocol feature that will be ignored, especially when implementing it correctly is expensive.