Early Hints: How Cloudflare Can Improve Website Load Times by 30%

A Head Start on Page Loads

Web performance is often framed around file sizes, compression, and caching — but there's another bottleneck that gets less attention: the idle time browsers spend waiting for a server's initial response. That period, often called "server think time," is when an origin is compiling a response, and the browser can only wait. Cloudflare's support for Early Hints targets precisely this gap.

The feature is now in beta and available to all Cloudflare customers at no cost. In initial tests, the company has recorded more than a 30% improvement in first-time page load times for browsers using Early Hints.

Early Hints is a web standard defined by RFC 8297, which introduces a new HTTP status code: 103 Early Hints. A server sends a 103 response while a 200 OK (or error) response is still being prepared. That early response contains hints about which assets the client will likely need to fully render the page — allowing the browser to start fetching those resources during what would otherwise be dead time.

It's a straightforward idea with a practical benefit: instead of the browser sitting idle while the origin computes a dynamic page, it can begin retrieving stylesheets, scripts, and other subresources immediately. The client gets its instructions early and is ready for the final response before it even arrives.

Why Cloudflare Is Placed to Handle This

While the concept is simple, implementation is not. Origins are often ill-equipped to emit 103 responses. Most HTTP server infrastructure is built on the faulty assumption that a request maps one-to-one to a response, making it difficult to send multiple responses for a single request. Cloudflare's edge network sits between the client and the origin, which gives it the ability to handle this complexity on behalf of the origin. It's also close to the end user, which means hints travel extremely quickly. Additionally, Cloudflare already sees the full request and response flow for its customers, so it can generate hints automatically without any origin-side changes.

There are several advantages to having Cloudflare manage Early Hints:

1. It sidesteps the legacy HTTP server limitations that make emitting 103 responses from origins impractical.
2. The edge network can serve hints quickly because it's geographically close to users.
3. Hints can be generated automatically from observed traffic patterns, requiring no setup on the customer's origin.
4. Handling the standard at the edge accelerates broader adoption of the technology.

The Problem with Waiting

The typical request/response cycle leaves noticeable room for optimization. When a browser loads a page, it first performs DNS resolution, establishes a connection, and then sends the HTTP request. Once that request is sent, everything halts while the origin server executes business logic — database lookups, personalization, fraud detection — before it can return even the first byte of the response. Only then can the browser begin parsing HTML, building the DOM, and discovering subresources like images, scripts, and stylesheets.

Because the browser doesn't know what subresources it needs until that initial HTML arrives, every asset is subject to an unavoidable dependency: the response must be fully thought through before the browser can even start loading critical resources. Consider the performance waterfall of a checkout page from pinecoffeesupply.com, a Shopify-hosted store:

In that example, rendering could not begin until the document was returned and the stylesheet and four scripts subsequently loaded. The browser could have gotten a head start had it known about those resources earlier.

"Entrepreneurs know that first impressions matter. Shopify's own data shows that on average, when a store improves the speed of the first page in the buyer journey by 10%, there is a 7% increase in conversion. We see great promise in Early Hints being another tool to help improve the performance and experience for all merchants and customers." — Colin Bendell, Director Performance Engineering at Shopify

The Mechanics of a 103 Response

Early Hints is designed to prep the browser for what's coming in the final 200 OK response. The server sends a 103 response with Link headers identifying assets that are likely to be needed. The browser can then preload or preconnect as instructed, and when the final response arrives, it's ready to render.

The RFC lays out this example of a request/response transaction:

Client request:

GET / HTTP/1.1 
Host: example.com

Server responses:

Early Hint Response

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

⏱_...Server Think Time…_ ⏱

Full Response

HTTP/1.1 200 OK
     Date: Thurs, 16 Sept 2021 11:30:00 GMT
     Content-Length: 1234
     Content-Type: text/html; charset=utf-8
     Link: </style.css>; rel=preload; as=style
     Link: </script.js>; rel=preload; as=script

[Rest of Response]

The key distinction is what the browser can do during that think time. Instead of waiting idly, it can act on the hints and get a running start on resource loading.

What About Server Push?

This isn't the first attempt at solving the problem of idle browser time. HTTP/2 server push was a prior effort, but it failed on two counts.

The Wrong Bytes at the Wrong Time

Server push forced assets onto clients without regard for whether they were already cached. It also tended to delay the HTML document itself, which worsens performance overall because it pushes back the moment when the browser discovers all the other resources on the page. Web performance engineer Pat Meenan wrote about this in a thread on Chrome's intent to deprecate server push:

Push sounds like a great solution, particularly when it can be done intelligently to not push resources already in cache and if it can exactly only fill the wait time while a CDN edge goes back to an origin for the HTML but getting those conditions right in practice is extremely rare. In virtually every case I have seen, the pushed resources end up delaying the HTML itself, the CSS and other render-blocking resources. Delaying the HTML is particularly bad because it delays the browser's discovery of all of the other resources on the page. Preload works with the normal document parsing and resource discovery, letting preloaded resources intermix with other important resources and giving the dev, browsers and origins more control over prioritization.

