Can Early Hints Make Your Site Feel Faster?

Can Early Hints Make Your Site Feel Faster?

Yes, on pages where the server thinks for a while before it answers. Early Hints lets the server send a partial reply first, telling the browser which files to start fetching. The browser gets a head start instead of sitting idle. On fast static pages the gain is small.

We get asked about this most often after a Core Web Vitals audit comes back with a slow Largest Contentful Paint and a healthy-looking server. The page is not heavy. The browser is just waiting.

Early Hints is one of the few performance features that attacks that specific gap. Here is how it works, what it actually buys you, and when we would skip it.

What Is an HTTP 103 Response?

It is an informational response a server sends before the real one. Defined in RFC 8297, a 103 Early Hints response carries Link headers that tell the browser which resources to preload or which origins to preconnect to, while the server is still building the actual page.

The normal request cycle has a dead zone. The browser asks for a page, then waits while the server queries a database, renders a template and streams a response. During that wait the browser knows nothing about the stylesheet or font it will need, so it does nothing.

A 103 response fills that dead zone. It is not the page. It is a note that says start fetching these while you wait.

MDN documents the two headers it works with. Link is the main one, and Content-Security-Policy may also be sent, in which case it is enforced while the early hint is processed.

Why Does Sending Hints Early Help at All?

Because connection setup and file fetching are the slow parts, and they can happen in parallel with server work. A preconnect hint gets DNS, TCP and TLS out of the way for a third-party origin. A preload hint starts the download of a stylesheet before the HTML that references it exists.

MDN is explicit that preloaded resources are fetched immediately when the early hints arrive. There is no waiting for the parser, because there is nothing to parse yet.

The bigger the gap between request and response, the more this matters. A page that answers in 40 milliseconds has almost no dead zone to fill. A page that answers in 600 milliseconds has a lot.

That is why we always look at time to first byte before recommending this. Early Hints does not make your server faster. It makes the wait useful.

Which Browsers Actually Support It?

Support is uneven, and the two directives differ. Chrome's documentation states that preconnect through Early Hints works in Chrome, Edge, Firefox 120 and later, and Safari 17 and later. Preload works in Chrome, Edge and Firefox 123 and later, but not in Safari.

Chrome itself has supported Early Hints since Chrome 103, which is a pleasant coincidence given the status code number. Chrome's docs note plainly that not all browsers support preload for Early Hints, which makes preconnect the more universally reliable of the two.

There is a transport requirement as well. MDN recommends Early Hints only over HTTP/2 or later, for compatibility and security reasons, and Cloudflare's documentation says it supports Early Hints only over HTTP/2 and HTTP/3.

So the realistic planning assumption is that a meaningful share of your Safari traffic gets the preconnect benefit and none of the preload benefit. Plan for partial coverage, not a universal win.

How Much Faster Does It Really Get?

Chrome's documentation cites two results. Shopify and Cloudflare each reported an improvement of several hundred milliseconds to Largest Contentful Paint. A WebPageTest before and after comparison on a Moto G4 over DSL showed test sites loading up to a second faster.

Notice what those numbers have in common. They come from large sites with real server work and real third-party origins, measured on slow devices and slow connections. That is the profile where Early Hints shines.

We would treat "several hundred milliseconds" as the honest headline and ignore anyone quoting a precise percentage. Chrome's own page offers no more precision than that, and neither should we.

If LCP is your problem, read that number against the rest of your budget. Our guide to Largest Contentful Paint covers what else moves the same metric, usually by more.

What Can You Put in an Early Hint?

Two things: preconnect and preload. Prefetch is not supported. A preconnect hint names an origin you will need, such as a font host or an image CDN. A preload hint names a specific file and its type, such as a stylesheet.

The syntax is a Link header with a rel value of preconnect or preload, and for preload an "as" attribute describing the resource type. Cloudflare's documentation gives a preload example pointing at an image path.

Chrome documents real limits on what is worth hinting. Only cacheable resources should be preloaded, because an uncacheable resource gets fetched twice. Responsive images using srcset or media attributes may not work effectively, because the browser cannot yet pick the right variant.

Keep the list short. Three or four genuinely render-blocking resources is a good hint. Twenty is a way to compete with yourself for bandwidth, which is the same trap we described in our piece on resource hints.

How Do You Turn Early Hints On?

Most teams enable it at the CDN rather than in application code, because the CDN can send the 103 while your origin is still working. On Cloudflare it is a toggle under Speed, then Settings, then Content Optimization, and it is available on the Free, Pro, Business and Enterprise plans.

Cloudflare generates and caches early hints from what your origin already sends. Its documentation says it does this for pages ending in .html, .htm or .php or with no extension, when the response status is 200, 301 or 302, and when the response includes Link headers with preconnect or preload rel types.

That last condition is the one teams miss. Cloudflare is not guessing what to preload. You still have to emit Link headers from your origin for the important resources, and Cloudflare turns them into the early hint.

If you run your own edge, the pattern is the same. Send the 103 with Link headers as soon as the request arrives, then send the real response when it is ready.

What Breaks When You Get Early Hints Wrong?

Mostly wasted bandwidth, occasionally a security surprise. Preloading a file the page never uses costs a download on a connection that may be metered. Preloading an uncacheable file causes a double fetch, which is strictly worse than doing nothing.

Redirects are the sharp edge. MDN states that the early hints response must be discarded if the request results in a cross-origin redirect, and Chrome notes that a cross-origin redirect causes browsers to discard preloaded resources. If your canonical URL bounces users across origins, the hints evaporate.

There is also a quiet rule worth knowing. A server may send multiple 103 responses, for example after a redirect, but browsers only process the first one. Sending a second, better set of hints does nothing.

None of this is dangerous, but all of it makes measurement confusing. Test with real field data rather than assuming the feature is working because you enabled it.

Is This Better Than Just Using Preload Tags?

It is earlier, which is the entire point. A preload tag in your HTML head only helps once the HTML starts arriving. An early hint helps before that. They are not competitors, they are the same instruction delivered at two different moments.

The practical answer for most sites is to do both. Keep your preload tags for correctness and for browsers that ignore Early Hints, and add the 103 for the browsers that honour it. The duplicate costs nothing, because the browser will not fetch the same cacheable resource twice.

Where Early Hints clearly wins is on slow dynamic pages behind a CDN. Where it clearly does not matter is on a prerendered static page served from cache, because there is no dead zone to fill.

Who Should Actually Bother With This?

Sites with slow origins, heavy third-party dependencies, and a lot of mobile traffic. An ecommerce site rendering personalised pages is the textbook case. So is a marketing site pulling fonts and a tag manager from three different origins.

Teams who should probably skip it include anyone serving static HTML from the edge, anyone whose LCP problem is an oversized hero image, and anyone who has not yet dealt with render blocking resources. Fix the big things first.

We also skip it when a site is about to be rebuilt. Early Hints is a tuning step, and tuning a page you are replacing in six weeks is a poor use of anyone's afternoon.

Where Does This Fit in a Performance Plan?

Near the end, after the structural work. Reduce the payload, fix the render-blocking chain, right-size the hero image, cut the third-party scripts you cannot justify. Then, if the server still takes real time to answer, add Early Hints to make that wait productive.

The reason to know about it now is that it costs very little once the rest is done. A toggle at the CDN and a few Link headers from your origin is not a project.

If you want a second pair of eyes on where your page time is actually going, or you want the whole chain handled, we are happy to walk through it. You can find us at phoenix.studio.