I think the addition is reasonable, and it makes perfect sense to add it as part of the same Origin Trial. Is the addition a result of feedback from OT participants? If so, I think it makes sense to add that support without requiring much process.
On Fri, Aug 27, 2021 at 9:45 AM Kenichi Ishibashi <[email protected]> wrote: > Hi API owners, > > We would like to add preconnect [1] support in this experiment. The > purpose of preconnect is similar to preload but it's more lightweight: > preload tries to fetch resources, preconnect just tries to establish > connections. If this addition is reasonable, we will update relevant > documents and work on relevant spec works. > Updating the documentation seems critical, so thanks for doing that! > > [1] https://www.w3.org/TR/resource-hints/#preconnect > > > On Wed, Jul 28, 2021 at 10:29 AM Kenichi Ishibashi <[email protected]> > wrote: > >> Hi blink-dev, >> >> We now plan to run an origin trial for Early Hints preload. We realized >> that running an origin trial is useful for developers to try the feature. >> CL for integrating with the origin trial frame is under review. Experiment >> timeline unchanged (until M95). >> >> Thanks, >> >> On Thu, Jun 17, 2021 at 6:42 PM Yoav Weiss <[email protected]> >> wrote: >> >>> Still LGTM. I agree that being able to monitor support for a performance >>> optimization is a crucial part of the experiment. >>> >>> On Thu, Jun 17, 2021 at 11:01 AM Kenichi Ishibashi <[email protected]> >>> wrote: >>> >>>> Hi API owners, >>>> >>>> Regarding a PerformanceResourceTiming change for monitoring, we are >>>> going to add a new value "early-hints" for `initiatorType` [1]. >>>> >>>> We consider this web-exposing change is a crucial part of this intent >>>> to experiment. We would like to make the change as a part of this intent. I >>>> added a section for the change to the design doc [2]. The explainer for TAG >>>> review also mentions the change [3]. >>>> >>>> Please let us know if we need a separate intent for the change. >>>> >>>> [1] https://github.com/w3c/resource-timing/issues/273 >>>> [2] >>>> https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit#heading=h.vsk6lnrdp6xp >>>> [3] >>>> https://github.com/bashi/early-hints-explainer/blob/main/explainer.md#extension-to-the-performanceresourcetiming >>>> >>>> Thanks, >>>> >>>> On Fri, May 21, 2021 at 3:55 PM Yoav Weiss <[email protected]> >>>> wrote: >>>> >>>>> LGTM to experiment M91-M95 >>>>> >>>>> On Fri, May 21, 2021 at 1:15 AM Kenichi Ishibashi <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Yoav, sorry for the late reply. >>>>>> >>>>>> On Wed, May 19, 2021 at 6:38 PM Yoav Weiss <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks for experimenting with this! >>>>>>> >>>>>>> What's the plan in terms of monitoring? I know we discussed offline >>>>>>> the possibility of adding an Early Hints indication as part of >>>>>>> Resource Timing <https://github.com/w3c/resource-timing/issues/273>. >>>>>>> Is that planned to be part of that experiment? Or are you planning >>>>>>> to send a separate intent for that? >>>>>>> >>>>>> >>>>>> We likely propose adding a new attribute to PerformanceResourceTiming >>>>>> or adding a new value for `initiatorType`. I'm planning to send a >>>>>> separate >>>>>> intent as needed. >>>>>> >>>>> >>>>> That sounds great, thanks! :) >>>>> >>>>> >>>>>> >>>>>> >>>>>>> On Wed, May 19, 2021 at 3:31 AM Kenichi Ishibashi < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Mike, thank you for your questions! >>>>>>>> >>>>>>>> On Tue, May 18, 2021 at 6:31 PM Mike West <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Tue, May 18, 2021 at 10:45 AM Kenichi Ishibashi < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Contact emails >>>>>>>>>> >>>>>>>>>> [email protected], [email protected], [email protected] >>>>>>>>>> >>>>>>>>>> Specification >>>>>>>>>> >>>>>>>>>> https://tools.ietf.org/html/rfc8297 >>>>>>>>>> >>>>>>>>>> Link to “Intent to Prototype” blink-dev discussion >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/DAgWIczGtG0/m/gSXvjYn-AwAJ >>>>>>>>>> >>>>>>>>>> Summary >>>>>>>>>> >>>>>>>>>> When a 103 Early Hints response is received during navigation and >>>>>>>>>> it contains link rel=preload header fields Chrome tries to preload >>>>>>>>>> the >>>>>>>>>> specified resource before the final response is received. This is a >>>>>>>>>> finch >>>>>>>>>> experiment. Chrome triggers preload for the limited percentage of >>>>>>>>>> traffic. >>>>>>>>>> Currently we don’t plan to do an Origin Trial but we might set it up >>>>>>>>>> if we >>>>>>>>>> realize we need it. >>>>>>>>>> >>>>>>>>> >>>>>>>>> What percentage of traffic are you planning to experiment with? It >>>>>>>>> seems like the percentage is going to need to be quite large to gather >>>>>>>>> useful data, given that servers need to opt-in to sending early >>>>>>>>> hints, and >>>>>>>>> include a set of resources which might be useful. >>>>>>>>> >>>>>>>> >>>>>>>> Currently we plan to enable 50% on Canary, Dev and Beta, and 1% on >>>>>>>> Stable. We will revisit the percentage if the configuration doesn't >>>>>>>> provide >>>>>>>> enough numbers. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Do you have partners lined up for such an experiment? >>>>>>>>> >>>>>>>> >>>>>>>> Yes, we have partners who are interested in experimenting with the >>>>>>>> feature. We've been talking about the experiment details. When we have >>>>>>>> updates I'll post follow up emails to this thread. >>>>>>>> >>>>>>> >>>>>>> It might be worthwhile to verify with your partners that 1% of >>>>>>> stable traffic would be sufficient for them. >>>>>>> >>>>>> Yes, we talked about the percentages. I'll post an update when we >>>>>> decide to change the percentages. Currently we don't plan to change the >>>>>> percentages. >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Blink component >>>>>>>>>> >>>>>>>>>> Internals>Preload >>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload> >>>>>>>>>> >>>>>>>>>> Activation >>>>>>>>>> >>>>>>>>>> Servers send a 103 Early Hints informational response with link >>>>>>>>>> rel=preload header fields to ask Chrome to trigger subresource >>>>>>>>>> preloads >>>>>>>>>> before sending the final response. Chrome preloads subresources if >>>>>>>>>> the >>>>>>>>>> feature is activated by the experiment configuration. >>>>>>>>>> >>>>>>>>> >>>>>>>>> What's Chromium's current behavior if a 103 response is sent for a >>>>>>>>> subresource? >>>>>>>>> >>>>>>>> >>>>>>>> Chromium ignores a 103 response that is sent for a subresource. >>>>>>>> Details can be found in a crbug.com entry >>>>>>>> <https://crbug.com/1190699>. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> For testing purposes the feature can also be enabled by >>>>>>>>>> `--enable-features=EarlyHintsPreloadForNavigation` command line >>>>>>>>>> flag. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Is this wired up to the >>>>>>>>> `--enable-experimental-web-platform-features` flag as well? >>>>>>>>> >>>>>>>> >>>>>>>> No, but I think we can do that if that's preferable. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Goals for experimentation >>>>>>>>>> >>>>>>>>>> To see subresource preloading triggered by Early Hints can >>>>>>>>>> improve page rendering performance. >>>>>>>>>> >>>>>>>>>> Experimental timeline >>>>>>>>>> >>>>>>>>>> M91-M95 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ongoing technical constraints >>>>>>>>>> >>>>>>>>>> None >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> Please ask for signals via the mechanism described in >>>>>>>>> https://bit.ly/blink-signals. >>>>>>>>> >>>>>>>> >>>>>>>> Done: >>>>>>>> Gecko: https://github.com/mozilla/standards-positions/issues/530 >>>>>>>> WebKit: >>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I also note that the TAG design review section of this email is >>>>>>>>> missing. Can you link to your request? >>>>>>>>> >>>>>>>> >>>>>>>> Tag review: https://github.com/w3ctag/design-reviews/issues/638 >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Web developers: Positive >>>>>>>>>> >>>>>>>>>> Positive interest and intent of support by popular CDNs (e.g. >>>>>>>>>> https://www.fastly.com/blog/faster-websites-early-priority-hints >>>>>>>>>> ). >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> No. We plan to figure out what kind of web-platform-tests we >>>>>>>>>> should have once the spec issue >>>>>>>>>> <https://github.com/whatwg/fetch/issues/1225> is resolved. We >>>>>>>>>> already have browser_tests and unittests. >>>>>>>>>> >>>>>>>>>> Flag name >>>>>>>>>> >>>>>>>>>> EarlyHintsPreloadForNavigation >>>>>>>>>> >>>>>>>>>> Tracking bug >>>>>>>>>> >>>>>>>>>> https://crbug.com/671310 >>>>>>>>>> >>>>>>>>>> Launch bug >>>>>>>>>> >>>>>>>>>> https://crbug.com/1197989 >>>>>>>>>> >>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>> >>>>>>>>>> https://chromestatus.com/feature/5207422375297024 >>>>>>>>>> >>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>> <https://www.chromestatus.com/>. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "net-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/net-dev/CAPLXX-_4%2B_yP44kZrJyOcc48CZqLTRQsupyqtooq%3D1u4PWWFbQ%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPLXX-_4%2B_yP44kZrJyOcc48CZqLTRQsupyqtooq%3D1u4PWWFbQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "net-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/net-dev/CAPLXX--Axo8G20pFp%3DqJZW1agAuK_mZEoGvnG%3Dz_Y3-JWPkY-g%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPLXX--Axo8G20pFp%3DqJZW1agAuK_mZEoGvnG%3Dz_Y3-JWPkY-g%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/CAL5BFfX%2BSAcASX-wECwbStii1GkC9hbBNKT3xkiX47mF_CwHBg%40mail.gmail.com.
