Hi Yoav, On Thu, Apr 21, 2022 at 3:26 PM Yoav Weiss <[email protected]> wrote:
> > > On Thu, Apr 21, 2022 at 4:13 AM Kenichi Ishibashi <[email protected]> > wrote: > >> Contact emails >> >> [email protected], [email protected] >> >> 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 >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload> >> >> 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 >> <https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html#name-informational-1xx> >> 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 >> <https://github.com/whatwg/html/pull/7675>, whatwg/fetch#1404 >> <https://github.com/whatwg/fetch/pull/1404>). For preconnect there are >> ongoing efforts to specify the behavior. See “Anticipated spec changes” >> section below for more information. >> >> Gecko: In development >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1407355>. >> > > Can you ask for an official position? https://bit.ly/blink-signals > I should have put the link to the official position. They said it's worth prototyping <https://github.com/mozilla/standards-positions/issues/134> and IIUC it's under development. > >> >> WebKit: No signal >> <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html>. >> >> Web developers: Positive. Positive interest and intent of support by >> popular CDNs (Fastly >> <https://www.fastly.com/blog/faster-websites-early-priority-hints>, >> Cloudflare <https://blog.cloudflare.com/early-hints/>). 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 > <https://html.spec.whatwg.org/multipage/semantics.html#process-early-hint-headers>" > is only called from "process a navigate response > <https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents:process-early-hint-headers> > ". > Yes, you're right. Sorry for the confusion. Chromium has these restrictions to follow the specification. > > >> See this document >> <https://chromium.googlesource.com/chromium/src/+/master/docs/early-hints.md> >> 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 <https://fetch.spec.whatwg.org/#concept-request-mode> and >> credentials >> mode <https://fetch.spec.whatwg.org/#concept-request-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 >> <https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit#heading=h.fhq04xt0tah6> >> of the design doc for more information. >> > > Is that specified? > Yes. These behaviors are specified in "process a navigate fetch <https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-fetch>" and "process early hint headers <https://html.spec.whatwg.org/multipage/semantics.html#process-early-hint-headers> ". > >> >> >> 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 <https://www.chromium.org/for-testers/providing-network-details/>, >> WebPageTest, or network protocol analyzers such as Wireshark for debugging. >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >> ? >> >> Yes >> <https://github.com/web-platform-tests/wpt/tree/master/loading/early-hints> >> >> 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 >> <https://github.com/whatwg/html/issues/4224>). There are ongoing efforts >> to specify the behavior. For example whatwg/html#7814 >> <https://github.com/whatwg/html/pull/7814> specified the behavior of >> <link rel=preconnect>. whatwg/html#7835 >> <https://github.com/whatwg/html/pull/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 >> <https://chromestatus.com/>. >> >> -- >> 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 [email protected]. >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX-9MUr5cdGw_x7Gy6B3dxcmpVp9tnXL%2BY%3DDeEXoABNy3bA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX-8382k5MP5ejcG%2B0kqGMkNM0y4x9%3D1MDTeyG%2BLqdyf53g%40mail.gmail.com.
