Problem and applicable scenarios
HTML generation is slow, and the resource set varies by user, experiment, or authorization. Design a prediction policy that generates 103 Early Hints by route and cohort, with an explicit confidence threshold, privacy boundary, and misprediction control.
This fits backend, edge-gateway, and performance-engineering interviews. Assume the request eventually returns a 2xx response or redirect, and the resource set may vary by user, experiment, or authorization.
What the interviewer is evaluating
- Whether you understand that 103 is a provisional hint, not a final response or business state.
- Whether resource certainty, protocol version, and cross-origin behavior drive the send-or-skip decision.
- Whether you can handle hint/final mismatches, redirects, and CSP boundaries.
- Whether you use real browsers, caches, and layered protocol metrics rather than server time alone.
Clarifying questions before answering
- Are the resources known before final HTML generation? Uncertainty makes speculative downloads wasteful.
- Is the connection HTTP/2 or newer? Legacy HTTP/1.1 clients may mishandle informational responses.
- Which resources deserve a hint? Critical CSS, fonts, and connection warm-up have different payoffs from low-priority images.
- Are there cross-origin redirects, CSP, user cohorts, or authorization differences? Each changes hint validity.
A 30-second answer framework
“I treat 103 as a discardable performance hint and send only high-confidence Link resources likely to appear in the final response. I gate it on HTTP/2 or newer, derive the list at the CDN/origin boundary, and skip it when redirects or user-specific resources make the prediction uncertain. The final response still carries the authoritative Link and CSP, and business logic never depends on 103. In a canary I measure arrival, lead time, useful-preload rate, duplicate downloads, and errors; I turn it off if user-visible gains are absent.”
Step-by-step deep dive
1. Decouple hints from business response
RFC 8297 defines 103 as an informational response: a client may speculatively process headers while waiting, but must not treat them as final metadata. Send performance hints only, never authorization, pricing, or success state. The final response must remain correct when a proxy drops 103.
2. Choose high-certainty Link headers
Prefer above-the-fold CSS, fonts, or preconnect to a fixed CDN. If cohorts, permissions, or experiments change the resource set, calculate a safe intersection or skip the hint. A hint is not a forced download; as, CORS, and CSP still govern the fetch.
3. Set protocol and redirect gates
Make HTTP/2 or newer the default gate for compatibility and safety. When a request ends in a cross-origin redirect, a browser may discard the first 103; a gateway may also merge or reorder informational responses. Test the proxy chain in the canary so 103 is never mistaken for the final response.
4. Handle CSP and final-response drift
103 may carry a CSP that restricts speculative loads, but the final response remains authoritative. If the server later discovers a wrong resource, the client may already have started it. Limit hints to low-risk, cacheable, safely discardable assets; never use 103 to bypass final CSP.
5. Verify with layered metrics
Keep a control group without 103 and enable it only for HTTP/2 or newer in the experiment. Measure 103 arrival, resource lead time, useful-preload ratio, duplicate requests, final LCP, bandwidth, and errors. Slice by cache hit, cross-origin redirect, and device; if TTFB improves but LCP does not, roll it back.
High-quality sample answer
I would first ensure 103 carries only performance hints and that the final response does not depend on it. For HTTP/2 or newer, I would hint only high-confidence above-the-fold CSS, fonts, or a fixed CDN connection; user cohorts, authorization, or cross-origin redirects that make the resource set uncertain cause a skip. The gateway and browser canary must prove that informational responses are not treated as final, while the final response repeats authoritative Link and CSP. I would compare arrival, useful-hit rate, duplicate downloads, LCP, bandwidth, and errors by cache and device; if only server TTFB improves, I would disable Early Hints.
Common mistakes
- Symptom: Treat 103 as a success response. Why it fails: it has no business-completion semantics and may be dropped. Fix: complete authorization, status, and body in the final response.
- Symptom: Preload every resource. Why it fails: dynamic pages create wasted downloads, bandwidth contention, and cache pollution. Fix: hint only high-certainty assets and set a useful-hit threshold.
- Symptom: Ignore HTTP/1.1 and the proxy chain. Why it fails: older clients may mishandle informational responses. Fix: add a protocol gate, proxy tests, and a kill switch.
- Symptom: Measure only TTFB. Why it fails: earlier hints may not improve rendering and may compete for bandwidth. Fix: measure LCP, duplicates, bandwidth, and errors.
Follow-up questions and answers
What if a hinted resource is no longer needed?
Limit hints to safely speculative assets and cap the invalid-download rate. 103 cannot guarantee that a resource will be used.
Should you keep sending 103 across a cross-origin redirect?
Skip it by default, or restrict it to safe connection warm-up unrelated to the final target. Browsers may discard the first 103 and proxies may reorder responses, so decide from an end-to-end test.
May the final Link differ from the 103 Link?
Yes: 103 is a hint and the final response is authoritative. A large mismatch indicates a poor predictor, so narrow the hint set and monitor duplicates.
How do you prevent 103 from leaking user information?
Do not include authorization, cohort, or sensitive URLs. Generate hints from a public low-risk asset set, while final CSP and authorization checks remain active.
When is ordinary HTML preload better than 103?
Use final-HTML preload when assets are known only after HTML generation or when informational responses cannot be reliably delivered. 103 is useful when the server learns the asset set earlier than it can produce HTML.