Between the moment a browser asks for a page and the moment your origin finishes rendering it, nothing useful happens on the client — hundreds of milliseconds of paid-for silence. Early Hints spends that silence: the edge sends a preliminary 103 response listing the critical assets, and the browser starts fetching them while the HTML is still being built. Done right, it pulls your largest paint forward by whatever your server think-time was. Done wrong, it preloads garbage with priority.
What Early Hints actually does
A 103 Early Hints response is an informational status sent before the real response, carrying Link headers — the same rel=preload and rel=preconnect hints you can put in HTML, but delivered before any HTML exists. CDNs implement it the clever way: the edge observes the Link headers on your successful responses, caches them, and replays them as a 103 on the next request for that page, before contacting your origin at all. That means the hints arrive at effectively zero latency even when your origin is slow — which is precisely when they are worth the most. Support is real but bounded: Chromium-family browsers act on 103 over HTTP/2 and HTTP/3, and major edges only emit it on those protocols, so this feature stacks on top of a healthy protocol setup rather than substituting for one.
Choosing what to hint
The candidate list is short by design: the render-critical CSS, the LCP image if it is predictable, at most a couple of preconnects to third-party origins that every page uses (a fonts host, an asset domain). The test for each candidate is brutal — would the browser otherwise discover this resource only after parsing HTML, and does the page visibly wait on it? Fonts are a frequent win because they hide behind CSS and get discovered late. Hero images are a win when the template is stable. JavaScript is usually not: preloading a bundle that executes late moves nothing the user sees, and it competes for bandwidth with the things that do.
Enabling it: origin headers, edge cache
The working pattern on the platforms that support it: emit correct Link headers from your origin on HTML responses, then switch the Early Hints feature on at the edge and let it cache and replay them. Check three platform-specific behaviours in the documentation while you set it up: which protocols 103 is emitted on, whether hints are replayed for pages behind authentication (a cached 103 can be sent to a visitor who will then receive a 403 — harmless for assets, but know it happens), and how the hint cache is invalidated when your Link headers change. If a page's critical assets are fingerprinted and change per deploy, your Link headers change per deploy too, and a stale hint preloads a file that no longer exists — wasted bytes, not breakage, but worth purging alongside the HTML.
The overhinting trap
Every preload is a command, not a suggestion: the browser fetches it at high priority whether or not the page turns out to need it. Hint ten resources and you have built a bandwidth auction in which your LCP image bids against nine other files on the user's constrained uplink — mobile users, again, pay first. Overhinting also bloats the header block itself, and header size limits are real. Keep the list to a handful, review it whenever the template changes, and delete hints for assets that no longer exist; a hint list is config, and unowned config rots. If you cannot name why a resource is on the list, it comes off the list.
Measuring the gain honestly
The before/after is measurable and you should demand it. In synthetic testing, compare waterfalls with the feature off and on: with hints working, the critical assets start loading during the HTML wait instead of after it, and the LCP marker slides left by roughly your server think-time. In the field, watch LCP in your RUM data, segmented to Chromium browsers on H2/H3 — the population that can act on 103 — so the gain isn't diluted by clients that ignore it. Expect the improvement to scale with origin latency: a page served in 80 ms has little silence to spend, a 600 ms server-rendered page has plenty. And expect zero gain on fully-cached HTML: if the edge serves the page itself in one round trip, there is no think-time to hide work behind, which is why this feature and HTML caching are alternatives more often than teammates.