HTTP/2 (RFC 7540) originally specified an intricate priority tree where each stream declared an explicit dependency on a parent stream, along with an exclusive flag and an integer weight (1-256). In practice, this design proved catastrophic: browsers (Chrome, Firefox, Safari) built wildly conflicting tree shapes that CDN servers and reverse proxies could not reconcile. Intermediaries often dropped or reprioritized branches, causing priority inversion, starvation, and buffer bloat. RFC 9218 discarded the complex tree model in favor of a simple, decoupled scheme using just two orthogonal parameters: Urgency (u=0 to 7) and Incremental (i boolean), unifying priority signaling across both HTTP/2 and HTTP/3.

Urgency (u) defines strict bucketed priority from 0 (highest, e.g. render-blocking CSS) to 7 (lowest, e.g. background analytics). A server MUST send data for higher-urgency streams before lower-urgency streams. Within the same urgency bucket, the Incremental parameter (i) dictates concurrency: if i=?0 (default/non-incremental), the server transmits one stream to completion before starting the next (ideal for JavaScript bundles that cannot be parsed until fully downloaded). If i=?1 (incremental), the server multiplexes bandwidth fairly in round-robin across all active streams in that bucket (ideal for progressive images or audio chunks where partial data is immediately useful).

In HTTP/2, priority frames were sent directly on individual client streams. If a stream was closed or had not yet been processed by an intermediary, priority signals were dropped or triggered synchronization race conditions. In HTTP/3, PRIORITY_UPDATE is sent as a distinct HTTP frame on the control stream (stream 0). It identifies the prioritized request by its 62-bit integer Element ID (Stream ID), decoupling prioritization signaling from the lifecycle of the data stream itself and preventing stream-closure race conditions.

Without proper stream prioritization, an edge server sends chunks of every requested asset concurrently. A 500 KB non-critical background image competes equally with a 20 KB critical CSS stylesheet, causing the stylesheet download to stall and delaying First Contentful Paint (FCP). With RFC 9218, the browser assigns u=0 to critical CSS and fonts, u=1 to above-the-fold hero images (with i=?0 to finish fastest), and u=5 to non-critical analytics. The server dedicates 100% of available bandwidth to the critical path first, cutting LCP times by 30% to 50% on mobile networks.