Early Hints steers clear of these issues by signaling rather than commanding. Browsers can prioritize loads using their own heuristics about cache state and resource priority. When used with rel=preconnect, Early Hints can also accelerate connection and TLS setup for the many third-party origins that modern pages depend on — something that's time-intensive but not bandwidth-intensive — without risking the collateral damage of preloading superfluous assets.

Adoption Barriers

The second problem with server push was that it never gained traction across the full content supply chain. Even though browsers supported it, major CDNs — including Cloudflare — did not implement it at scale. Standards like Early Hints only become useful when they're supported by every key part of the chain: browsers, origins, and CDNs. Cloudflare issuing 103 responses from the edge directly addresses that gap for its customers.

Solving the Adoption Problem

New web standards often stall because of a chicken-and-egg problem: browsers won't invest in support until servers deliver the standard, and servers won't implement it until browsers speak the language. Early Hints faces an even higher barrier because 103 is an unusual status code and many HTTP servers and application stacks don't cleanly support multiple responses to a single request.

Cloudflare's strategy relies on two parallel efforts:

1. Working directly with Google Chrome and other browser teams to ship support for the standard at the same time, creating immediate critical mass for Early Hints.
2. Building ways for Cloudflare's edge to emit hints to compatible clients without requiring the origin server to support the standard. Shopify's performance engineering team has been a key design partner in shaping the implementation and testing production deployments.

Early Hints is rolling out in two forms: one available now, one in development.

Now: Converting 200 OK Link: Headers into 103 Early Hints

Instead of requiring origins to generate 103 responses, Cloudflare leverages the Link response header, which many customers already use to declare asset dependencies. The process works like this:

• Cloudflare parses origin responses for Link headers with preload or preconnect rel types. These tell the browser which assets to fetch immediately (preload) or which origins to open connections to without transferring bytes (preconnect).
• Those headers are cached at the edge, ready to be served as a 103 Early Hints payload.
• On subsequent requests for the asset, Cloudflare immediately sends the cached Early Hints response to the browser while proxying the request to the origin for the full response.
• The complete origin response is then forwarded to the browser when ready.
• The Link headers in the 200 response are compared against the cached version. If they've changed, the stale Early Hints are purged and the new ones cached.

Coming Soon: Smart Early Hints at the Edge

The next iteration, Smart Early Hints, will use machine learning to generate hints even when origin responses don't include Link headers. By analyzing historical request/response patterns for customers, Cloudflare can infer which assets should be preloaded for faster page loads. Expect it in the coming months.

Browser Support

Cloudflare has coordinated closely with Google Chrome, Microsoft Edge, and Mozilla Firefox, all of which have announced plans to support Early Hints. Progress can be tracked here and here. Additional browser support is anticipated.

Benchmarking the Impact

Once you're in the beta and the feature is enabled, you can test Early Hints with Google Chrome version 94 or higher. As of September 16, 2021, the Chrome Dev channel is at version 94.

Testing with Chrome 94+

Enable Early Hints in Chrome by running (macOS syntax; the same flag works on Windows or Linux):

open /Applications/Google\ Chrome\ Dev.app --args --enable-features=EarlyHintsPreloadForNavigation

Testing with Web Page Test

1. Open webpagetest.org.
2. Enter a test URL with the necessary preload/preconnect rel types in the response's Link header.
3. Select Chrome Canary (or Chrome 94+).
4. Under advanced settings, choose Chromium.
5. In the command-line field at the bottom of the Chromium section, paste: --enable-features=EarlyHintsPreloadForNavigation.

• Remove the flag for a side-by-side comparison without Early Hints.

You can also test via Chrome's Origin Trials.

Using Web Page Test, Cloudflare has measured over 30% improvement in content loading time, as captured by Largest Contentful Paint (LCP). An example test filmstrip:

Testing Notes and Caveats

• Chrome won't support Early Hints over HTTP/1.1 or earlier protocols.
• Chrome won't support Early Hints for subresource requests.
• Experiment with different rel types and other Cloudflare performance features like Argo.
• Use the ResourceTiming API to identify assets loaded early; they'll return initiator=EarlyHints.

Signing Up for the Beta

Early Hints is live at Cloudflare's edge globally and currently in beta testing with selected customers. To request access:

1. Log in to your Cloudflare Account.
2. Open the dashboard and navigate to the Speed tab.
3. Click the Optimization section.
4. Find the Early Hints beta card and request access. Activation is handled in batches.

The Speed tab also contains the beta implementation for exploration. Cloudflare intends the feature to be freely available to everyone.