Frontend Interview: When Does HTTP 103 Early Hints Actually Improve LCP?

Prompt and context

You own an ecommerce homepage whose above-the-fold HTML takes time to generate. The proposal is to send 103 Early Hints before the final response so the browser can start critical CSS, fonts, or scripts. Explain when it helps, how to avoid duplicate downloads, and how to verify the LCP change. Assume a top-level navigation over HTTP/2 or HTTP/3, with correct Link headers still sent on the final response.

What the interviewer is testing

Whether you describe 103 as a hint rather than an authoritative resource list: the browser may connect or preload, while the final response remains authoritative.
Whether you identify server think-time as the overlap window; when the server can return 200 immediately, regular preload or preconnect on the main response is simpler.
Whether you cover resource stability, caching, cross-origin redirects, browser support, and protocol requirements.
Whether you validate with LCP, cache reuse, duplicate requests, and errors instead of reciting a status code.

Clarifying questions before answering

How long is server time before the first byte? If it is near zero, there is little overlap to gain; optimize the backend or main-response hints first.
Are the hinted resources stable and necessary? User, experiment, or permission-dependent resources can be wasted when guessed early.
Is this a top-level navigation over HTTP/2+? Browser handling is centered on navigation, and MDN recommends HTTP/2 or later.
Are the resources cacheable? A non-cacheable preload can be downloaded again after HTML arrives, turning a hint into extra work.

30-second answer framework

“I first verify that the page has meaningful server think-time and that this is a navigation where the client supports 103. I then hint only stable, cacheable CSS, fonts, or connection origins, and repeat correct Link headers in the final response. I avoid hints for experiment or permission-dependent resources. Before and after launch, I compare the overlap between TTFB and resource requests, LCP, duplicate bytes, and errors; clients that do not support 103 use the normal response path.”

Step-by-step deep answer

1. Quantify the overlap window

103 lets the browser connect or fetch while the server prepares the final HTML. The useful upper bound is approximately server preparation time minus the time at which the browser would otherwise discover the resource after the final response. If the server returns 200 quickly, the window is nearly zero; Chrome recommends regular Link or HTML link in that case.

2. Select stable resources instead of copying every HTML hint

Early Hints arrive before the final HTML and its user-specific variant is known. Good candidates include shared CSS, common scripts, fonts, and critical CDN connections. Personalized images, experiment branches, and permission-gated resources should wait for HTML. Split a resource into a stable part for the hint and a dynamic part for the final response when that is practical.

3. Treat cache and protocol as correctness conditions

The final page must reuse a preloaded resource. If it is not cacheable, the browser may download it once from the hint and again after parsing HTML. Cross-origin fonts also need matching crossorigin semantics. MDN recommends sending 103 over HTTP/2 or later because older clients and intermediaries may mishandle 1xx responses.

4. Keep the final response authoritative

Continue sending Link headers in the final response for clients that ignore 103 and for resources learned while rendering the HTML. A cross-origin redirect may cause browsers to discard early connections and resources, so 103 is not an irrevocable download command.

5. Measure a real experiment

Randomize real navigations with and without Early Hints. Record server think-time, resource request start times, LCP, duplicate bytes, and error rate. Chrome DevTools exposes the Early Hints initiator and cache reuse, but cache must remain enabled during the test. If LCP does not improve, check whether the resource was already cached, the hint arrived too late, a redirect discarded it, or server time is not the bottleneck.

6. Contrast it with HTTP/2 Push

103 supplies a clue and leaves the browser in control of fetching; HTTP/2 Push actively sent resources and often duplicated items already cached by the browser. The tradeoff is that Early Hints still needs a round trip and depends on browser support, but it avoids taking control away from the client.

High-quality sample answer

I would start with time before the first byte. If SSR takes 300 milliseconds and the main CSS and font are stable on every navigation, 103 can overlap their connection and download with those 300 milliseconds. I would hint only cacheable stable resources, include the right crossorigin for cross-origin fonts, and leave personalized images and experiment scripts to the final response. The final response would still include Link so unsupported clients have a normal fallback.

I would not claim that adding a status code guarantees a win. I would run a controlled navigation experiment and compare LCP, request start times, duplicate bytes, and cross-origin redirect rate. If the server already returns 200 quickly, the resource is in cache, or the final page frequently rejects the hint, a regular main-response hint—or no preload—is safer. That answer exposes the benefit window, the cost of wrong guesses, and the fallback.

Common mistakes

Mistake → Treating 103 as equivalent to 200. Why it fails: 103 is informational; the final response defines the result and resources. Fix: say the hint can be ignored and retain final Link headers.
Mistake → Copying every HTML preload into 103. Why it fails: user variants are unknown at hint time, so dynamic resources waste bandwidth. Fix: choose stable, high-probability resources only.
Mistake → Measuring only LCP. Why it fails: a non-cacheable preload or wrong cross-origin attribute can start earlier while increasing total bytes. Fix: measure cache reuse, duplicate requests, bandwidth, and errors too.
Mistake → Sending it to every HTTP/1.1 request. Why it fails: 1xx handling varies and Early Hints targets navigation. Fix: gate by protocol, request type, and client capability, with a normal-response fallback.

Follow-up questions and responses

The final response often redirects to another origin. Would you still send 103?

Only cautiously. MDN and Chrome guidance note that a cross-origin redirect can make browsers discard early connections and resources. Restrict hints to a stable final entry point or same-origin resources that survive the redirect, and set a redirect-rate threshold.

CSS differs between experiment groups. What can you hint?

Hint only the CSS shared by every group; leave experiment-specific chunks to the final HTML. If there is no stable intersection, do not preload. The bandwidth cost of a wrong guess can exceed the saved wait.

How do you prove the gain came from 103 rather than a warmed cache?

Randomize groups with matched cache states and report cold and warm caches separately. Measure the overlap between resource requests and server think-time, not only one LCP value; inspect the Early Hints initiator, cache hits, and duplicate downloads.

What if a browser does not support a particular Early Hints directive?

Keep the final Link and HTML declarations as fallback. Start with the broadly supported preconnect, roll out preload according to the target-browser matrix, and monitor errors.