Early Hints Preload
Early hints (103) send the preload and preconnect hints before the final response, so the browser starts fetching subresources while the server is still computing the document.
Definition
Early hints is the HTTP 103 informational status that lets the server send Link headers — preload, preconnect, modulepreload — before the final response, so that the browser begins fetching critical subresources in parallel with the server computation that produces the document, reducing the waterfall where the browser waits for the document to discover its dependencies.
Context and scope
Applied in server-rendered pages where the document computation is slow and the subresources are knowable before the document is ready.
Common misconceptions
- Early hints are just Link headers — Link headers in the final response work; early hints send them earlier, before the response, to start the fetch sooner
- Early hints help every page — they help when the server computation is slow and the subresources are knowable early; for a fast response they add overhead for no gain
Anti-patterns
- Sending early hints for resources that the document will not actually use, triggering speculative fetches that waste bandwidth
- Sending 103 after beginning the final response body, which violates the protocol and is dropped by the client
Related concepts
Authoritative source
What it is
Early hints is the HTTP 103 informational status that lets the server send Link headers — preload, preconnect, modulepreload — before the final response, so that the browser begins fetching critical subresources in parallel with the server computation that produces the document, reducing the waterfall where the browser waits for the document to discover its dependencies. Applied in server-rendered pages where the document computation is slow and the subresources are knowable before the document is ready. The protocol’s semantics — safe versus unsafe, idempotent versus non-idempotent, cacheable versus non-cacheable — are contracts the client and intermediary rely on, and violating them breaks the web.
How it works
Headers carry the negotiation: content type, encoding, caching directives, and conditional request validators together let a client and server reach the cheapest correct response. Connection reuse eliminates handshake overhead; multiplexing removes head-of-line blocking; streaming avoids buffering the entire body. Each feature has a failure mode — keep-alive on a broken proxy, multiplexing with a misbehaving server — that must be detected and handled.
When to apply and pitfalls
Apply whenever a client and server communicate across a trust boundary the protocol already spans. The pitfall is treating HTTP as a transport and ignoring its semantics — POSTing a retrieval, marking a mutating request cacheable, or omitting the validator that would enable a 304. Intermediaries — CDNs, proxies — implement the standard literally, so semantic violations produce surprising behavior far from the origin.