HTTP 103 Early Hints: Test Useful Resource Starts

HTTP 103 Early Hints lets a server send preliminary hints before the final response is ready. The useful question is not whether a response contains 103, but whether a supported client starts a needed resource sooner without wasting requests or revealing inappropriate information.

The MDN 103 reference documents the response and its compatibility considerations. Check your browser, server, and CDN path together. A local server emitting an informational response does not establish that every intermediary forwards it or that every client acts on it.

Understand the timing opportunity

Early Hints can matter when the server needs time to produce the main document while already knowing a stable dependency. Sending a hint during that interval can let supported clients begin work before the final document arrives.

If the final response is already nearly immediate, there may be little useful head start. Likewise, a dependency discovered early through another mechanism may gain little. Measure the actual critical path rather than adopting the feature because an example waterfall looks impressive.

Keep 103 separate from the final response. It is not a redirect, an application success result, or proof that the requested page will ultimately be returned. The final status, headers, and body still need to be handled correctly.

Choose a stable candidate

Start with a small set of resources genuinely needed by the intended page, such as an approved stylesheet. Avoid hinting every script, image, and font. Extra early work can compete with the resources that actually determine useful rendering.

Check whether the same resource is used for all relevant variants. An authenticated page, locale, experiment, or device layout may select different dependencies. A hint based on the wrong variant can produce unused downloads and confuse performance attribution.

Do not include private or token-bearing URLs in broadly cached hints. Review the information exposed and the cache boundary. A performance optimization should not leak a signed asset URL or a personalized identifier to another visitor.

Match request attributes

Review the relevant preload or connection-hint attributes in the documentation for the chosen resource. If request mode, resource type, or cross-origin settings differ from the eventual request, the browser may not reuse the work as intended.

Use the browser's network tools to identify whether the hinted request and the document-initiated request are the same useful fetch. Two similar URLs in a log are not enough. Check initiators, cache behavior, request attributes, and transferred bytes.

For fonts and other cross-origin dependencies, test the exact production origin configuration. Do not relax cross-origin restrictions as a quick fix. A correct hint must fit the application's existing resource security and privacy requirements.

Observe the complete delivery path

Test through the CDN and proxy layers users actually reach. Record which component creates the hint and how the final response is generated. A development server bypassing production intermediaries can produce a misleading success result.

Check successful pages, errors, redirects, and authentication outcomes. A hint can become wasted work when the final response changes direction. Keep the candidate list appropriate for those outcomes, and avoid treating an informational response as permission to access a protected resource.

Use the normal configured endpoints and supported diagnostics. Do not open an unprotected alternate origin merely to make a test easier. If an intermediary does not support the desired behavior, record that limitation and keep the final page functional without the optimization.

Compare page-level results

Run a controlled comparison with the feature enabled and disabled using matching content and network conditions. Record when the resource starts, when it completes, and when the relevant page content becomes useful. Retain multiple runs rather than selecting the best one.

Separate cold and warm caches. A previously cached stylesheet can hide any initial-fetch benefit. Conversely, a test that clears every cache may overstate the importance for returning visitors. Report both when both are relevant to the audience.

Also measure wasted bytes and resource contention. An earlier request is not necessarily a better result if it delays a more important image or competes with the main document. The objective is user-facing improvement, not a waterfall with more activity near the top.

Keep a safe rollback

Deploy a small canary and confirm that clients without useful 103 support still receive a normal complete final response. Early Hints should remain an optional optimization, not a dependency required for correctness.

Document the resource owner and invalidation process. If a hashed stylesheet URL changes, stale hints should not remain indefinitely. Include this path in the normal deployment and cache review instead of maintaining a separate forgotten list.

JSON Diff can compare redacted hint configurations. It does not capture informational network responses or measure page rendering. Our Server-Timing guide covers another diagnostic layer, not a substitute for a real browser waterfall.

Conclusion

Use Early Hints only where there is a measurable timing opportunity and a stable needed resource. Verify request reuse, privacy boundaries, intermediary behavior, and complete page outcomes. A visible 103 is evidence of a mechanism, not evidence that users benefited.