Archivenetworking
HTTP/2 Prioritization Failed, and That Is Instructive
A flexible priority tree was ignored by implementations; HTTP/3 replaced it with simple, explicit priorities.
- Published
- Reading time
- 1 min read
HTTP/2 let clients express a dependency tree with weights, so browsers could say "render-blocking CSS before below-the-fold images". In practice, servers and intermediaries ignored or simplified it, and different clients disagreed on semantics. The result was unpredictable scheduling.
What replaced it
HTTP/3 (and RFC 9218) defines the Priority header with urgency (0–7) and incremental flags — a much simpler model that intermediaries can honor. Extensible priorities work even for protocols that do not have a native tree.
The lesson
A protocol feature is only real if implementations enforce it and intermediaries preserve it. Priority needs a shared interpretation across client, CDN, and origin; a complex optional tree had none.
What to do today
- Mark critical resources with
fetchpriority="high"and defer the rest. - Avoid relying on server-side priority; control order in markup.
- Measure with real network conditions, not localhost.
Takeaway: preference signals only help when the whole path agrees on them. Simplicity beats expressiveness in middlebox-land.