skip to content

You want to use HTTP status 103 Early Hints in production to speed up page loads. Describe how it travels through the request path, what must be true for it to help, and what can break.

level: seniorimportance: should knowfreq 26%

answer

  1. 103 = informational, sent before the final response
  2. carries Link: rel=preload / rel=preconnect only
  3. win = overlap with origin think-time
  4. 1xx dropped by buffering proxies — verify end to end
  5. stale hints after a hashed-asset deploy → 404s

basics

~20 s

The origin sends a 103 informational response with Link: rel=preload or rel=preconnect fields, then later the real response. It only helps when origin think-time is large enough to cover a fetch, every hop forwards 1xx responses, and the hints match what the page actually needs. Wrong hints waste bandwidth.

solid answer

~1 min

103 (RFC 8297) is an **informational response** sent before the final one, carrying `Link` fields — typically `rel=preload` for known critical subresources and `rel=preconnect` for third-party origins. The client may act on them while the origin is still generating the page. For it to pay off: 1. **Origin think-time must be meaningful.** If the HTML returns in 20 ms there is nothing to overlap; the win scales with server processing time. 2. **Every hop must forward 1xx.** Some reverse proxies, WAFs and older HTTP/1.1 intermediaries buffer or drop informational responses, or mis-handle a 1xx followed by a final response on the same connection. Verify end to end, not just at the origin. Browser support is limited to top-level navigations and to preload/preconnect hints. 3. **Hints must be accurate and stable.** They are computed before the response body exists, so they are usually derived from the route, a previous render, or an asset manifest — which goes stale after a deploy that renames hashed files. Failure modes: wasted bytes for wrong hints, hint fields desynchronized from the built assets, and hints on non-cacheable personalized pages that vary per user. Measure with a real metric (Largest Contentful Paint or first paint), not by counting hints.

code

bash · 1 line
bash
curl -sSv --http2 https://www.example.com/ 2>&1 | grep -E '^< HTTP|^< link'

go deeper

for a junior

Know that 103 is an informational response carrying Link hints before the real response, and that the client decides whether to fetch.

for a middle

Explain where the saving comes from (overlap with server processing) and name preload versus preconnect and the as= attribute.

for a senior

Own the deployment: verify 1xx survives every hop, tie hints to the build manifest, restrict the list to render-blocking assets, and measure with field data.

for a principal

Judge whether the mechanism is worth it at all against alternatives such as caching the HTML, cutting critical resources, or inlining — and decide how hint generation stays correct across deploys and experiments.

## What 103 is HTTP has always allowed **informational (1xx) responses**: a provisional status line plus header fields sent before the final response, and never the end of the exchange. `103 Early Hints` (RFC 8297) is the modern one. Its purpose is to let a server say "whatever the answer turns out to be, you will need these resources" while it is still computing. A response sequence looks like: ``` 103 Early Hints link: </app.css>; rel=preload; as=style link: https://cdn.example.com; rel=preconnect 200 OK content-type: text/html ...body... ``` Multiple 103 responses are permitted. The header fields in a 103 are explicitly *not* binding on the final response — the final status may even be a redirect or a 404, and the hints may be wrong. That is why they must be safe and cheap to act on. ## The two useful hint types - **`rel=preload`** with a correct `as=` (style, script, font, image) starts the fetch early with the right priority and credentials mode. A wrong or missing `as` can cause a double fetch. - **`rel=preconnect`** does DNS, TCP and TLS to a third-party origin without transferring anything. This is often the *safest* early hint: the cost of being wrong is one idle connection, and the saving on a cold third-party origin can be 100–300 ms. ## Where the benefit comes from The saving is the overlap between origin think-time and the client's fetches. If the HTML takes 300 ms to render server-side, hints issued at 10 ms let the browser spend nearly 300 ms fetching CSS, fonts and connections it would otherwise only discover after the HTML arrived and was parsed. If the HTML is served from cache in 15 ms, there is essentially nothing to overlap, and you have added a frame's worth of bytes for nothing. **Slow, dynamic, personalized pages benefit most** — which is convenient, because those are exactly the pages a CDN cannot cache. ## What breaks **Intermediaries.** 1xx handling is the weak point. Some reverse proxies, load balancers, WAFs and application servers buffer the whole response before forwarding, silently dropping the 103; some older HTTP/1.1 proxies mishandle an unexpected 1xx and corrupt the connection. Your application framework must also expose an API for sending an early response (`ctx.writeEarlyHints`, `res.writeEarlyHints`, or the platform equivalent) — many do not. Test the *whole* path with a client that reports informational responses (`curl -v` on HTTP/2, or a browser dev-tools waterfall showing the early fetches starting before the document response). **Client support.** Browsers restrict 103 handling: it applies to top-level navigation requests, and only preload and preconnect hints are honoured. Do not expect subresource requests or arbitrary link relations to work. **Hint accuracy and freshness.** Hints are generated before the body exists, so they come from the route table, a build manifest, or a learned model of what the last render referenced. Two failure modes follow: after a deploy that changes content-hashed filenames, stale hints preload files that 404; and on pages whose assets vary by user segment or experiment, a fixed hint set is wrong for a fraction of traffic. Ship hint generation from the same build artifact as the page, and version them together. **Bandwidth waste.** Every wrong preload is a full resource fetched and discarded, on a connection that is often the constrained resource on mobile. Hint few things, hint the render-blocking ones, prefer preconnect where the target is uncertain. **Caching interaction.** A CDN caching the final response should not replay a stale 103 against a fresh body, and vice versa; check that your CDN treats them as one unit. Also remember early hints do nothing for a repeat visitor whose assets are already cached — the browser will consult its cache, which is exactly the improvement over push. ## Rolling it out 1. Start with `rel=preconnect` to third-party origins — low risk, easy win. 2. Add `rel=preload` for the one or two render-blocking assets that every page on a route uses. 3. Verify the 103 survives to the browser on the real production path, including the CDN. 4. Measure Largest Contentful Paint and Time to First Byte in field data (real-user monitoring), split by whether the hint was sent. Lab tests with a warm cache will show nothing. 5. Watch for 404s on preloaded URLs after deploys; alert on them. If the numbers do not move, the honest conclusion is usually that your origin was already fast, and the effort belongs elsewhere — caching the HTML, reducing critical resources, or inlining the small critical CSS.

  • Your 103 works against the origin but never reaches the browser in production. Where do you look?
    At every intermediary between origin and client. Reverse proxies, WAFs and load balancers that buffer a full response before forwarding will swallow informational responses, and some CDN configurations only pass 1xx when explicitly enabled. Test hop by hop with a client that prints informational status lines, and confirm the application framework is actually flushing the early response rather than queueing it with the final one.
  • Which pages are the wrong candidates for Early Hints?
    Pages the CDN already serves in a few milliseconds, because there is no think-time to overlap, and pages whose subresources vary per user or experiment, because a fixed hint set will be wrong for part of the traffic and waste bandwidth. Repeat visits with a warm cache also gain little, though they are not harmed since the client checks its cache before fetching.

It is the restaurant telling you the wine list while the kitchen is still cooking: useless if the food is instant, valuable if the kitchen is slow, and harmless if you ignore it.

saying these in an interview costs you the question

  • Believing the header fields in a 103 constrain the final response — they are explicitly non-binding
  • Assuming 1xx passes through every proxy untouched
  • Preloading dozens of resources, so the hints compete with the document for bandwidth
  • Expecting a benefit on pages that already return in a few milliseconds
  • Letting hint lists drift from the build manifest, so hashed filenames 404 after a deploy

context

resolving links…