HTTP/2 multiplexes many requests over one connection, but multiplexing does not decide which response data a server should send first. RFC 9218 defines a common way for clients and intermediaries to express relative preferences for HTTP responses. Those values are signals for a server to consider, not a promise that one resource will arrive before another. Browser hints, server queues, network conditions, and application policy all contribute to the observed result.

Conceptual diagram of HTTP/2 priority signals and server response scheduling

1. Why the earlier dependency-tree model was difficult

The earlier HTTP/2 priority model represented dependencies and weights between streams. In practice, a browser and server could maintain different views of that tree. New requests could also appear after the relationship had been described, and implementations did not always interpret or update the tree in the same way. RFC 9218 uses a simpler set of preference attributes for each response instead of requiring the same complex dependency state to be maintained across the connection.

This change does not mean that the transport layer automatically sorts application data. HTTP/2 still multiplexes streams over one TCP connection, and the server implementation decides when it creates and sends response frames. Supporting the priority protocol and changing the loading order visible to a user are separate steps. Operators need to check whether the browser sends the new signals and whether the server's scheduler actually uses them.

2. Reading urgency and incremental delivery

The u parameter in the Priority field expresses urgency on a scale from 0 through 7. A smaller number represents a more urgent preference; when the parameter is omitted, its default value is 3. The i parameter indicates whether incremental delivery is preferred. It is false when omitted; the true form is expressed as i=?1. When it is true, a server may choose to send portions of a response while also making progress on other responses, rather than treating completion of the whole response as the only useful milestone.

These attributes communicate preference, not a fixed deadline or a strict queue position. Urgency does not reserve bandwidth, and an urgency value of 0 cannot guarantee that an object will complete first. Server policy, response size, whether data is already available, congestion, and other requests can change what is practical. The values also do not encode a complete dependency graph or a direct measure of how much a user interface is blocked.

3. Updating a preference after a request starts

At the start of document processing, a browser may not yet know every resource or how each one affects the current view. It discovers stylesheets, scripts, images, and other requests over time. RFC 9218 therefore defines both an initial Priority field and frames that can update priority on HTTP/2 and HTTP/3 connections. A server can use a later update to reconsider the scheduling of response data that has not yet been sent.

An update cannot take back bytes already transmitted, nor does the protocol require a server to honor every change. The operational path matters: the client must send the update, any proxy or CDN in the path must preserve it, and the server's scheduler must apply it in a useful way. Cloudflare's deployment account discusses the practical relationship between browser signals and server-side scheduling. It is a useful engineering perspective on implementation, not evidence that every HTTP/2 service behaves identically.

4. Expert perspective: testing whether priorities help

Start with a few representative pages and record the browser's Priority values, request discovery times, response sizes, and completion times. Compare those observations with server frame scheduling and user-facing measures such as rendering milestones. Keep cache state, connection reuse, CDN behavior, and network conditions consistent between test runs. When testing incremental delivery, check whether partial progress is useful to the consumer and whether it delays a small response that blocks a more important interaction.

The useful mental model is a preference communicated across protocol layers. RFC 9218 defines how to express and update it; the browser chooses what to signal, and the server decides how that signal fits its implementation and current conditions. Keeping those roles separate avoids the mistaken claim that HTTP/2 automatically recognizes important files or guarantees that they arrive first.

Sources