Intent to Ship: Early Hints preload/preconnect during Navigation

266 views
Skip to first unread message

Kenichi Ishibashi

unread,
Apr 20, 2022, 10:13:13 PM4/20/22
to blink-dev, deno...@chromium.org

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.


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

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

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.
Reply all
Reply to author
Forward
0 new messages