Hi Yoav, On Fri, Aug 27, 2021 at 5:25 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
> 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. > Yes, we got feedback from our partners that preconnect will be beneficial to them. > > On Fri, Aug 27, 2021 at 9:45 AM Kenichi Ishibashi <ba...@chromium.org> > 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 <ba...@chromium.org> >> 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 <yoavwe...@chromium.org> >>> 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 <ba...@chromium.org> >>>> 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 <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>>> LGTM to experiment M91-M95 >>>>>> >>>>>> On Fri, May 21, 2021 at 1:15 AM Kenichi Ishibashi <ba...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Hi Yoav, sorry for the late reply. >>>>>>> >>>>>>> On Wed, May 19, 2021 at 6:38 PM Yoav Weiss <yoavwe...@chromium.org> >>>>>>> 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 < >>>>>>>> ba...@chromium.org> wrote: >>>>>>>> >>>>>>>>> Hi Mike, thank you for your questions! >>>>>>>>> >>>>>>>>> On Tue, May 18, 2021 at 6:31 PM Mike West <mk...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Tue, May 18, 2021 at 10:45 AM Kenichi Ishibashi < >>>>>>>>>> ba...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emails >>>>>>>>>>> >>>>>>>>>>> ba...@chromium.org, kin...@chromium.org, yhir...@chromium.org >>>>>>>>>>> >>>>>>>>>>> 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 net-dev+unsubscr...@chromium.org. >>>>>>>>>>> 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 net-dev+unsubscr...@chromium.org. >>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX-9Wi7h%3Dymb2%2BAiF%3Dw-prU5d%3DS22907YXMFxNSd%2B9j8B7A%40mail.gmail.com.
