2026-09-20 · 8 min read
- http
- performance
- priority
HTTP priority signals communicate relative scheduling preferences between clients and servers. Urgency describes how soon a response is useful relative to other requests, while the incremental preference indicates whether progressively available response data can be useful.
These values are hints within a larger scheduling system. Discovery order, browser internals, preload, fetch priority, transport state, server queues, cache status, and bandwidth competition can all outweigh or revise the initial signal.
Classify resources by user impact
Start with the rendering and interaction dependency graph rather than assigning priorities by file extension alone. A stylesheet that blocks first render, a visible hero image, and an offscreen image have different timing value even when their transfer sizes are similar.
- Reserve the highest urgency for genuinely critical work.
- Mark progressive delivery only when partial bytes are useful.
- Keep background transfers from starving interactive requests.
- Revisit classifications for each page template.
Treat fields as structured data
Use an implementation of HTTP Structured Fields to parse and serialize priority parameters. Validate urgency within its defined range, represent incremental as the defined boolean, and tolerate extensions according to the protocol.
Do not infer a total global order from equal urgency values. A scheduler still needs fairness, connection-level flow control, dependency handling, and protection against clients that label every request as critical.
Coordinate clients, edges, and origins
Document whether the browser, CDN, reverse proxy, or origin consumes and forwards each signal. A cache hit may never reach the origin, while a cache miss can have separate priorities on the client-edge and edge-origin legs.
Log safe scheduling categories and timings without high-cardinality URLs or user data. Compare protocol behavior across HTTP/2 and HTTP/3 because transport and server implementations differ even when application fields match.
Optimize from measured outcomes
Measure resource start, queueing, first byte, completion, rendering milestones, bandwidth use, and regressions under realistic contention. A faster individual request does not prove that the page became faster if it displaced more important bytes.
Use Flashman's URL tool for resource fixtures, diff for traces and policies, timestamp converter for event order, units converter for transfer budgets, and JSON formatter for sanitized measurements. Cover cold caches, slow networks, multiplexing, reprioritization, CDN hits, overload, and unsupported peers.