HTTP 103 Early Hints: Faster Pages Without Over-Preloading

While a backend queries a database or renders HTML, the browser often has nothing to do but wait. HTTP 103 Early Hints can use that server think time: an origin, proxy, or CDN sends an informational response with Link hints so the browser can connect or fetch critical resources before the final 200, 302, or 404 arrives.

Early Hints do not make every page faster. A bad candidate can waste bytes, contend with the LCP image, or be downloaded twice when preload metadata differs from the real request. Value comes from a small, stable, cacheable hint set validated with user data.

1. Where does 103 appear in a request?

GET /products/42 HTTP/2
Host: example.com

HTTP/2 103 Early Hints
Link: </assets/app.css>; rel=preload; as=style
Link: <https://static.example-cdn.com>; rel=preconnect

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Link: </assets/app.css>; rel=preload; as=style

<!doctype html>
...

Under RFC 8297, 103 is an informational response. A client may evaluate its headers for performance while waiting, but they are only hints. They do not replace final response headers and must not change final response processing except for optimization.

This is not a redirect. The browser does not navigate away and the request is not complete; it continues waiting for the final status. A 103 does not prove the page will eventually return 200.

2. Why HTML discovery can be late

Without an early response, the browser normally connects, requests the document, waits for backend rendering, receives HTML, and parses up to each stylesheet or script. A 400 ms backend render delays discovery of render-blocking resources by roughly that think time.

Early Hints can be emitted as soon as the route and stable asset set are known. The opportunity is larger when backend TTFB is meaningful and critical assets require a new connection. A static page returned immediately by an edge cache leaves little time to recover.

3. Preconnect and preload are different

Use preconnect when a critical external origin is certain but the exact asset is not. Reserve preload for stable render-critical CSS, an essential font, or a critical script.

Support varies by browser and hint type. The Chrome for Developers Early Hints guide documents differences between preconnect and preload support. Final HTML must remain correct when a client ignores 103 entirely.

4. Preload metadata must match the real request

Link: </assets/site.css>; rel=preload; as=style
Link: </assets/app.js>; rel=preload; as=script
Link: </assets/brand.woff2>; rel=preload; as=font; type="font/woff2"; crossorigin

as controls destination, priority, and CSP context. Cross-origin fonts commonly need matching crossorigin. If an Early Hint fetches with one credentials mode but CSS requests another, the browser may not reuse it and can download the font again.

Normalize URLs and align query versions, as, type, crossorigin, and cache policy with final use. Prefer stable final asset URLs over redirects.

5. Choose candidates from the critical path

• A render-blocking stylesheet shared by nearly every route variant.
• A font actually used above the fold with an appropriate font-display strategy.
• A script essential for rendering or hydration, not below-fold widgets or analytics.
• A preconnect to an origin certain to serve a critical resource.

Do not preload every bundle, font weight, carousel image, or possible asset. Incorrect preloads can take bandwidth from the document and LCP image, with larger costs on slow mobile networks.

One correct, stable hint usually beats ten predictions.

6. Dynamic routes and personalization

A CDN can generate Early Hints from observed Link headers or route configuration, but a dynamic URL may produce several templates: login redirects, A/B bundles, locale themes, access errors, or product 404s.

If hints precede variant selection, the browser can fetch the wrong asset. Use candidates common to all variants or key configuration on reliable route, locale, and tenant information. Do not build hint URLs from sensitive cookies in ways that leak into logs or shared cache.

A final cross-origin redirect can cause browsers to discard resources and connections obtained from Early Hints, making redirect-heavy routes a poor starting point.

7. Node.js example and proxy principle

import http from 'node:http';

http.createServer(async (request, response) => {
  response.writeEarlyHints({
    link: [
      '</assets/app.css>; rel=preload; as=style',
      '<https://static.example-cdn.com>; rel=preconnect'
    ]
  });

  const html = await renderPage(request.url);
  response.writeHead(200, {
    'content-type': 'text/html; charset=utf-8'
  });
  response.end(html);
}).listen(8080);

This illustrates writeEarlyHints(); production still needs render error, timeout, and final-status handling. Emit hints at the earliest layer that understands both the route and asset manifest.

Validate the whole chain. An origin can emit 103 while a load balancer strips it; a CDN can generate 103 independently; access logs may record only the final status. Configuration at one layer does not prove delivery to the client.

8. Cacheability controls reuse

Early-preloaded resources normally pass through the HTTP cache for later page reuse. If an asset is not cacheable or metadata differs, the real request can fetch it again. Strong candidates have:

• Content-fingerprinted URLs such as app.7f3a.css.
• Suitable immutable asset caching.
• Correct CORS headers for cross-origin CORS fetches.
• No cookie dependency where possible.
• Correct content type and no unnecessary redirect.

Do not hint personalized API responses, tokenized URLs, or resources the final page may not use. Speculative fetches still consume resources and can create third-party access records.

9. Security and correctness

Only send fields safe to process before the final response. Early speculation can occur before request processing has established the final outcome.

• Never put Set-Cookie, authentication data, or private metadata in 103.
• Do not let preload URLs reveal account or user-content state.
• Keep the final response authoritative.
• Apply normal CSP, CORS, and integrity controls.
• Prefer trusted HTTPS and HTTP/2 or HTTP/3 according to infrastructure and client support.

Older clients, bots, and proxies may mishandle informational responses. Roll out to modern navigation traffic over HTTP/2+ based on observed compatibility rather than trusting a user-agent string absolutely.

10. Verify that the browser receives and uses 103

curl -sS -D - --http2 https://example.com/products/42 -o /dev/null

The output should show 103 before the final response. Then inspect a trusted HTTPS request in browser DevTools. Disabling cache can invalidate the test because reuse depends on browser caching.

1. The origin or CDN emits the intended 103 and Link.
2. Intermediaries preserve informational responses.
3. The browser starts the asset before final headers.
4. Final HTML reuses the asset without a duplicate fetch.
5. Error, redirect, and variant paths do not fetch wrong assets.

11. Measure with RUM and an experiment

Do not conclude from one laptop waterfall. Run control and treatment groups segmented by device, network, geography, cache state, and route. Track:

• LCP and FCP percentiles, not only averages.
• Critical CSS, font, and script request start time.
• Duplicate fetches and unused transfer bytes.
• Final response time to quantify the available think-time window.
• Error, redirect, and cache-hit rates.

Because 103 is an informational first response, historical TTFB measurement can be confusing. Distinguish Early Hints arrival from final response headers and optimize rendering outcomes instead of a cosmetically lower TTFB number.

12. Production rollout checklist

• The route has meaningful server think time and predictable critical assets.
• Only a small set of truly critical resources or origins is hinted.
• as, type, crossorigin, URL, and credentials mode match final requests.
• Assets are cacheable, versioned, and free of personal data.
• The final page remains correct when clients ignore 103.
• Origin, proxy/CDN, HTTP/2/3, browser, redirect, and error paths are tested.
• No material duplicate fetching or bandwidth contention occurs.
• RUM or A/B data proves LCP/FCP improvement for the target audience.
• A kill switch and asset-manifest update process exist.

HTTP 103 Early Hints turns backend thinking time into browser preparation time only when prediction is accurate. Start with one certain stylesheet or preconnect, verify cache reuse, and measure real users. Removing a hint that does not produce a clear benefit is also an optimization.