Backend Interview: Explain HTTP 103 Early Hints and Preload Trade-offs

Prompt and context

This HTTP, gateway, and performance question fits backend, platform, and infrastructure roles. The origin has a predictable wait before final HTML is ready. You must decide whether to send 103 and avoid wrong preloads, old-client parsing failures, and duplicate downloads.

What the interviewer evaluates

• Distinguishing 103 hint semantics from final-response semantics.
• Using server think time, resource stability, and cache hits to judge value.
• Designing graceful fallback on HTTP/2 or HTTP/3 instead of making 103 a required path.
• Verifying that preload does not create duplicate requests, wrong resources, or excess bandwidth.

Clarifying questions

Confirm whether the wait comes from dynamic HTML generation or network transfer, whether the request is a top-level navigation, whether clients and proxies handle 1xx reliably, whether resource URLs, versions, and as values are stable, and whether resources are cacheable. If the final response can be sent immediately, a normal Link header or an HTML link element is simpler. If resources vary with authentication, redirects, or personalization, wrong early hints may cost more than they save.

30-second answer framework

103 is a hint before the final response, not the page result. While generating HTML, the origin can send 103 with Link: rel=preload or preconnect so the client prepares resources in parallel; the final 200 still supplies authoritative headers. Enable it only when server think time is material, predictions are stable, and HTTP/2 or HTTP/3 is reliable. Measure cache use, duplicate downloads, LCP, errors, and bandwidth, with a normal final-response fallback for older clients.

Step-by-step deep dive

1. Find the optimization window. Measure the wait between receiving the request and having final HTML. If the origin quickly returns 200, 103 has no useful gap; keep ordinary preload in the final response.
2. Define 103 semantics. 103 says the final response is likely to include these fields. A client may speculatively prepare, but the hint cannot replace or change the final response's semantics.
3. Choose hint content. Prefer stable, critical, cacheable CSS, scripts, or connection origins. Resource version, media type, and cross-origin credentials must match the final response; do not hint uncertain personalized assets.
4. Constrain protocol and clients. Prefer HTTP/2 or HTTP/3 and verify that proxies, browsers, and observability paths handle 1xx correctly. Disable or downgrade for old HTTP/1.1 clients that may treat 103 as final.
5. Handle the final response. The final 200/3xx/4xx decides the page result. If a 103 hint becomes wrong, the client follows the final response; an intermediary must not cache the hint as the final object.
6. Measure value and cost. Compare first-view LCP, resource hits, duplicate downloads, bandwidth, and errors before and after. If redirects, disabled caching, or resource variants waste preloads, narrow the page set or remove 103.

Model answer

I would not enable 103 everywhere because it sounds faster. I would first verify meaningful dynamic HTML generation time and a top-level navigation. If CSS and critical script URLs, versions, as, and cache behavior are stable, I would send hints over HTTP/2 or HTTP/3:

HTTP/2 103 Early Hints
Link: </style.abc.css>; rel=preload; as=style
Link: </app.abc.js>; rel=preload; as=script

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Link: </style.abc.css>; rel=preload; as=style

The final response remains authoritative; 103 does not promise that a resource will be used. For old clients, unreliable proxies, or pages where redirects and personalization change resources, I fall back to normal Link headers in the final response. I would run an experiment measuring server wait, LCP, cache hits, duplicate downloads, bandwidth, and 4xx/5xx. If hints do not cover a real gap, I remove 103.

Common mistakes

• Treating 103 as the final status → the client may think the page succeeded → explain that the final response decides the result.
• Copying every HTML resource into 103 → personalized or non-cacheable assets download twice → hint only stable critical resources.
• Ignoring protocol and proxy compatibility → old clients may parse 1xx incorrectly → prefer HTTP/2/3 and provide fallback.
• Measuring only LCP → wasted preload bandwidth can hide a local gain → monitor duplicate requests, cache, and errors too.
• Omitting authoritative final headers → hints are not final metadata → repeat required Link fields in the final response.

Follow-up questions

How is 103 different from HTTP/2 Server Push?

103 lets the client decide whether to fetch; Server Push sends resources proactively and can push assets already cached by the client. When cache state is uncertain, 103 makes unnecessary transfer easier to avoid.

What if the final response redirects cross-origin?

Connections or resources started early may be discarded, turning the hint into extra bandwidth and connection cost. Enable it only for stable entry points and include redirect rate in the experiment.

How do you handle dynamic asset versions?

Use a known content-hashed URL, or hint only a version guaranteed to match the final response. If the version is unknown, wait for final HTML rather than guessing.

Why not send 103 on every page?

Without server think time there is no parallel work to expose, and deeper navigations may already have cached the critical assets. Roll out by entry page, protocol, cache behavior, and measured value.