On Fri, Jan 28, 2022 at 4:33 AM Yoav Weiss <yoavwe...@chromium.org> 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 <jbro...@chromium.org> wrote:
>
>> On Wed, Jan 26, 2022 at 10:18 AM Yoav Weiss <yoavwe...@chromium.org>
>> 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
>>>>
>>>> jbro...@chromium.org, kenjibah...@chromium.org
>>>>
>>>> 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 blink-dev+unsubscr...@chromium.org.
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.

Reply via email to