Intent to Prototype: 103 Early Hints for Navigation
Kenichi Ishibashi
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
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
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
Contact emails
ba...@chromium.org, kin...@chromium.org, yhi...@chromium.org, b...@chromium.org, net...@chromium.org
Specification
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.
Kenichi Ishibashi
On Friday, February 19, 2021 at 12:23:41 AM UTC+1 Kenichi Ishibashi wrote:Contact emails
ba...@chromium.org, kin...@chromium.org, yhi...@chromium.org, b...@chromium.org, net...@chromium.org
Specification
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
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? :)