HTTP/2 collapsed the browser’s six-connection scramble into one multiplexed pipe, which created a new problem the old chaos accidentally solved: something must decide which stream’s bytes go first. Prioritization is that decision, its history is messy, and its present is finally usable.
From dependency trees to priority hints
HTTP/2’s original scheme, a dependency tree with weights, was expressive, inconsistently implemented (some servers ignored it, some middleboxes mangled it), and quietly abandoned. The replacement, Extensible Priorities, reduces the signal to urgency levels plus an incremental flag, carried in a header, simple enough that implementations actually honor it. HTTP/3 adopted it natively. The lesson embedded in that history: on the wire, boring and implemented beats elegant and theoretical.
What actually needs ordering
The renderer’s hunger order is stable: HTML, then render-blocking CSS and critical fonts, then above-fold images and application JS, then the long tail. Browsers signal this reasonably well now; you tune at the margins with fetchpriority attributes (raising the LCP image, lowering the analytics bundle), preload for late-discovered critical assets, and by not shipping megabytes of equal-priority JS that gives the scheduler nothing to choose between. Bandwidth allocation cannot rescue an undifferentiated payload.
The systems lesson under the history is worth keeping: multiplexing moved scheduling power from the client’s crude connection pool into the server’s explicit decisions, which means your delivery stack now actively chooses your render order under contention. That choice quality is invisible on fast connections, everything arrives soon regardless, and decisive on the slow tail, where the difference between CSS-first and image-first scheduling is seconds of blank page. Which makes prioritization one more entry in this series’ recurring theme: the technologies that matter most are the ones only your worst-connected users can see, and they are exactly the users your averages are structurally designed to hide.
Where it still breaks
Server and CDN implementation quality varies: some edges honor urgency fully, some approximate, and buffering anywhere in the path (an over-eager proxy, a fat kernel send buffer) defeats reprioritization by committing bytes too early, the classic symptom being a huge image hogging the pipe while CSS waits behind bytes already queued. HTTP/3’s independent streams sharpen this: no transport head-of-line, so scheduling choices show through cleanly, for better and worse.
In practice
Verify empirically per provider: throttled-network waterfalls for a heavy page, watching whether critical assets preempt bulk ones mid-flight. Set fetchpriority on your LCP element and your least important third-party bundles, measure the LCP delta, and treat any provider whose edge visibly ignores priority signals as having disclosed something about their HTTP stack’s maturity. It is one of the few transport behaviors a Tuesday afternoon and devtools can conclusively audit.
Priority behavior is on our provider test matrix, measured under throttle, per protocol. Ask for the scheduling tab.