HTTP 103 Early Hints is an informational response that can tell a client about resources likely to be useful before the final response is ready. It can help begin supported preload or connection work earlier. It is not the final page response and does not guarantee that every client uses every hint.
A good deployment identifies a real waiting period and a resource that benefits from earlier discovery. This guide explains selection, compatibility, privacy, and measurement so early hints improve the user path rather than add speculative traffic without evidence.
Identify the performance opportunity
Measure where the page waits before discovering important resources. If the final HTML arrives quickly and already exposes the resource early, an informational hint may add little value.
Choose a resource tied to user-visible performance, such as a required stylesheet or a suitable connection. Do not hint every asset merely because it appears somewhere on the page.
Record the baseline metric and test conditions. Faster resource initiation is useful only if it improves the relevant experience without unnecessary bandwidth or contention.
Keep informational and final responses distinct
A 103 response precedes the final response under supported HTTP behavior. The final response still provides the actual status, headers, and body for the request. A hint is not a completed successful page.
Do not make the application’s correctness depend on clients consuming early hints. Clients and intermediaries can vary in support. The page should still load correctly through the final response.
Test redirects, errors, and personalized paths. A resource that looked likely before the final decision may be unnecessary when the request ends differently.
Select preload and preconnect deliberately
Preload and preconnect express different work. Preload concerns fetching an identified resource with suitable metadata, while preconnect can establish an appropriate connection context earlier.
Use supported Link header syntax and resource type information. A hint with the wrong destination or type can be ignored or cause redundant work. Validate what the browser actually does.
Do not preconnect broadly to third-party origins without a purpose. Extra connections consume resources and can disclose interest or request context to another party before the page needs it.
Match cross-origin and credential context
CORS-related resources and connection modes need appropriate attributes and policy. A font preload, for example, should match the context in which the final page uses it under supported browser behavior.
An early fetch with incompatible credentials or request mode may not be reusable for the final resource request. That can create duplicate traffic instead of the intended improvement.
Test through the real browser and resource origin. A correct-looking header is not proof that the fetched resource was reused or that cross-origin access is valid.
Keep hints aligned with the released asset set
Use the same approved versioned asset identity that the final response references. Hinting an old filename while the page requests a new one wastes work and can complicate cache diagnosis.
Coordinate application and delivery-layer configuration during rollout. A CDN-generated hint and origin-generated HTML can drift if they are managed independently.
Preserve compatible fallback behavior. The final page must remain self-contained enough to discover its dependencies normally when the hint is unavailable or stale.
Review privacy before speculative requests
An early resource request can occur before the final response establishes which page or user flow will be shown. Avoid hinting private resource URLs or third-party requests that expose unnecessary information.
Keep tokens and personal identifiers out of hint URLs. Cache and telemetry systems can retain URL information. A performance optimization should not become a new private-data channel.
Apply the appropriate data-sharing and consent policy to third-party resources. Starting a connection earlier does not exempt it from the application’s privacy requirements.
Verify intermediary and protocol support
Servers, CDNs, reverse proxies, and clients can differ in how they handle informational responses. Confirm the supported configuration for the actual request path rather than only a local origin test.
Inspect whether the client receives the hint and whether the browser acts on it. An intermediary can change or omit behavior while the origin log still shows a 103 was generated.
Keep compatibility guidance current. A feature supported by one browser version should not be described as universally effective across every client population.
Measure reuse, contention, and user impact
Compare controlled runs with and without the feature using meaningful page metrics and representative network conditions. Include resource reuse and duplicate-fetch evidence, not only earlier request start time.
Look for contention with more important work. An unnecessary preload can consume bandwidth or connection capacity that delays the primary content. Earlier is not automatically better when the target is wrong.
Use a realistic sample of pages and clients. A benefit on one uncached page over a slow network may differ from ordinary repeat visits with warm caches.
Roll out a small owned hint set
Start with a limited set of clearly useful hints and a responsible owner. Reevaluate after asset, route, or delivery changes. Avoid a growing static list no longer connected to the final page.
Monitor relevant errors and performance regressions through nonsecret evidence. Do not collect complete private page URLs or credentials just to prove the feature ran.
For a server-rendered page waiting on approved backend work, a tested stylesheet preload can overlap useful fetching with that wait. The final response still defines the page, while measurement determines whether the hint deserves to remain.
Keep performance claims scoped to evidence
Report the page, client, cache state, and network conditions used for the comparison. A measured improvement should not be generalized to every browser or route without relevant coverage.
Recheck after changing backend response time or resource delivery. A hint that was valuable when HTML generation was slow may become unnecessary after another optimization. Retaining only evidence-backed hints keeps the feature small and avoids speculative work becoming permanent overhead.
Frequently asked questions
Is 103 the final successful response?
No. It is informational and precedes a separate final response.
Does every hint always produce a useful fetch?
No. Support, attributes, reuse, and the eventual page determine the outcome.
Where are examples and header behavior documented?
Read MDN’s 103 Early Hints reference and verify the actual delivery path.
For a complementary workflow, read CloudFront Invalidation: Clear the Right Cache Layer.
