103 Early Hints 1xx

What does 103 mean?

A 103 Early Hints response lets a server send some response headers to the client before the final response is ready — specifically so the client can start acting on useful information (like which CSS, JS, or font files will be needed) while the server is still preparing the actual page content. It's one of the newer status codes (standardized in 2017) and, unlike 102, it's actively encouraged in modern HTTP rather than deprecated.

The classic use case: a server-rendered page might take, say, 200ms to generate the HTML (database queries, template rendering, etc.) — but the server already knows at request time which CSS and JS files the page will reference. With 103, the server can immediately send Link: <style.css>; rel=preload headers (and similar for key scripts/fonts), letting the browser start fetching those resources during the 200ms the HTML is being generated, rather than waiting until the HTML arrives to discover what it needs.

How a 103 behaves

• It's an interim/informational response (1xx) — the final response (200, etc.) follows afterward with the actual content
• It typically includes Link headers with rel=preload or rel=preconnect hints, telling the browser what to start fetching or connecting to
• The final response repeats the relevant headers — 103 is purely an early hint; the actual final response still includes whatever headers it normally would, since 103 isn't guaranteed to be processed by all clients/intermediaries
• It requires support across the chain — the origin server, any CDN/proxy in between, and the client all need to support 103 for it to provide its benefit; if any layer doesn't support it, the response is typically just ignored (falling back to normal behavior) rather than causing an error

Common scenarios

If you're building the website:

• Your server takes meaningful time to generate HTML (due to database queries, server-side rendering, etc.) but knows in advance which critical CSS/JS/font resources the page will need — sending 103 with preload hints for these resources can improve perceived load performance
• You're using a CDN or hosting platform that supports 103 — some platforms implement this automatically based on configured preload rules, without requiring application-level changes

If you're calling an API:

• 103 is primarily relevant to browser page loads (where preloading resources matters for rendering performance) rather than typical API request/response patterns — API clients generally don't benefit from "early hints" the way browsers loading a full page do

If you're a website visitor:

• If a site uses 103 effectively, pages may feel slightly faster to load — critical resources (fonts, key stylesheets) may already be loading by the time the HTML itself arrives, entirely invisible as a distinct "step" from your perspective

Real-world examples

Some CDN and hosting platforms have implemented automatic 103 Early Hints support, generating preload hints based on previously-observed resource usage patterns for a given page — meaning sites hosted on these platforms can benefit from 103 without any application code changes. Performance-focused discussions of web page loading often cite 103 as part of a broader toolkit (alongside resource hints like <link rel="preload"> in HTML itself, HTTP/2 server push — now largely deprecated in favor of 103 — and other techniques) for reducing the time between a request starting and critical resources becoming available.

SEO implications

Faster page loads are a positive signal for both user experience and various search engine ranking factors related to page speed — to the extent 103 meaningfully improves load times for pages where server-side generation takes noticeable time, it can contribute positively to these performance-related metrics, though it's one of many factors and its impact depends heavily on whether the specific page's bottleneck is actually "time to generate HTML" vs. other factors.

FAQ

What's the practical benefit of 103?

It lets browsers start fetching critical resources (CSS, fonts, key scripts) before the full HTML response arrives, by sending preload hints as soon as the server knows what will be needed — even if the HTML itself takes additional time to generate.

Do I need to change my HTML to use 103?

The hints themselves are sent as HTTP headers (typically Link: <url>; rel=preload) in the 103 response, separate from the HTML. Your final HTML response can (and often should) still include its own resource hints as a fallback for clients/intermediaries that don't process 103.

What happens if a client doesn't support 103?

It should simply be ignored — clients that don't recognize or process 1xx responses beyond what's strictly necessary will proceed to wait for the final response as normal, without any error. 103 is designed to be a pure enhancement with no downside if unsupported.

Is 103 related to HTTP/2 Server Push?

Conceptually similar in goal (getting resources to the client sooner) but different in mechanism — HTTP/2 Server Push (now largely deprecated/removed from browsers) allowed servers to proactively send resources without the client requesting them. 103 instead gives the client hints about what to request, letting the client's normal request/cache logic handle the actual fetching — a less aggressive, more compatible approach that has seen more lasting adoption.

How do I implement 103 on my server?

This depends heavily on your server/platform — some CDNs and hosting providers offer built-in support (sometimes automatic, sometimes via configuration), while implementing it directly in application code requires server/framework support for sending interim 1xx responses, which not all stacks support equally well.

Fun fact

103 is one of the few 1xx codes that's actively encouraged in modern HTTP (as opposed to 102, which is deprecated) — it represents a relatively rare case of the HTTP status code registry gaining new, genuinely useful, widely-adopted functionality in the 2010s, decades after most of the "core" codes were established, driven specifically by the web performance community's interest in shaving milliseconds off page load times at scale.