Intent to Prototype: 103 Early Hints for Navigation

103 views
Skip to first unread message

Kenichi Ishibashi

unread,
Feb 18, 2021, 6:23:41 PMFeb 18
to blink-dev, Kinuko Yasuda, Yutaka Hirano, b...@chromium.org, net...@chromium.org

Contact emails

ba...@chromium.org, kin...@chromium.org, yhi...@chromium.org, b...@chromium.org, net...@chromium.org


Specification

https://tools.ietf.org/html/rfc8297


Design docs


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


Summary

Support 103 Early Hints informational responses on navigation responses. When a 103 response includes <link rel=preload> or other link headers Chromium tries to preload (and/or preconnect, prefetch) specified resources even before the final response is received.  This gives Web developers a way to optimize Core Web Vitals such as Largest Contentful Paint (LCP).


A few months ago, we announced a collaborative experiment to measure the potential impact of 103 early hints. The results indicate that Early Hints could result in speed improvements on the order of a few hundred milliseconds (the sample size is a bit small though). Given these encouraging results, we are now moving forward with the next steps, starting with this intent to prototype.


Blink component

Internals>Preload


TAG review

N/A but will file one when we find it’s appropriate.


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Several servers/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 thanks to their frame format. Chromium only handles 103 responses over HTTP/2 and HTTP/3.



Gecko: No signal


WebKit: No signal


Web developers: Positive (https://www.fastly.com/blog/faster-websites-early-priority-hints). Positive interest and intent of support by popular CDNs. We've been collaborating with Fastly to do the preliminary measurement.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


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

No but we would add WPT as needed


Tracking bug

https://crbug.com/671310


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5207422375297024


This intent message was generated by Chrome Platform Status.


Mike West

unread,
Feb 23, 2021, 5:05:30 AMFeb 23
to blink-dev, Kenichi Ishibashi, Kinuko Yasuda, Yutaka Hirano, Bence Béky, net...@chromium.org
On Friday, February 19, 2021 at 12:23:41 AM UTC+1 Kenichi Ishibashi wrote:

On the design doc, Anne from Mozilla noted that the integration with Fetch and/or HTML's navigation algorithm are not contained in this RFC. Are there plans to flesh that integration out?

Design docs


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


Summary

Support 103 Early Hints informational responses on navigation responses. When a 103 response includes <link rel=preload> or other link headers Chromium tries to preload (and/or preconnect, prefetch) specified resources even before the final response is received.  This gives Web developers a way to optimize Core Web Vitals such as Largest Contentful Paint (LCP).


A few months ago, we announced a collaborative experiment to measure the potential impact of 103 early hints. The results indicate that Early Hints could result in speed improvements on the order of a few hundred milliseconds (the sample size is a bit small though). Given these encouraging results, we are now moving forward with the next steps, starting with this intent to prototype.


While the perf advantages do seem to primarily accrue to navigation requests, there are some security benefits which we might obtain by supporting this mechanism for subresource requests. For example, processing CORP headers and/or teaching CORB/ORB about early responses could mitigate some timing attacks on resource size and server-side generation. I'd be interested in seeing work in that direction as well.

Blink component

Internals>Preload


TAG review

N/A but will file one when we find it’s appropriate.


Given that this is already published as an RFC, it seems well past the time at which TAG review might initially have been helpful. Why wait? :)
Reply all
Reply to author
Forward
0 new messages