Cloudflare Early Hints: HTTP 103 Mechanics, Link Header Criteria, and Edge Caching Behavior

HTTP 103 Early Hints and Cloudflare Edge Delivery

When a browser requests a dynamic page, the origin server requires processing time to execute code, run database queries, and assemble the full response. In standard HTTP exchanges, the client waits during this server think time before receiving headers and content. RFC 8297 addresses this interval by defining the informational status code 103 Early Hints. This code allows a server or caching intermediary to emit preliminary headers containing links to critical resources before the final response is ready.

According to Cloudflare Early Hints documentation, Cloudflare caches and serves these 103 responses with Link headers from your HTML pages, allowing supported browsers to preload assets or establish preconnections while the origin finishes preparing the response.

Requirements for Generating and Caching Early Hints

To have Early Hints generated and cached by Cloudflare, responses must meet three criteria documented by Cloudflare:

• URI Extension: The requested URI must have a .html, .htm, or .php file extension, or no file extension.
• Response Return Code: The response must return an HTTP status code of 200, 301, or 302.
• Link Header Relations: The response must include Link headers with rel=preload or rel=preconnect relation types.

Cloudflare illustrates a qualifying header with the following example:

Link: </img/preloaded.png>; rel=preload

RFC 8297 demonstrates that early hint headers can also declare resource types using the as attribute:

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

RFC 8297 notes that a client speculatively evaluates header fields in a 103 response, but these hints do not replace final response headers. A client should not interpret the absence of a header field in a 103 response as speculation that the header field will be omitted from the final response. Additionally, servers may emit multiple 103 responses as new information becomes available.

Cloudflare Edge Timing and Caching Mechanics

Early Hints can be enabled across Free, Pro, Business, and Enterprise plans in the Cloudflare dashboard under Speed > Settings > Content Optimization by toggling Early Hints to On. In operation, Cloudflare manages Early Hints delivery according to specific timing rules:

• Asynchronous Emission: Cloudflare asynchronously looks up and emits a cached 103 Early Hints response ahead of the main response to compatible browsers, such as Google Chrome M94 and higher.
• Edge Cache Availability: Early Hints may be emitted less frequently when the requested content is already cached. If Cloudflare CDN retrieves the response header before the asynchronous Early Hints lookup finishes, Cloudflare will not send a 103 response.
• Pre-Origin Delivery: A cached 103 Early Hints response may be emitted to the client before the incoming request reaches the origin server or a Cloudflare Worker.

Operational Considerations and Log Entries

Deploying Early Hints involves several documented edge and protocol behaviors:

• Authentication Precedence: When Early Hints is enabled on pages that require authentication, unauthenticated visitors may receive a cached 103 response containing Link headers before the origin server returns a 403 Forbidden response.
• User-Agent Disabling: Cloudflare automatically disables Early Hints for certain user agents, including select search crawler bots that exhibit incompatibilities with 1xx informational responses.
• earlyHintsCache Subrequests in Logs: Cloudflare Logs may display an influx of requests with the RequestSource marked as earlyHintsCache and HTTP status code 504. Cloudflare documents these as expected, benign internal edge subrequests querying local cache state rather than origin traffic. A status of 200 denotes an internal cache hit, while 504 denotes an internal cache miss. These subrequests are filtered out of views like Cache Analytics.
• HTTP/1.1 Persistent Connection Framing: RFC 8297 highlights that informational responses are rarely used without an Expect header field. An HTTP/1.1 client that mishandles an informational response as a final response could treat subsequent responses on the same connection as part of the initial response body, which can cause cross-origin information disclosure if requests to different origins share a persistent connection. HTTP/2 clients are less prone to framing errors because header parsing does not govern how the end of the response body is delimited.

Research Methodology and Limitations

This technical explainer was prepared exclusively from public documentation excerpts from Cloudflare Developer Docs and IETF RFC 8297, alongside a partial excerpt from Perfmatters documentation. Material limitations include truncation in the secondary Perfmatters excerpt, which restricts comparison of third-party implementation and verification guidance, and the absence of origin-side server configuration or WordPress-specific header generation instructions within the supplied Cloudflare documentation.