How do you explain HTTP request prioritization and RFC 9218?

Prompt and context

Explain how a browser expresses resource priority, how servers and intermediaries act on it, and why a priority hint cannot guarantee that one request finishes first. Cover the RFC 9218 Priority field, urgency and incremental, and relate it to the older HTTP/2 dependency and weight model.

What the interviewer is testing

• Whether you distinguish a scheduling preference from an SLA.
• Whether you understand boundaries between clients, origins, intermediaries, and CDNs.
• Whether you can connect scheduling with fairness, bandwidth contention, and user metrics.
• Whether you know that RFC 9113 deprecated the RFC 7540 priority signaling model and RFC 9218 defines an extensible alternative.

Clarifying questions before answering

Confirm the protocol version, browser or SDK, CDN path, resource type, cache hit rate, and target metric. Ask whether the priority is a client hint or a server decision that must be communicated downstream; the debugging path differs.

30-second answer framework

RFC 9218 defines an extensible HTTP prioritization scheme. A request or response Priority field can express urgency=0 through 7 and whether delivery is incremental; lower values are generally more urgent. It is scheduler input, not an SLA: a server or intermediary may reorder, coalesce, delay, or ignore it. Because HTTP/2's original dependency tree and weight model were deprecated, I would validate the result with real browser, origin, and CDN waterfalls.

Step-by-step deep dive

1. What the field expresses

urgency provides relative urgency, while incremental says whether a response is suitable for progressive delivery. Example:

Priority: u=1, i

This asks for relatively urgent, incremental delivery; it does not require preempting every other stream.

2. Who applies it

The client can send a preference in a request, and a server can update the value in a response for downstream processing. Origins, reverse proxies, and CDNs can reschedule using connection limits, queues, cache state, bandwidth, and fairness. The protocol defines the signal and semantics, not one mandatory algorithm at every hop.

3. Why fairness matters

Always serving the highest urgency can starve low-priority downloads. A scheduler may need bounded concurrency, quotas, aging, or round-robin behavior; incremental responses also trade fast first bytes against completion time.

High-quality sample answer

I treat RFC 9218 as a scheduling-hint layer shared across HTTP implementations. The client supplies urgency and incremental preferences based on rendering or business goals, while servers and intermediaries make the final decision from their queues, cache state, and bandwidth. Priority is not a promise that a request finishes first, and it cannot bypass congestion control or connection multiplexing. RFC 9113 deprecates HTTP/2 dependency and weight signaling, so changing an old tree is not enough to predict modern behavior. For diagnosis, I would hold cache and network conditions constant, inspect headers, queues, and waterfalls from browser to CDN and CDN to origin, then compare LCP, INP, tail latency, and constrained-bandwidth runs. If an intermediary strips or overwrites the field, that boundary must be configured or accepted.

Common mistakes

• Calling urgency=0 an absolute, preemptive top priority.
• Claiming every browser, server, and CDN uses the same scheduler.
• Treating the RFC 7540 dependency tree as required configuration for RFC 9218.
• Measuring only local latency without separating cache hits, bandwidth contention, and intermediary rewrites.
• Looking only at time to first byte and ignoring full-response completion and fairness.

Follow-up questions and responses

What if an intermediary does not support the Priority field?

Treat that as a capability observation and keep a safe default queue. Check whether intermediary configuration, resource partitioning, or bounded concurrency can improve the critical path; do not treat the client hint as proof of enforcement.

How would you prove that prioritization improved UX?

Run a controlled comparison with the same protocol, cache state, bandwidth, and request set. Capture waterfalls, per-hop fields, LCP, INP, first-byte time, and tail completion latency under both warm-cache and constrained-bandwidth conditions.

How does fetchpriority relate to the Priority field?

fetchpriority expresses a resource-fetch preference in a page API. An implementation may map it to request prioritization, but browser, server, and intermediary schedulers still decide the outcome. Verify the emitted field and network behavior rather than relying on the DOM attribute.