103 Early Hints: Faster — or Just Wrong Earlier?

You enable Early Hints at the CDN. The network waterfall now shows 103 Early Hints before the real 200 OK. The browser can start CSS, fonts, or connections while the server is still generating HTML. It looks like free performance.

That is exactly what 103 is designed to do. But loading earlier is only faster when the browser loads the right thing early. A bad preload competes with genuinely important resources, a stale asset hash creates a failed request, and a preload that cannot be reused may be transferred twice.

The better audit question is: Are our Early Hints stable, cacheable, genuinely critical, and consistent with the final response?

What 103 actually does

RFC 8297 defines 103 Early Hints as an informational response. It can carry Link headers before the final status and complete response headers are known. A browser may evaluate those hints speculatively for preload or preconnect, while the final response remains authoritative.

The mechanism is most useful when the server has real wait time: SSR is waiting for data, a CMS or API is slow, a CDN must reach the origin, or routing requires computation. Chrome explicitly notes that Early Hints offer little benefit when the final response can be sent immediately. In that case, ordinary resource hints in the final headers or HTML may be enough.

Myth: Every preload makes a page faster

The HTML Standard defines preload as preemptively fetching and caching a resource for the current navigation. It is not a free, passive annotation.

Problems appear when:

• a bundle is fetched even though the route does not need it,
• a font is preloaded with the wrong crossorigin mode and requested again later,
• a hero image is preloaded while mobile chooses a different responsive candidate,
• too many high-priority resources compete for bandwidth,
• the hint still references an asset from the previous deployment.

Preload is a budget, not decoration.

Red flag 1: 103 and the deployment are out of sync

Modern frontends often use fingerprinted assets such as app.8af31.js. Early Hints adds another cache and timing layer. RFC 8297 explicitly describes an intermediary generating a 103 response from stale cached information while the final response later carries different headers.

After releases, check:

1. Does 103 reference the same critical versions as the final page?
2. Are old hashed files still requested?
3. Do old assets remain available long enough that a briefly stale hint does not become a 404?
4. How quickly does the CDN hint layer update?

If deployments delete old assets immediately while edge hints still reference them, an optimization becomes extra network work.

Red flag 2: The preload cannot be reused

A preload is useful only if the later real request can reuse the same resource under compatible request conditions.

Fonts are a common failure point. MDN notes that font preloads need the appropriate CORS mode, including the usual crossorigin requirement for font fetching.

Also verify:

• correct as,
• identical URL and relevant parameters,
• compatible credentials and CORS modes,
• no unnecessary redirect,
• cache headers that permit reuse.

The important question is not whether a preload exists. It is whether the waterfall shows no second download.

Red flag 3: Non-cacheable resources are loaded early

Chrome documents an important limitation: resources preloaded through Early Hints are stored in the HTTP cache and later reused by the page. If a resource is not cacheable, it can be fetched twice—once because of 103 and again when the document needs it.

Cacheability therefore belongs in the selection criteria for every Early Hints candidate. A request that starts early but must be repeated is not a win.

Red flag 4: Authenticated pages emit hint metadata before the decision

Cloudflare currently documents that cached Early Hints can be emitted before the origin response is available. An unauthenticated visitor may therefore receive a 103 response before the origin later returns 403 Forbidden.

This does not mean 103 automatically exposes protected content. It does mean URLs placed in Early Hints should not be treated as confidential metadata.

Avoid user-specific export URLs, document IDs, internal hostnames, tenant-specific paths, or signed URLs in cached hints. Any protected subresource must also enforce its own authorization.

Cloudflare also notes that its Early Hints cache is keyed by request URI and ignores query strings. If critical resources vary by query parameter, test that provider-specific behavior explicitly.

Red flag 5: TTFB improves but the page does not

Early Hints changes measurement. MDN notes that TTFB on pages using 103 commonly refers to the first byte of the interim response. A dashboard can therefore report a much better TTFB even though the final HTML starts at the same time as before.

Where supported, finalResponseHeadersStart helps separate the final response from the first interim response. Also compare LCP, FCP, the resource waterfall, duplicate requests, transferred bytes, and cache hits.

A greener metric is not proof of a faster experience.

Red flag 6: HTTP/1.1 is treated like HTTP/2

RFC 8297 warns about HTTP/1.1 clients that mishandle informational responses. MDN recommends using 103 primarily over HTTP/2 or newer for compatibility and security reasons. Cloudflare currently supports Early Hints over HTTP/2 and HTTP/3.

An audit should therefore inspect the real delivery path: browser, CDN, reverse proxy, origin, negotiated protocol, and older clients.

A pragmatic Early Hints audit

Answer ten questions:

1. Is there enough server wait time for 103 to create a useful head start?
2. Which resource actually starts earlier?
3. Is it needed on almost every affected navigation?
4. Is it cacheable?
5. Do as, CORS, and credentials mode match?
6. Is anything downloaded twice?
7. Can hints reference old asset hashes after deployments?
8. Do hints contain information that should not be public before authentication?
9. Does the real delivery path work reliably across the HTTP versions you serve?
10. Does LCP or perceived loading improve—or only TTFB?

What Website-Pflichtencheck would inspect

Website-Pflichtencheck can assess 103 Early Hints as part of the full delivery chain:

• actual 103 and final responses,
• Link headers and preload targets,
• critical-resource prioritization,
• CORS and as consistency,
• cacheability and double fetches,
• stale asset hashes after deployments,
• CDN and reverse-proxy behavior,
• public versus authenticated routes,
• HTTP/2 and HTTP/3 delivery,
• TTFB versus final-response start,
• LCP and real resource waterfalls.

The goal is not to enable as many performance features as possible. The goal is for every optimization to demonstrably shorten a bottleneck without creating a new one.

103 Early Hints is useful when the server has to wait and the browser can spend that time productively. If the hint list is stale or overloaded, you are simply loading mistakes earlier.

Faster does not mean starting any request first. Faster means starting the right request early enough—and not needing to download it again later.