103 Early Hints preload (and its Resource Timing entries)

Description

A server can send a 103 Early Hints response before the final response. The browser reads the Link headers in the 103 and starts preconnect and preload work while the server is still generating the HTML. This proposal covers how browsers act on those headers during a top-level navigation and what they report about that work through Resource Timing.

The proposal includes:

• preload and preconnect links in 103 responses, with their as, crossorigin, fetchpriority and integrity attributes, referrer policy, redirects, and how CSP and COEP on the final response affect them
• the document's reuse of the preloaded response
• the shape and quantity of PerformanceResourceTiming entries these preloads produce, both initiatorType and the timing fields (startTime, fetchStart, requestStart, responseStart, responseEnd), see: https://github.com/w3c/resource-timing/issues/435

The proposal leaves out interim responses in the Fetch API (whatwg/fetch#1716) and Early Hints on subresource or iframe requests.

Specification

https://html.spec.whatwg.org/multipage/semantics.html#early-hints

web-feature

No response

Test Links

https://wpt.fyi/results/loading/early-hints?label=master&label=experimental&aligned

No test today checks the timing fields of an early-hints entry, and no test checks what entry the consumption produces. preload-initiator-type.h2.window.js checks initiatorType only.

Additional Signals

Current state

Chromium has shipped Early Hints preload since version 103 (2022) and Firefox since 123 (2024). Safari has honoured preconnect since 17 but ignores preload. WebKit/WebKit#70207, open since July 2026, implement preload, but remains open.

Cloudflare, Fastly, Akamai, Vercel and Shopify all emit 103 responses today. Shopify sends preconnect and preload links in 103 responses on storefront navigations for all of its merchants' shops. The feature has real traffic and real behaviour differences between engines.

Impact

Shopify's write-up of its Early Hints rollout (https://performance.shopify.com/blogs/blog/faster-shopify-storefronts-with-automatic-early-hints) documents both the value of the feature and the problems with rolling it out confidently. On pageviews where the browser received and used the 103 preloads, FCP improved by 76, and LCP by 100ms at p75. Buyers on Safari saw smaller gains, because Safari ignores the preload links.

Resource Timing could not tell us which preloads happened or whether the page reused them. To measure the new rollout we joined Chrome's Speculative Load Measurement origin trial. It reports which resources were preloaded, whether each came from a 103, and whether the page used it. That data exists in one engine, behind an origin trial. A Resource Timing entry with correct timings would answer the same questions in every browser (except for the actual usage).

Start with preload-initiator-type.h2.window.js and the existing loading/early-hints tests, then compare their coverage with the proposal and the Resource Timing issue. Add coverage for the timing fields of an early-hints entry and for the entry produced when the document consumes the preload, verifying the expected initiator type and entry shape across the relevant cases.