Your product page's origin needs about 400 ms to generate its HTML. What does an HTTP 103 Early Hints response let the browser do during that window, and how would you decide whether to adopt it?

## The dead window A browser cannot start fetching a page's subresources until it knows they exist, and it learns that from the HTML. If your origin needs 400 ms to render that HTML — database queries, personalisation, template rendering — the browser spends those 400 ms doing nothing at all. The connection is open and idle. Every resource hint in the `<head>` is useless during this period, because the `<head>` has not been sent yet. `103 Early Hints` fills that window. ## What the mechanism actually is HTTP allows a server to send **informational** responses (1xx) before the final response. `103 Early Hints` is one such response, and it carries `Link` headers with the same semantics as the corresponding `<link>` elements: ```http HTTP/2 103 Early Hints Link: </assets/app.a91f2c.css>; rel=preload; as=style Link: <https://cdn.example.com>; rel=preconnect HTTP/2 200 OK Content-Type: text/html ... ``` The server emits the 103 as soon as it knows what the page will need — typically before it starts the expensive work — then the final `200` follows whenever rendering completes. The browser acts on the hints immediately, so the CSS is downloading and the CDN connection is warm by the time the HTML lands. Chromium honours `preload` and `preconnect` in early hints for navigation requests over HTTP/2 or HTTP/3. Crucially, this is the only mechanism that can move work into that window while the response body is still being computed. Hints inside the document cannot; they arrive with the document. ## Deciding: is there a window to fill? The first question is diagnostic. Break down TTFB. If it is dominated by **server processing**, 103 has something to work with, and roughly the size of that processing time is the ceiling on what you can gain. If TTFB is dominated by **network latency** — a distant origin, a slow connection — the 103 arrives only marginally earlier than the 200 and there is little to win. If the HTML is served from an **edge cache**, there is no think-time at all, and early hints are pointless by construction. So the honest framing to stakeholders is: early hints monetise your server's slowness. That is worth saying out loud, because it implies the alternative — making the origin faster, or serving the document from cache — removes the same 400 ms for *every* client, including the ones whose browser or CDN does not support 103. Early hints are the right call when the think-time is irreducible (genuinely personalised, genuinely dynamic) rather than merely unaddressed. ## The operational risks **Stale hints.** Asset filenames are content-hashed and change every deploy. A 103 that names last build's chunk downloads a file nobody will use and burns bandwidth on the critical path — the failure is silent, because the page still works. Hints must be generated from the build manifest by the same process that renders the HTML, never hand-maintained in server config. **Variant correctness.** On a personalised or A/B-tested page the 103 is usually emitted *before* the variant is decided. So it may only hint what is true for every variant. Hint a variant-specific bundle and half your users pay for the wrong file and then fetch the right one. **Stack support.** The origin, every proxy in front of it, and the CDN must all pass 1xx responses through rather than swallowing them. Support exists in major CDNs but is not universal, and an application framework may not expose a way to flush an informational response mid-request. This is often the real blocker. **Over-hinting, again.** Everything true of a bloated `<head>` is true here. The 103 should carry the few resources that are on the critical path and stable across requests, not the whole manifest. ## Weighing it as a decision A reasonable evaluation looks like this: confirm the think-time window exists and measure it; confirm the stack can emit and forward 103 end to end; identify a small, stable set of hints that are correct for every variant; wire their generation to the build so they cannot rot; ship behind a flag to a slice of traffic and compare field metrics for the pages concerned, not lab numbers, since the benefit depends on real connection behaviour and on how many of your users are on a browser that honours it. And keep the fallback framing: because support is uneven as of 2025, early hints can only ever be an accelerator for some users. If a page's TTFB is bad enough that 103 looks attractive, the strategic answer usually includes reducing that TTFB as well — early hints buy back the window, but the window itself is the defect.