An HTTP server can emit a 103 Early Hints informational response before it has produced the final response. A client may act on suitable fields in that interim message, such as starting a preload named by Link, even though the eventual status code, header fields, and representation are still pending.

This creates a deliberate split between speculative work and authoritative response semantics. The interim response can move selected preparation earlier in time, but it cannot stand in for the final response or determine its meaning.

An informational response does not finish the exchange

Status code 103 belongs to the informational 1xx class. It precedes a final response rather than replacing one.

A simplified exchange can look like this:

HTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
Link: </app.css>; rel=preload; as=style

<!doctype html>
...

The first header block gives the client information that may support preparation. The second response is final and carries the semantics that govern normal processing of the request result.

RFC 8297 permits a client to evaluate fields from 103 speculatively. It also states that this evaluation, apart from performance optimizations, must not alter processing of the final response. That boundary prevents an optimization channel from becoming a second source of authoritative response metadata.

A hint can be useful before it is certain

The server sends fields that it expects are likely to appear in the final response. That expectation is not a promise that every hinted field will be repeated unchanged.

This matters when response generation has two timing layers. A routing layer, template manifest, or cached metadata may identify probable dependencies quickly, while application work needed to produce the final response takes longer. Early Hints can expose the stable prediction without forcing the server to wait for final response construction.

The eventual computation can produce a different result. A resource mentioned in 103 may be absent from the final response, or the final response may contain links that were not hinted earlier. The protocol allows that difference.

The optimization therefore has an asymmetry: correct predictions can advance useful work, while incorrect predictions can cause speculative work that the final response does not need.

A common use of 103 is a Link field with rel=preload. A capable client can begin fetching the referenced resource after receiving the informational response instead of waiting for final response headers or HTML parsing.

Without an early hint, a dependency might become visible only after this sequence:

request page
    |
wait for final response headers
    |
receive or parse representation
    |
identify dependency
    |
request dependency

An early hint can expose the dependency before the final response is ready:

request page
    |
receive 103 with Link
    |--------------------> speculative dependency request
    |
final response still being prepared

The mechanism changes discovery time, not the dependency’s application semantics. A preload fetch can make bytes available earlier, but the final document and its policies still determine whether and in what context those bytes are used.

Incorrect speculation has observable cost

A hinted preload can consume network, connection, server, and client resources. If the final response does not use the resource, that work may have no corresponding application benefit.

The cost is not limited to transferred bytes. A speculative request can compete with other requests for connection capacity or client scheduling priority. The exact effect depends on protocol version, browser behavior, prioritization, cache state, and network conditions, so a 103 response alone does not establish a latency improvement.

This makes hint selection a precision problem. Resources that are conditional on late application state are weaker candidates than resources whose need is already stable at the point where the interim response is generated.

The same constraint applies to stale metadata. An intermediary can possess information from an earlier response that predicts links for a later one, but the prediction can diverge from the final origin response. RFC 8297 explicitly permits multiple 103 responses, including scenarios involving intermediaries, without making any one interim field set authoritative.

Missing fields carry no negative prediction

A 103 response may contain only a subset of fields expected in the final response. The absence of a field from the interim response does not indicate that the field is unlikely to appear later.

This property is important for incremental response construction. A server can send one useful hint as soon as it is available without needing a complete preview of final headers.

It also means clients cannot treat the interim header block as a provisional full response schema. Early Hints are additive signals for speculation, not a complete declaration against which the final response should be compared.

Security policy can constrain speculative fetches

Early resource acquisition happens before final response processing, so policy handling needs an explicit boundary as well. Browser processing can apply a Content-Security-Policy delivered with Early Hints when deciding whether an indicated resource may be preloaded.

The final response can carry a different policy. A resource already fetched because an early policy allowed the preload does not thereby gain permission to participate in rendering under a stricter final policy. Fetching a resource and authorizing its later use are separate decisions.

This distinction mirrors the broader protocol design: early processing may initiate reversible or discardable preparation, while final response semantics retain authority over the request result.

Redirects expose the prediction boundary

A server can emit Early Hints and later return a redirect rather than the representation initially anticipated. That transition demonstrates the speculative nature of the mechanism especially clearly.

Browser rules account for origin changes because a hint associated with one request context must not silently become authoritative metadata for a different origin reached later. Current browser processing discards the early hint when the request results in a cross-origin redirect.

The observable consequence is that an early action may have started but its result may not be usable after final routing becomes known. Early timing creates opportunity, not certainty.

Metrics need to distinguish interim bytes from final headers

Early Hints also change the meaning of timing observations. A metric described as time to first response byte can record the arrival of the 103 rather than the arrival of final response headers.

That is a valid measurement of first response activity, but it answers a different timing question from the interval until the final response begins. Systems that introduce Early Hints can therefore show an earlier first-byte timestamp even when final response generation is unchanged.

For browser performance data, separate timing attributes can represent the first interim response and the final response headers. Keeping those events distinct avoids attributing application-response completion to an informational message.

The useful boundary is speculation without authority

103 Early Hints creates a narrow protocol channel for work that can safely begin before the final response is known. Its value comes from moving selected preparation across a latency boundary while preserving the final response as the semantic authority.

That separation also defines its failure modes. A bad prediction can waste work, an omitted hint says nothing about later headers, a redirect can invalidate the original context, and an early policy decision does not override the final policy. The mechanism is therefore strongest when the hinted information is stable enough to justify speculation but not required to be final.

Software Engineering HTTP Web Performance Protocol Semantics