Jeremy, When do you hope to ship this?
Joe Joe Medley | Technical Writer, Chrome DevRel | [email protected] | 816-678-7195 *If an API's not documented it doesn't exist.* On Fri, Jan 28, 2022 at 11:51 AM Jeremy Roman <[email protected]> wrote: > On Fri, Jan 28, 2022 at 4:33 AM Yoav Weiss <[email protected]> wrote: > >> LGTM to continue experimentation. Note that this would bring the OT to 11 >> milestones, which is approaching the limits of OT timelines. >> >> On Wed, Jan 26, 2022 at 9:57 PM Jeremy Roman <[email protected]> >> wrote: >> >>> On Wed, Jan 26, 2022 at 10:18 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> Any current feedback from the OT up until now? >>>> >>> >>> Feedback on the speculation rules API itself has been relatively >>> limited. We had one issue where server postprocessing incorrectly >>> interpreted a <script> with a non-JavaScript type. >>> >>> Related to prefetch, we're aware of issues relating to how prefetch >>> requests, especially anonymized prefetch requests (which emerge from a >>> Google IP not necessarily in the exact same location and thus might affect >>> GeoIP-dependent responses), can be easily identified by server software >>> (and are working on updating the spec and implementation to send a clearer >>> signal in the request headers) and how best for servers to indicate that a >>> prefetch cannot be used without adverse side effects. >>> >>> On Monday, January 24, 2022 at 4:58:16 PM UTC+1 Jeremy Roman wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected] >>>>> >>>>> Explainer >>>>> >>>>> https://github.com/WICG/nav-speculation/blob/main/triggers.md >>>>> >>>>> Specification >>>>> >>>>> https://wicg.github.io/nav-speculation/speculation-rules.html >>>>> >>>>> https://wicg.github.io/nav-speculation/prefetch.html >>>>> >>>>> Summary >>>>> >>>>> Speculation Rules is a flexible syntax for defining what outgoing >>>>> links are eligible to be prepared speculatively before navigation. It >>>>> enables access to additional enhancements, such as use of a private >>>>> prefetch proxy, where applicable. >>>>> >>>>> Participants in this trial can use this syntax to request prefetching >>>>> of links they expect the user is likely to visit next. >>>>> >>>>> This is a request to extend the previous experiment >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Cw-hOjT47qI/m/EObn9-4MAgAJ>. >>>>> We would like to extend the experiment for milestones M98 to M101 >>>>> (inclusive), in order to continue to gather data as a partner makes >>>>> improvements to their integration and to shave some of the rough edges off >>>>> the feature. There is an ongoing early access program >>>>> <https://github.com/buettner/private-prefetch-proxy/issues/15#issuecomment-952207477> >>>>> to allow more publishers to receive IP anonymized traffic as we refine >>>>> this. >>>>> >>>>> We now support "prefetch" rules and intend to deprecate >>>>> "prefetch_with_subresources" (at least for now) during this extension. >>>>> Cross-origin uncredentialed prefetch without IP anonymization is now >>>>> supported. >>>>> >>>> >>>> That's a new addition of this extension, right? >>>> >>> >>> Yes, these are new since the previous extension. >>> >>> >>>> Users can now enable access to IP anonymization from any origin through >>>>> a Chrome setting. >>>>> >>>> >>>> Is this setting applicable to all sites? Just prefetched ones? >>>> >>> >>> This change landed recently. If the user enables extended preloading in >>> Google Chrome, then any site can request prefetches which require IP >>> anonymization. If only standard preloading is enabled, then any site can >>> still be prefetched anonymously (subject to the other conditions on that), >>> but only some sites can request it. >>> >> >> Any documentation on that? >> > > The support pages don't elaborate on this point, but the strings in the > Clank settings do. > > They're defined here > <https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/ui/android/strings/android_chrome_strings.grd;l=348-389;drc=d18700ce0dc7050e430e65ffdad1ade446fe190e>. > The short version reads: > > *Standard preloading* > Some of the pages you visit are preloaded. Pages may be preloaded through > Google servers when linked from a Google site. > > *Extended preloading* > More pages are preloaded. Pages may be preloaded through Google servers > when requested by other sites. > > >> Internal analysis from the current experiment with significant >>>>> improvement to the largest contentful paint time when successful. Though >>>>> prefetching with subresources (NoStatePrefetch) provides some additional >>>>> improvement, it incurs over a much higher byte cost on average. We believe >>>>> that in most cases prefetching more possible outgoing navigation is >>>>> typically a better tradeoff than also prefetching subresources, so we are >>>>> focusing on shipping prefetch of the main resource. Many outbound >>>>> navigations are currently ineligible due to cookies existing on the >>>>> destination site, which motivates future improvements to allow sites to >>>>> participate in uncredentialed prefetch through an additional opt-in. (I've >>>>> requested clearance to release approximate numbers, but that hasn't been >>>>> approved at this point.) >>>>> >>>> > I've received clearance to unredact this, so here are some slightly more > specific numbers: > > Internal analysis from the current experiment with Google Search shows > approximately 400 ms of improvement to the largest contentful paint time > when successful. Though prefetching with subresources (NoStatePrefetch) > provides some additional improvement, it incurs over 3x the byte cost on > average. We believe that in most cases prefetching more possible outgoing > navigation is typically a better tradeoff than also prefetching > subresources, so we are focusing on shipping prefetch of the main resource. > Over half of the outbound navigations are currently ineligible due to > cookies existing on the destination site, which motivates future > improvements to allow sites to participate in uncredentialed prefetch > through an additional opt-in. > > 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/611 >>>>> >>>>> TAG review status >>>>> >>>>> Complete (recommended followup review TBA) >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> Gecko: No signal >>>>> >>>>> WebKit: No signal >>>>> >>>>> Web developers: Past success with <link rel=prefetch> >>>>> <https://web.dev/link-prefetch/> and libraries like QuickLink, and >>>>> discussion with some partners suggests interest in this space. >>>>> >>>>> >>>>> Goals for experimentation >>>>> >>>>> To gather feedback about the convenience of the Speculation Rules >>>>> syntax, and to gather data about performance improvements for navigations >>>>> that are prefetched, directly and via a private prefetch proxy (subject to >>>>> the limitations mentioned above). >>>>> >>>>> Ongoing technical constraints >>>>> >>>>> No significant technical constraints anticipated. >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>> >>>>> Chrome for Android (non-WebView) only, at present. >>>>> >>>>> Eventually other platforms will be supported. >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> Not yet, but we have plans to >>>>> <https://github.com/jeremyroman/alternate-loading-modes/blob/main/speculation-rules-testing.md> >>>>> . >>>>> >>>>> Flag name >>>>> >>>>> The origin trial feature name will continue to be >>>>> SpeculationRulesPrefetch. >>>>> >>>>> Tracking bug >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1173646 >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5740655424831488 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> Intent to prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/1q7Fp3zpjgQ >>>>> >>>>> Intent to experiment: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/Cw-hOjT47qI/m/CY7qVZP5AQAJ >>>>> >>>>> Intent to continue experimenting: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/T3nKEipKv-4/m/rKJ0uFR3BAAJ >>>>> >>>>> -- > 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/CACuR13fkTqkoXks8SdP32aafchEZTOf_oFG_71iim%2BaO84_BFg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13fkTqkoXks8SdP32aafchEZTOf_oFG_71iim%2BaO84_BFg%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/CAJUhtG-guySDUUO%3DyqLx5bU%2B5XZP5PRGjA%2BddM%2BcMSzOb8byoA%40mail.gmail.com.
