Intent to Ship: Early Hints preload/preconnect during Navigation

Kenichi Ishibashi

unread,

Apr 20, 2022, 10:13:13 PM4/20/22

to blink-dev, deno...@chromium.org

Summary

Support 103 Early Hints informational responses during top-level frame navigation. When a 103 response includes link headers Chromium tries to preload specified resources (including modulepreload) or preconnect to specified origins before the final response is received. This gives Web developers a way to optimize Core Web Vitals such as Largest Contentful Paint (LCP).

Blink component

Internals>Preload

TAG review

https://github.com/w3ctag/design-reviews/issues/638

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Browsers may not understand a 103 response but they are expected to ignore 1xx responses if they don’t understand 1xx responses. Firefox is implementing 103 support.

Proxies may not understand a 103 response. They may treat the 103 response as a part of the final response when the response is sent over HTTP/1.1. The problem is less likely to happen over HTTP/2 and HTTP/3 thanks to their frame format. Chromium only handles 103 responses over HTTP/2 and HTTP/3.

The HTML and Fetch standards have been updated to handle preload link headers in 103 responses for navigations (whatwg/html#7675, whatwg/fetch#1404). For preconnect there are ongoing efforts to specify the behavior. See “Anticipated spec changes” section below for more information.

Gecko: In development.

WebKit: No signal.

Web developers: Positive. Positive interest and intent of support by popular CDNs (Fastly, Cloudflare). We've been collaborating with partners to evaluate the impact of Early Hints and we observed significant improvements on page loading metrics such as FCP.

Ergonomics

The primary usage of this feature is to send link headers to preload resources or preconnect to servers to improve page load performance. Due to potential security concerns Chromium only handles the first 103 response for the top-frame navigation. See this document for details of restrictions. These restrictions may be relaxed in the future.

Activation

Popular HTTP servers and CDNs provide configurations or options to send Early Hints responses.

Security

Request mode and credentials mode are calculated the same as normal preload and preconnect. Preloads triggered by a 103 response follow policies specified in the same 103 response. Chromium only handles the first 103 response and ignores following 103 responses to avoid contradiction policies between these responses and the final response. Chromium doesn’t use preloaded resources triggered by a 103 response when there are conflicting policies between a 103 response and the final response. See the security considerations section of the design doc for more information.

WebView application risks

We don’t expect WebView specific problems with this feature.

Debuggability

If a resource is preloaded by Early Hints, the corresponding PerformanceResourceTiming object reports that its initiatorType is "early-hints".

When the document doesn’t use resources preloaded by Early Hints within a few seconds from the window’s load event Chromium will show warning messages (this is under review now).

DevTools lack Early Hints support and we consider adding Early Hints support in DevTools in the future. In the meanwhile developers can use NetLog, WebPageTest, or network protocol analyzers such as Wireshark for debugging.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

EarlyHintsPreloadForNavigation

Requires code in //chrome?

False

Tracking bug

https://crbug.com/671310

Launch bug

https://crbug.com/1197989

Sample links

https://early-hints.fastlylabs.com/

Estimated milestones

We would like to ship this feature in M103.

Anticipated spec changes

Historically preconnect hasn’t been specified well (whatwg/html#4224). There are ongoing efforts to specify the behavior. For example whatwg/html#7814 specified the behavior of <link rel=preconnect>. whatwg/html#7835 will specify preconnect in link headers and it will cover 103 responses.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5207422375297024

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/xb_NHDS3twY

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,

Apr 21, 2022, 2:26:30 AM4/21/22

to Kenichi Ishibashi, blink-dev, deno...@chromium.org

On Thu, Apr 21, 2022 at 4:13 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Contact emails
ba...@chromium.org, deno...@chromium.org

Explainer
https://github.com/bashi/early-hints-explainer/blob/main/explainer.md

Specification
https://tools.ietf.org/html/rfc8297
https://html.spec.whatwg.org/#early-hints

Design docs
https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit?usp=sharing

Summary
Support 103 Early Hints informational responses during top-level frame navigation. When a 103 response includes link headers Chromium tries to preload specified resources (including modulepreload) or preconnect to specified origins before the final response is received. This gives Web developers a way to optimize Core Web Vitals such as Largest Contentful Paint (LCP).

Blink component
Internals>Preload

TAG review
https://github.com/w3ctag/design-reviews/issues/638

TAG review status
Issues addressed

Risks

Interoperability and Compatibility
Browsers may not understand a 103 response but they are expected to ignore 1xx responses if they don’t understand 1xx responses. Firefox is implementing 103 support.

Proxies may not understand a 103 response. They may treat the 103 response as a part of the final response when the response is sent over HTTP/1.1. The problem is less likely to happen over HTTP/2 and HTTP/3 thanks to their frame format. Chromium only handles 103 responses over HTTP/2 and HTTP/3.

The HTML and Fetch standards have been updated to handle preload link headers in 103 responses for navigations (whatwg/html#7675, whatwg/fetch#1404). For preconnect there are ongoing efforts to specify the behavior. See “Anticipated spec changes” section below for more information.

Gecko: In development.

Can you ask for an official position? https://bit.ly/blink-signals

WebKit: No signal.

Web developers: Positive. Positive interest and intent of support by popular CDNs (Fastly, Cloudflare). We've been collaborating with partners to evaluate the impact of Early Hints and we observed significant improvements on page loading metrics such as FCP.

Ergonomics
The primary usage of this feature is to send link headers to preload resources or preconnect to servers to improve page load performance. Due to potential security concerns Chromium only handles the first 103 response for the top-frame navigation.

That restriction is specified, right? AFAICT, "process early hints headers" is only called from "process a navigate response".

See this document for details of restrictions. These restrictions may be relaxed in the future.

Activation
Popular HTTP servers and CDNs provide configurations or options to send Early Hints responses.

Security
Request mode and credentials mode are calculated the same as normal preload and preconnect. Preloads triggered by a 103 response follow policies specified in the same 103 response. Chromium only handles the first 103 response and ignores following 103 responses to avoid contradiction policies between these responses and the final response. Chromium doesn’t use preloaded resources triggered by a 103 response when there are conflicting policies between a 103 response and the final response. See the security considerations section of the design doc for more information.

Is that specified?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX-9MUr5cdGw_x7Gy6B3dxcmpVp9tnXL%2BY%3DDeEXoABNy3bA%40mail.gmail.com.

Kenichi Ishibashi

unread,

Apr 21, 2022, 4:23:48 AM4/21/22

to Yoav Weiss, blink-dev, deno...@chromium.org

Hi Yoav,

I should have put the link to the official position. They said it's worth prototyping and IIUC it's under development.

WebKit: No signal.

Web developers: Positive. Positive interest and intent of support by popular CDNs (Fastly, Cloudflare). We've been collaborating with partners to evaluate the impact of Early Hints and we observed significant improvements on page loading metrics such as FCP.

Ergonomics
The primary usage of this feature is to send link headers to preload resources or preconnect to servers to improve page load performance. Due to potential security concerns Chromium only handles the first 103 response for the top-frame navigation.

That restriction is specified, right? AFAICT, "process early hints headers" is only called from "process a navigate response".

Yes, you're right. Sorry for the confusion. Chromium has these restrictions to follow the specification.

See this document for details of restrictions. These restrictions may be relaxed in the future.

Activation
Popular HTTP servers and CDNs provide configurations or options to send Early Hints responses.

Security
Request mode and credentials mode are calculated the same as normal preload and preconnect. Preloads triggered by a 103 response follow policies specified in the same 103 response. Chromium only handles the first 103 response and ignores following 103 responses to avoid contradiction policies between these responses and the final response. Chromium doesn’t use preloaded resources triggered by a 103 response when there are conflicting policies between a 103 response and the final response. See the security considerations section of the design doc for more information.

Is that specified?

Yes. These behaviors are specified in "process a navigate fetch" and "process early hint headers".

Daisuke Enomoto

unread,

Apr 27, 2022, 1:49:10 AM4/27/22

to Kenichi Ishibashi, blink-dev, Yoav Weiss

Hi

Any other questions or concerns?

Thanks!

Yoav Weiss

unread,

Apr 27, 2022, 2:34:07 AM4/27/22

to Daisuke Enomoto, Kenichi Ishibashi, blink-dev

LGTM1

I'm excited about this work as it unlocks many potential wins in terms of loading performance. Interest from Mozilla as well as support from leading CDNs is also promising in terms of activation and usage. Thanks for working on this!!

Great to see those PRs have landed!

Mike Taylor

unread,

Apr 27, 2022, 9:11:07 AM4/27/22

to Yoav Weiss, Daisuke Enomoto, Kenichi Ishibashi, blink-dev

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU3vO5hb3CXXt4mG6HCWPOF7tjCoqvrjOdbW2Q49uiSbw%40mail.gmail.com.

mkwst via Chromestatus

unread,

Apr 27, 2022, 10:56:43 AM4/27/22

to blin...@chromium.org

LGTM3.

Chris Harrelson

unread,

Apr 27, 2022, 10:58:46 AM4/27/22

to Mike Taylor, Yoav Weiss, Daisuke Enomoto, Kenichi Ishibashi, blink-dev

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d74545b-dde0-49ce-197d-25ae8dfd4ec2%40chromium.org.

jmedley via Chromestatus

unread,

Apr 27, 2022, 2:14:47 PM4/27/22

to blin...@chromium.org

Last I heard, you all wanted to ship in 103. Can you please put the correct number in the status entry?

Kenichi Ishibashi

unread,

Apr 27, 2022, 7:17:19 PM4/27/22

to jmedley via Chromestatus, blin...@chromium.org

Yes we would like to ship in 103. Updated the status entry.

On Thu, Apr 28, 2022 at 3:14 AM jmedley via Chromestatus <admin+...@cr-status.appspotmail.com> wrote:

Last I heard, you all wanted to ship in 103. Can you please put the correct number in the status entry?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0000000000008f7e8905dda6c856%40google.com.

Reply all

Reply to author

Forward