When a browser requests a webpage, it normally waits for the server’s response before discovering many of the resources needed to render the page.
If the server spends significant time generating HTML, that waiting period can delay the discovery of stylesheets, fonts, and other important resources.
HTTP 103 Early Hints offers a way to use part of that waiting time. The server or an intermediary can send preliminary information about resources that the browser is likely to need before the final response is ready.
The mechanism is defined by RFC 8297. It is an established HTTP capability, although support and deployment behavior vary across browsers, servers, and content-delivery networks.
The waiting-time problem
Consider a server-rendered application that needs several hundred milliseconds to prepare its HTML response.
The browser cannot discover a stylesheet referenced inside that HTML until the relevant response data arrives.
If the stylesheet is required for rendering, its late discovery can extend the time before the page becomes visually useful.
Early Hints attempts to reduce this delay by communicating selected resource information while the final response is still being prepared.
An informational response before the final response
HTTP status code 103 is informational. It is not the final result of the request.
A simplified exchange might look like this:
GET /article HTTP/2
HTTP/2 103
link: </assets/article.css>; rel=preload; as=style
HTTP/2 200
content-type: text/html; charset=utf-8
<html>
...
</html>The browser receives the resource hint before the complete HTML response.
A supporting browser may begin fetching the stylesheet while the server continues preparing the page.
The final response remains authoritative. Early Hints does not replace HTTP 200, redirects, error responses, or the normal processing of response headers.
What belongs in an Early Hint?
The most useful candidates are resources that are important for rendering and are very likely to be required by the final page.
Examples may include a critical stylesheet, a frequently used font, or a connection to a required resource origin.
However, sending hints for every resource can be counterproductive. Excessive preloading may compete with more important downloads and consume bandwidth unnecessarily.
Resource hints should therefore be selected according to actual application behavior, not generated indiscriminately from every dependency.
The role of content-delivery networks
Content-delivery networks can make Early Hints useful even when the origin application does not generate a separate informational response directly.
For example, Cloudflare documents an implementation that can cache eligible Link headers and emit an Early Hints response while the final response is being retrieved.
This can allow resource discovery to begin before the origin server completes its work.
Cloudflare’s documentation specifies operational conditions, including supported protocols, eligible responses, and restrictions affecting when hints are generated or emitted.
Its implementation currently supports HTTP/2 and HTTP/3. Developers should verify their own CDN configuration rather than assuming that every intermediary supports the feature.
A hint is not a performance guarantee
Early Hints is an optimization opportunity, not a promise that a page will load faster.
The benefit depends on the timing of the informational response, the resources identified, browser behavior, network conditions, and whether the hinted resources would otherwise have been discovered significantly later.
If the final HTML response arrives almost immediately, there may be little opportunity for improvement.
Likewise, preloading resources that are already cached or are not needed for the current page may provide little benefit.
Teams should evaluate the effect using representative pages and real performance measurements rather than assuming that enabling Early Hints automatically improves every metric.
Be careful with personalized pages
Early Hints introduces an important consideration for applications serving authenticated or personalized content.
An intermediary may emit previously cached hints before it knows the result of the current request.
Cloudflare specifically documents scenarios where hints can be emitted before an origin returns an authorization failure.
Resource hints must therefore avoid exposing sensitive information through personalized URLs, user-specific asset paths, or other data that should not be disclosed before authorization.
Critical resources for authenticated pages deserve a separate review before Early Hints is enabled broadly.
How to evaluate a deployment
Start with pages where server response preparation is relatively expensive and critical resources are consistently required.
Identify a small set of appropriate resources. Confirm that the browser receives the informational response and actually begins the intended requests.
Compare results with and without the optimization under similar conditions. Examine resource timing, rendering behavior, and the effect on important user-facing performance metrics.
Browser developer tools and controlled web-performance testing can help establish whether resource discovery begins earlier.
Finally, verify that the hints remain correct when applications are deployed, resources are versioned, and cached responses are updated.
Using waiting time more intelligently
HTTP 103 Early Hints addresses a narrow but important inefficiency: browsers sometimes wait for HTML before discovering resources that the server already knows will be needed.
By communicating that information earlier, servers and CDNs can give supporting browsers an opportunity to begin useful work sooner.
The engineering challenge is choosing the right resources, understanding intermediary behavior, and measuring the outcome.
Used selectively, Early Hints can complement other performance techniques. Used indiscriminately, it risks adding complexity without delivering meaningful improvements.
