Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Yoav Weiss]

SG! My LGTM still stands :)

On Tue, Sep 6, 2022 at 3:52 PM Dave Tapuska  wrote:

> BFCache has different behavior. Pages are evicted if an extension tries to
> communicate with something that is in the cache. We did outreach to help
> increase BFCache rates because we know what extensions cause eviction.
>
> In terms of prerender it is different because extensions can modify/block
> content on the page and you really need to do this during the prerender
> phase to really do what an extension wants. It is difficult to quantify
> which extensions could be broken, but we did do some testing of popular
> extensions and discovered no problems. We have finch and enterprise policy
> fail safes in place if we do run into something in the wild that is causing
> significant issues.
>
> dave.
>
> On Mon, Sep 5, 2022 at 5:33 AM Yoav Weiss  wrote:
>
>> Thanks!! Were extensions affected by previous multi-page arch shipped
>> features, such as BFCache?
>> Is there a way for us to scan the various extension stores, look for
>> patterns that would be affected by this change and notify the extension's
>> authors ahead of time?
>>
>> On Thu, Sep 1, 2022 at 4:23 PM Dave Tapuska 
>> wrote:
>>
>>> I drafted a blog post highlighting the additions/changes to the
>>> extension APIs. It is just going through reviews before being posted to
>>> developer.chrome.com, hopefully sometime next week.
>>>
>>> dave.
>>>
>>> On Thu, Sep 1, 2022 at 2:49 AM Yoav Weiss 
>>> wrote:
>>>


 On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
 wrote:

> Thank you for the feedback.
>
> Yes, the Extensions is the thing we have paid the biggest attention to
> support Prerendering on Desktop.
>
> https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
> This is the document we discussed especially on Prerendering and
> Extensions. In the design discussion we tried finding the best choice to
> minimize possible compatibility breakage for most Extensions, but at the
> same time, we understood it's unavoidable that some Extensions may be
> surprised to see unexpected prerendering pages.
>
> So, our prepared mitigations are
> - Enterprise Policy to disable Prerendering completely
> - Users' report based incompatible Chrome Extensions list that
> disables Prerendering when a user installs one in the list.
>

 That sounds reasonable, but I wonder if more communication to the
 extensions community is warranted.

 +Simeon Vincent  for thoughts


>
> It minimizes the risk to block the rollout for such unexpected
> Extensions compatibility breakages.
>
> For more visibility, here is the crbug entry to report such
> incompatible Extensions quickly.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1351312
>
> 
> T 
> hanks!
>
> On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell 
> wrote:
>
>> In addition to the LGTM, I want to point out that during our
>> discussion among the API Owners, we did specifically wonder about 
>> extension
>> compatibility. Since this will change things for extensions, I think it
>> will be important to look for compatibility problems popping up, and, if
>> necessary, delay until any such problems are fully understood.
>>
>> /Daniel
>> On 2022-08-31 16:34, Daniel Bratell wrote:
>>
>> LGTM3
>>
>> /Daniel
>> On 2022-08-30 10:58, Yoav Weiss wrote:
>>
>> LGTM2 to expand support for desktop.
>>
>> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent 
>> wrote:
>>
>>> LGTM1.
>>> It's pretty safe to expand support to desktop platforms, and it
>>> seems there are no negative signals.
>>>
>>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 toyos...@chromium.org, angelrapo...@google.com

 Explainer

 This I2S aims to expand our efforts on Prerender2 (currently
 shipped only on Android) to Desktop.

 The full prerendering revamped explainer can be found at

 https://github.com/WICG/nav-speculation/blob/main/README.md

 Specification

 https://wicg.github.io/nav-speculation/prerendering.html

 Design docs


 https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs

 Summary

 Prerendering is “pre”-rendering, it’s about pre-loading and
 rendering a Web page before the user actually navigates to it. The main
 goal of prerendering is to make the next page navigation faster, or 
 ideally
 nearly 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Dave Tapuska]

BFCache has different behavior. Pages are evicted if an extension tries to
communicate with something that is in the cache. We did outreach to help
increase BFCache rates because we know what extensions cause eviction.

In terms of prerender it is different because extensions can modify/block
content on the page and you really need to do this during the prerender
phase to really do what an extension wants. It is difficult to quantify
which extensions could be broken, but we did do some testing of popular
extensions and discovered no problems. We have finch and enterprise policy
fail safes in place if we do run into something in the wild that is causing
significant issues.

dave.

On Mon, Sep 5, 2022 at 5:33 AM Yoav Weiss  wrote:

> Thanks!! Were extensions affected by previous multi-page arch shipped
> features, such as BFCache?
> Is there a way for us to scan the various extension stores, look for
> patterns that would be affected by this change and notify the extension's
> authors ahead of time?
>
> On Thu, Sep 1, 2022 at 4:23 PM Dave Tapuska  wrote:
>
>> I drafted a blog post highlighting the additions/changes to the extension
>> APIs. It is just going through reviews before being posted to
>> developer.chrome.com, hopefully sometime next week.
>>
>> dave.
>>
>> On Thu, Sep 1, 2022 at 2:49 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
>>> wrote:
>>>
 Thank you for the feedback.

 Yes, the Extensions is the thing we have paid the biggest attention to
 support Prerendering on Desktop.

 https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
 This is the document we discussed especially on Prerendering and
 Extensions. In the design discussion we tried finding the best choice to
 minimize possible compatibility breakage for most Extensions, but at the
 same time, we understood it's unavoidable that some Extensions may be
 surprised to see unexpected prerendering pages.

 So, our prepared mitigations are
 - Enterprise Policy to disable Prerendering completely
 - Users' report based incompatible Chrome Extensions list that disables
 Prerendering when a user installs one in the list.

>>>
>>> That sounds reasonable, but I wonder if more communication to the
>>> extensions community is warranted.
>>>
>>> +Simeon Vincent  for thoughts
>>>
>>>

 It minimizes the risk to block the rollout for such unexpected
 Extensions compatibility breakages.

 For more visibility, here is the crbug entry to report such
 incompatible Extensions quickly.
 https://bugs.chromium.org/p/chromium/issues/detail?id=1351312

 
 T hanks!

 On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell 
 wrote:

> In addition to the LGTM, I want to point out that during our
> discussion among the API Owners, we did specifically wonder about 
> extension
> compatibility. Since this will change things for extensions, I think it
> will be important to look for compatibility problems popping up, and, if
> necessary, delay until any such problems are fully understood.
>
> /Daniel
> On 2022-08-31 16:34, Daniel Bratell wrote:
>
> LGTM3
>
> /Daniel
> On 2022-08-30 10:58, Yoav Weiss wrote:
>
> LGTM2 to expand support for desktop.
>
> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent 
> wrote:
>
>> LGTM1.
>> It's pretty safe to expand support to desktop platforms, and it
>> seems there are no negative signals.
>>
>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> toyos...@chromium.org, angelrapo...@google.com
>>>
>>> Explainer
>>>
>>> This I2S aims to expand our efforts on Prerender2 (currently shipped
>>> only on Android) to Desktop.
>>>
>>> The full prerendering revamped explainer can be found at
>>>
>>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>>
>>> Specification
>>>
>>> https://wicg.github.io/nav-speculation/prerendering.html
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>>
>>> Summary
>>>
>>> Prerendering is “pre”-rendering, it’s about pre-loading and
>>> rendering a Web page before the user actually navigates to it. The main
>>> goal of prerendering is to make the next page navigation faster, or 
>>> ideally
>>> nearly instant.
>>>
>>> Sites can inform the user agent about which pages the user may
>>> likely visit, by asking to trigger a ‘prerendering’ for a particular URL
>>> (e.g. user is at page A and will likely navigate to page B 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Yoav Weiss]

Thanks!! Were extensions affected by previous multi-page arch shipped
features, such as BFCache?
Is there a way for us to scan the various extension stores, look for
patterns that would be affected by this change and notify the extension's
authors ahead of time?

On Thu, Sep 1, 2022 at 4:23 PM Dave Tapuska  wrote:

> I drafted a blog post highlighting the additions/changes to the extension
> APIs. It is just going through reviews before being posted to
> developer.chrome.com, hopefully sometime next week.
>
> dave.
>
> On Thu, Sep 1, 2022 at 2:49 AM Yoav Weiss  wrote:
>
>>
>>
>> On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
>> wrote:
>>
>>> Thank you for the feedback.
>>>
>>> Yes, the Extensions is the thing we have paid the biggest attention to
>>> support Prerendering on Desktop.
>>>
>>> https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
>>> This is the document we discussed especially on Prerendering and
>>> Extensions. In the design discussion we tried finding the best choice to
>>> minimize possible compatibility breakage for most Extensions, but at the
>>> same time, we understood it's unavoidable that some Extensions may be
>>> surprised to see unexpected prerendering pages.
>>>
>>> So, our prepared mitigations are
>>> - Enterprise Policy to disable Prerendering completely
>>> - Users' report based incompatible Chrome Extensions list that disables
>>> Prerendering when a user installs one in the list.
>>>
>>
>> That sounds reasonable, but I wonder if more communication to the
>> extensions community is warranted.
>>
>> +Simeon Vincent  for thoughts
>>
>>
>>>
>>> It minimizes the risk to block the rollout for such unexpected
>>> Extensions compatibility breakages.
>>>
>>> For more visibility, here is the crbug entry to report such incompatible
>>> Extensions quickly.
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1351312
>>>
>>> 
>>> T hanks!
>>>
>>> On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell 
>>> wrote:
>>>
 In addition to the LGTM, I want to point out that during our discussion
 among the API Owners, we did specifically wonder about extension
 compatibility. Since this will change things for extensions, I think it
 will be important to look for compatibility problems popping up, and, if
 necessary, delay until any such problems are fully understood.

 /Daniel
 On 2022-08-31 16:34, Daniel Bratell wrote:

 LGTM3

 /Daniel
 On 2022-08-30 10:58, Yoav Weiss wrote:

 LGTM2 to expand support for desktop.

 On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent 
 wrote:

> LGTM1.
> It's pretty safe to expand support to desktop platforms, and it
> seems there are no negative signals.
>
> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> toyos...@chromium.org, angelrapo...@google.com
>>
>> Explainer
>>
>> This I2S aims to expand our efforts on Prerender2 (currently shipped
>> only on Android) to Desktop.
>>
>> The full prerendering revamped explainer can be found at
>>
>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>
>> Specification
>>
>> https://wicg.github.io/nav-speculation/prerendering.html
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>
>> Summary
>>
>> Prerendering is “pre”-rendering, it’s about pre-loading and rendering
>> a Web page before the user actually navigates to it. The main goal of
>> prerendering is to make the next page navigation faster, or ideally 
>> nearly
>> instant.
>>
>> Sites can inform the user agent about which pages the user may likely
>> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
>> user is at page A and will likely navigate to page B next). Once the
>> prerender is triggered, the browser pre-fetches the main resource,
>> instantiates a hidden page, and processes the main resource to fetch and
>> process more subresources.
>>
>> After shipping Prerender2 for Android (I2S speculation rules
>> triggered Prerender2
>> 
>> and I2S for Omnibox triggered Prerender2
>> ),
>> we are now requesting approval to ship Prerender2 for Desktop. This 
>> release
>> will enable the same triggers (speculation rules and Omnibox) for 
>> Desktop.
>>
>> With this feature, Chrome (Desktop) will start prerendering
>> high-confidence URL suggestions provided 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Dave Tapuska]

I drafted a blog post highlighting the additions/changes to the extension
APIs. It is just going through reviews before being posted to
developer.chrome.com, hopefully sometime next week.

dave.

On Thu, Sep 1, 2022 at 2:49 AM Yoav Weiss  wrote:

>
>
> On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
> wrote:
>
>> Thank you for the feedback.
>>
>> Yes, the Extensions is the thing we have paid the biggest attention to
>> support Prerendering on Desktop.
>>
>> https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
>> This is the document we discussed especially on Prerendering and
>> Extensions. In the design discussion we tried finding the best choice to
>> minimize possible compatibility breakage for most Extensions, but at the
>> same time, we understood it's unavoidable that some Extensions may be
>> surprised to see unexpected prerendering pages.
>>
>> So, our prepared mitigations are
>> - Enterprise Policy to disable Prerendering completely
>> - Users' report based incompatible Chrome Extensions list that disables
>> Prerendering when a user installs one in the list.
>>
>
> That sounds reasonable, but I wonder if more communication to the
> extensions community is warranted.
>
> +Simeon Vincent  for thoughts
>
>
>>
>> It minimizes the risk to block the rollout for such unexpected Extensions
>> compatibility breakages.
>>
>> For more visibility, here is the crbug entry to report such incompatible
>> Extensions quickly.
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1351312
>>
>> 
>> T hanks!
>>
>> On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell 
>> wrote:
>>
>>> In addition to the LGTM, I want to point out that during our discussion
>>> among the API Owners, we did specifically wonder about extension
>>> compatibility. Since this will change things for extensions, I think it
>>> will be important to look for compatibility problems popping up, and, if
>>> necessary, delay until any such problems are fully understood.
>>>
>>> /Daniel
>>> On 2022-08-31 16:34, Daniel Bratell wrote:
>>>
>>> LGTM3
>>>
>>> /Daniel
>>> On 2022-08-30 10:58, Yoav Weiss wrote:
>>>
>>> LGTM2 to expand support for desktop.
>>>
>>> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:
>>>
 LGTM1.
 It's pretty safe to expand support to desktop platforms, and it
 seems there are no negative signals.

 On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emails
>
> toyos...@chromium.org, angelrapo...@google.com
>
> Explainer
>
> This I2S aims to expand our efforts on Prerender2 (currently shipped
> only on Android) to Desktop.
>
> The full prerendering revamped explainer can be found at
>
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>
> Design docs
>
>
> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>
> Summary
>
> Prerendering is “pre”-rendering, it’s about pre-loading and rendering
> a Web page before the user actually navigates to it. The main goal of
> prerendering is to make the next page navigation faster, or ideally nearly
> instant.
>
> Sites can inform the user agent about which pages the user may likely
> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
> user is at page A and will likely navigate to page B next). Once the
> prerender is triggered, the browser pre-fetches the main resource,
> instantiates a hidden page, and processes the main resource to fetch and
> process more subresources.
>
> After shipping Prerender2 for Android (I2S speculation rules
> triggered Prerender2
> 
> and I2S for Omnibox triggered Prerender2
> ),
> we are now requesting approval to ship Prerender2 for Desktop. This 
> release
> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>
> With this feature, Chrome (Desktop) will start prerendering
> high-confidence URL suggestions provided by the page using speculation
> rules or directly by Omnibox. During the prerendering process, a page will
> process and construct the full DOM tree, including the execution of 
> scripts
> (this differs from No-state Prefetch
> 
> which only prefetches resources and doesn’t execute scripts).
>
> Note that we are not shipping cross-origin prerendering, which 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Yoav Weiss]

On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
wrote:

> Thank you for the feedback.
>
> Yes, the Extensions is the thing we have paid the biggest attention to
> support Prerendering on Desktop.
>
> https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
> This is the document we discussed especially on Prerendering and
> Extensions. In the design discussion we tried finding the best choice to
> minimize possible compatibility breakage for most Extensions, but at the
> same time, we understood it's unavoidable that some Extensions may be
> surprised to see unexpected prerendering pages.
>
> So, our prepared mitigations are
> - Enterprise Policy to disable Prerendering completely
> - Users' report based incompatible Chrome Extensions list that disables
> Prerendering when a user installs one in the list.
>

That sounds reasonable, but I wonder if more communication to the
extensions community is warranted.

+Simeon Vincent  for thoughts


>
> It minimizes the risk to block the rollout for such unexpected Extensions
> compatibility breakages.
>
> For more visibility, here is the crbug entry to report such incompatible
> Extensions quickly.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1351312
>
> 
> T hanks!
>
> On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell  wrote:
>
>> In addition to the LGTM, I want to point out that during our discussion
>> among the API Owners, we did specifically wonder about extension
>> compatibility. Since this will change things for extensions, I think it
>> will be important to look for compatibility problems popping up, and, if
>> necessary, delay until any such problems are fully understood.
>>
>> /Daniel
>> On 2022-08-31 16:34, Daniel Bratell wrote:
>>
>> LGTM3
>>
>> /Daniel
>> On 2022-08-30 10:58, Yoav Weiss wrote:
>>
>> LGTM2 to expand support for desktop.
>>
>> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:
>>
>>> LGTM1.
>>> It's pretty safe to expand support to desktop platforms, and it
>>> seems there are no negative signals.
>>>
>>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 toyos...@chromium.org, angelrapo...@google.com

 Explainer

 This I2S aims to expand our efforts on Prerender2 (currently shipped
 only on Android) to Desktop.

 The full prerendering revamped explainer can be found at

 https://github.com/WICG/nav-speculation/blob/main/README.md

 Specification

 https://wicg.github.io/nav-speculation/prerendering.html

 Design docs


 https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs

 Summary

 Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
 Web page before the user actually navigates to it. The main goal of
 prerendering is to make the next page navigation faster, or ideally nearly
 instant.

 Sites can inform the user agent about which pages the user may likely
 visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
 user is at page A and will likely navigate to page B next). Once the
 prerender is triggered, the browser pre-fetches the main resource,
 instantiates a hidden page, and processes the main resource to fetch and
 process more subresources.

 After shipping Prerender2 for Android (I2S speculation rules triggered
 Prerender2
 
 and I2S for Omnibox triggered Prerender2
 ),
 we are now requesting approval to ship Prerender2 for Desktop. This release
 will enable the same triggers (speculation rules and Omnibox) for Desktop.

 With this feature, Chrome (Desktop) will start prerendering
 high-confidence URL suggestions provided by the page using speculation
 rules or directly by Omnibox. During the prerendering process, a page will
 process and construct the full DOM tree, including the execution of scripts
 (this differs from No-state Prefetch
 
 which only prefetches resources and doesn’t execute scripts).

 Note that we are not shipping cross-origin prerendering, which allows a
 web page to prerender another page on a different origin.


 Blink component

 Internals>Preload>Prerender
 

 TAG review

 https://github.com/w3ctag/design-reviews/issues/667

 TAG review status

 All issues have been addressed.

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Takashi Toyoshima]

Thank you for the feedback.

Yes, the Extensions is the thing we have paid the biggest attention to
support Prerendering on Desktop.
https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
This is the document we discussed especially on Prerendering and
Extensions. In the design discussion we tried finding the best choice to
minimize possible compatibility breakage for most Extensions, but at the
same time, we understood it's unavoidable that some Extensions may be
surprised to see unexpected prerendering pages.

So, our prepared mitigations are
- Enterprise Policy to disable Prerendering completely
- Users' report based incompatible Chrome Extensions list that disables
Prerendering when a user installs one in the list.

It minimizes the risk to block the rollout for such unexpected Extensions
compatibility breakages.

For more visibility, here is the crbug entry to report such incompatible
Extensions quickly.
https://bugs.chromium.org/p/chromium/issues/detail?id=1351312


T hanks!

On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell  wrote:

> In addition to the LGTM, I want to point out that during our discussion
> among the API Owners, we did specifically wonder about extension
> compatibility. Since this will change things for extensions, I think it
> will be important to look for compatibility problems popping up, and, if
> necessary, delay until any such problems are fully understood.
>
> /Daniel
> On 2022-08-31 16:34, Daniel Bratell wrote:
>
> LGTM3
>
> /Daniel
> On 2022-08-30 10:58, Yoav Weiss wrote:
>
> LGTM2 to expand support for desktop.
>
> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:
>
>> LGTM1.
>> It's pretty safe to expand support to desktop platforms, and it
>> seems there are no negative signals.
>>
>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> toyos...@chromium.org, angelrapo...@google.com
>>>
>>> Explainer
>>>
>>> This I2S aims to expand our efforts on Prerender2 (currently shipped
>>> only on Android) to Desktop.
>>>
>>> The full prerendering revamped explainer can be found at
>>>
>>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>>
>>> Specification
>>>
>>> https://wicg.github.io/nav-speculation/prerendering.html
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>>
>>> Summary
>>>
>>> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
>>> Web page before the user actually navigates to it. The main goal of
>>> prerendering is to make the next page navigation faster, or ideally nearly
>>> instant.
>>>
>>> Sites can inform the user agent about which pages the user may likely
>>> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
>>> user is at page A and will likely navigate to page B next). Once the
>>> prerender is triggered, the browser pre-fetches the main resource,
>>> instantiates a hidden page, and processes the main resource to fetch and
>>> process more subresources.
>>>
>>> After shipping Prerender2 for Android (I2S speculation rules triggered
>>> Prerender2
>>> 
>>> and I2S for Omnibox triggered Prerender2
>>> ),
>>> we are now requesting approval to ship Prerender2 for Desktop. This release
>>> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>>>
>>> With this feature, Chrome (Desktop) will start prerendering
>>> high-confidence URL suggestions provided by the page using speculation
>>> rules or directly by Omnibox. During the prerendering process, a page will
>>> process and construct the full DOM tree, including the execution of scripts
>>> (this differs from No-state Prefetch
>>> 
>>> which only prefetches resources and doesn’t execute scripts).
>>>
>>> Note that we are not shipping cross-origin prerendering, which allows a
>>> web page to prerender another page on a different origin.
>>>
>>>
>>> Blink component
>>>
>>> Internals>Preload>Prerender
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/667
>>>
>>> TAG review status
>>>
>>> All issues have been addressed.
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk: this feature is focused on enabling Prerender on
>>> Desktop, which is already launched and available for Android.
>>>
>>> We believe that some browsers already have prerendering implementations
>>> which are not specified and may differ from each 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Daniel Bratell]

In addition to the LGTM, I want to point out that during our discussion 
among the API Owners, we did specifically wonder about extension 
compatibility. Since this will change things for extensions, I think it 
will be important to look for compatibility problems popping up, and, if 
necessary, delay until any such problems are fully understood.


/Daniel

On 2022-08-31 16:34, Daniel Bratell wrote:


LGTM3

/Daniel

On 2022-08-30 10:58, Yoav Weiss wrote:

LGTM2 to expand support for desktop.

On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:

LGTM1.
It's pretty safe to expand support to desktop platforms, and it
seems there are no negative signals.

On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev
 wrote:

Contact emails

toyos...@chromium.org, angelrapo...@google.com


Explainer

This I2S aims to expand our efforts on Prerender2 (currently
shipped only on Android) to Desktop.

The full prerendering revamped explainer can be found at

https://github.com/WICG/nav-speculation/blob/main/README.md



Specification

https://wicg.github.io/nav-speculation/prerendering.html



Design docs


https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs




Summary

Prerendering is “pre”-rendering, it’s about pre-loading and
rendering a Web page before the user actually navigates to
it. The main goal of prerendering is to make the next page
navigation faster, or ideally nearly instant.


Sites can inform the user agent about which pages the user
may likely visit, by asking to trigger a ‘prerendering’ for a
particular URL (e.g. user is at page A and will likely
navigate to page B next). Once the prerender is triggered,
the browser pre-fetches the main resource, instantiates a
hidden page, and processes the main resource to fetch and
process more subresources.


After shipping Prerender2 for Android (I2S speculation rules
triggered Prerender2

and
I2S for Omnibox triggered Prerender2

),
we are now requesting approval to ship Prerender2 for
Desktop. This release will enable the same triggers
(speculation rules and Omnibox) for Desktop.


With this feature, Chrome (Desktop) will start prerendering
high-confidence URL suggestions provided by the page using
speculation rules or directly by Omnibox. During the
prerendering process, a page will process and construct the
full DOM tree, including the execution of scripts (this
differs from No-state Prefetch

which
only prefetches resources and doesn’t execute scripts).


Note that we are not shipping cross-origin prerendering,
which allows a web page to prerender another page on a
different origin.



Blink component

Internals>Preload>Prerender




TAG review

https://github.com/w3ctag/design-reviews/issues/667


TAG review status

All issues have been addressed.


Risks



Interoperability and Compatibility

Interoperability risk: this feature is focused on enabling
Prerender on Desktop, which is already launched and available
for Android.


We believe that some browsers already have prerendering
implementations which are not specified and may differ from
each other, or not always exposed to the platform. Our vision
is to produce a specification that can help improve
interoperability. There is a risk that other browsers do not
converge on a prerendering standard but we hope that we’ll be
able to address legitimate concerns if any are raised by
interested parties.


Compatibility risk: this feature is focused on enabling
Prerender on Desktop, which is already launched and available
for Android. There are some use cases that will need to know
whether a page is being prerendered by the user agent or
navigated by the user, e.g. ads and analytics are likely
examples of this which are supported by already launched
features such as `document.prerendering` which lets a page
know that it’s being 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Daniel Bratell]

LGTM3

/Daniel

On 2022-08-30 10:58, Yoav Weiss wrote:

LGTM2 to expand support for desktop.

On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:

LGTM1.
It's pretty safe to expand support to desktop platforms, and it
seems there are no negative signals.

On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev
 wrote:

Contact emails

toyos...@chromium.org, angelrapo...@google.com


Explainer

This I2S aims to expand our efforts on Prerender2 (currently
shipped only on Android) to Desktop.

The full prerendering revamped explainer can be found at

https://github.com/WICG/nav-speculation/blob/main/README.md



Specification

https://wicg.github.io/nav-speculation/prerendering.html



Design docs


https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs




Summary

Prerendering is “pre”-rendering, it’s about pre-loading and
rendering a Web page before the user actually navigates to it.
The main goal of prerendering is to make the next page
navigation faster, or ideally nearly instant.


Sites can inform the user agent about which pages the user may
likely visit, by asking to trigger a ‘prerendering’ for a
particular URL (e.g. user is at page A and will likely
navigate to page B next). Once the prerender is triggered, the
browser pre-fetches the main resource, instantiates a hidden
page, and processes the main resource to fetch and process
more subresources.


After shipping Prerender2 for Android (I2S speculation rules
triggered Prerender2

and
I2S for Omnibox triggered Prerender2

),
we are now requesting approval to ship Prerender2 for Desktop.
This release will enable the same triggers (speculation rules
and Omnibox) for Desktop.


With this feature, Chrome (Desktop) will start prerendering
high-confidence URL suggestions provided by the page using
speculation rules or directly by Omnibox. During the
prerendering process, a page will process and construct the
full DOM tree, including the execution of scripts (this
differs from No-state Prefetch

which
only prefetches resources and doesn’t execute scripts).


Note that we are not shipping cross-origin prerendering, which
allows a web page to prerender another page on a different origin.



Blink component

Internals>Preload>Prerender




TAG review

https://github.com/w3ctag/design-reviews/issues/667


TAG review status

All issues have been addressed.


Risks



Interoperability and Compatibility

Interoperability risk: this feature is focused on enabling
Prerender on Desktop, which is already launched and available
for Android.


We believe that some browsers already have prerendering
implementations which are not specified and may differ from
each other, or not always exposed to the platform. Our vision
is to produce a specification that can help improve
interoperability. There is a risk that other browsers do not
converge on a prerendering standard but we hope that we’ll be
able to address legitimate concerns if any are raised by
interested parties.


Compatibility risk: this feature is focused on enabling
Prerender on Desktop, which is already launched and available
for Android. There are some use cases that will need to know
whether a page is being prerendered by the user agent or
navigated by the user, e.g. ads and analytics are likely
examples of this which are supported by already launched
features such as `document.prerendering` which lets a page
know that it’s being prerendered.


Chrome Extensions have abilities to interact with web contents
and have widely used API surfaces. We’ve been keeping in mind
compatibility with Extensions’ compatibility, including giving
enough capability for Extensions to properly support
Prerender2 [1].


A similar concern applies to (P)NaCl/PPAPI. However, these
plugins are on a deprecation 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Yoav Weiss]

LGTM2 to expand support for desktop.

On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:

> LGTM1.
> It's pretty safe to expand support to desktop platforms, and it
> seems there are no negative signals.
>
> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> toyos...@chromium.org, angelrapo...@google.com
>>
>> Explainer
>>
>> This I2S aims to expand our efforts on Prerender2 (currently shipped only
>> on Android) to Desktop.
>>
>> The full prerendering revamped explainer can be found at
>>
>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>
>> Specification
>>
>> https://wicg.github.io/nav-speculation/prerendering.html
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>
>> Summary
>>
>> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
>> Web page before the user actually navigates to it. The main goal of
>> prerendering is to make the next page navigation faster, or ideally nearly
>> instant.
>>
>> Sites can inform the user agent about which pages the user may likely
>> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
>> user is at page A and will likely navigate to page B next). Once the
>> prerender is triggered, the browser pre-fetches the main resource,
>> instantiates a hidden page, and processes the main resource to fetch and
>> process more subresources.
>>
>> After shipping Prerender2 for Android (I2S speculation rules triggered
>> Prerender2
>> 
>> and I2S for Omnibox triggered Prerender2
>> ),
>> we are now requesting approval to ship Prerender2 for Desktop. This release
>> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>>
>> With this feature, Chrome (Desktop) will start prerendering
>> high-confidence URL suggestions provided by the page using speculation
>> rules or directly by Omnibox. During the prerendering process, a page will
>> process and construct the full DOM tree, including the execution of scripts
>> (this differs from No-state Prefetch
>> 
>> which only prefetches resources and doesn’t execute scripts).
>>
>> Note that we are not shipping cross-origin prerendering, which allows a
>> web page to prerender another page on a different origin.
>>
>>
>> Blink component
>>
>> Internals>Preload>Prerender
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/667
>>
>> TAG review status
>>
>> All issues have been addressed.
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interoperability risk: this feature is focused on enabling Prerender on
>> Desktop, which is already launched and available for Android.
>>
>> We believe that some browsers already have prerendering implementations
>> which are not specified and may differ from each other, or not always
>> exposed to the platform. Our vision is to produce a specification that can
>> help improve interoperability. There is a risk that other browsers do not
>> converge on a prerendering standard but we hope that we’ll be able to
>> address legitimate concerns if any are raised by interested parties.
>>
>> Compatibility risk: this feature is focused on enabling Prerender on
>> Desktop, which is already launched and available for Android. There are
>> some use cases that will need to know whether a page is being prerendered
>> by the user agent or navigated by the user, e.g. ads and analytics are
>> likely examples of this which are supported by already launched features
>> such as `document.prerendering` which lets a page know that it’s being
>> prerendered.
>>
>> Chrome Extensions have abilities to interact with web contents and have
>> widely used API surfaces. We’ve been keeping in mind compatibility with
>> Extensions’ compatibility, including giving enough capability for
>> Extensions to properly support Prerender2 [1].
>>
>> A similar concern applies to (P)NaCl/PPAPI. However, these plugins are on
>> a deprecation path. In the meantime, given that NaCl permits the page to
>> perform powerful operations, we are taking the safe route by canceling
>> prerendering if it triggers  a request to load a NaCl module.
>>
>> [1]
>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs/edit
>>
>>
>> Gecko: When we launched Prerender2 for Android, we had some informal
>> positive discussion with Gecko engineers on the HTML Standard issue
>> tracker
>>  and in
>> the HTML triage call
>> ;

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[TAMURA, Kent]

LGTM1.
It's pretty safe to expand support to desktop platforms, and it seems there
are no negative signals.

On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> toyos...@chromium.org, angelrapo...@google.com
>
> Explainer
>
> This I2S aims to expand our efforts on Prerender2 (currently shipped only
> on Android) to Desktop.
>
> The full prerendering revamped explainer can be found at
>
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>
> Design docs
>
>
> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>
> Summary
>
> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
> Web page before the user actually navigates to it. The main goal of
> prerendering is to make the next page navigation faster, or ideally nearly
> instant.
>
> Sites can inform the user agent about which pages the user may likely
> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
> user is at page A and will likely navigate to page B next). Once the
> prerender is triggered, the browser pre-fetches the main resource,
> instantiates a hidden page, and processes the main resource to fetch and
> process more subresources.
>
> After shipping Prerender2 for Android (I2S speculation rules triggered
> Prerender2
> 
> and I2S for Omnibox triggered Prerender2
> ),
> we are now requesting approval to ship Prerender2 for Desktop. This release
> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>
> With this feature, Chrome (Desktop) will start prerendering
> high-confidence URL suggestions provided by the page using speculation
> rules or directly by Omnibox. During the prerendering process, a page will
> process and construct the full DOM tree, including the execution of scripts
> (this differs from No-state Prefetch
> 
> which only prefetches resources and doesn’t execute scripts).
>
> Note that we are not shipping cross-origin prerendering, which allows a
> web page to prerender another page on a different origin.
>
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/667
>
> TAG review status
>
> All issues have been addressed.
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk: this feature is focused on enabling Prerender on
> Desktop, which is already launched and available for Android.
>
> We believe that some browsers already have prerendering implementations
> which are not specified and may differ from each other, or not always
> exposed to the platform. Our vision is to produce a specification that can
> help improve interoperability. There is a risk that other browsers do not
> converge on a prerendering standard but we hope that we’ll be able to
> address legitimate concerns if any are raised by interested parties.
>
> Compatibility risk: this feature is focused on enabling Prerender on
> Desktop, which is already launched and available for Android. There are
> some use cases that will need to know whether a page is being prerendered
> by the user agent or navigated by the user, e.g. ads and analytics are
> likely examples of this which are supported by already launched features
> such as `document.prerendering` which lets a page know that it’s being
> prerendered.
>
> Chrome Extensions have abilities to interact with web contents and have
> widely used API surfaces. We’ve been keeping in mind compatibility with
> Extensions’ compatibility, including giving enough capability for
> Extensions to properly support Prerender2 [1].
>
> A similar concern applies to (P)NaCl/PPAPI. However, these plugins are on
> a deprecation path. In the meantime, given that NaCl permits the page to
> perform powerful operations, we are taking the safe route by canceling
> prerendering if it triggers  a request to load a NaCl module.
>
> [1]
> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs/edit
>
>
> Gecko: When we launched Prerender2 for Android, we had some informal
> positive discussion with Gecko engineers on the HTML Standard issue
> tracker
>  and in
> the HTML triage call
> ;
> formal positions request here:
> https://github.com/mozilla/standards-positions/issues/613
>
>
> WebKit: WebKit already ships URL-bar triggered prerendering, but not any
> APIs for letting pages know about it, and 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Takashi Toyoshima]

Hi, Joe.

Thank you for your feedback.

On Thu, Aug 25, 2022 at 2:06 AM 'Joe Medley' via blink-dev <
blink-dev@chromium.org> wrote:

> I think you did everything as right as anyone could. Chrome Status is a
> bit confusing when it comes to shipping milestones and flags.
>
> The only thing required for a finch experiment is the "Finch experiment:"
> field, which takes a CR bug. Edit your feature, click "Edit all fields",
> then search for the field.
>
> Anyone who might be reading this who works on a web platform feature
> should stop reading this now. What I'm about to say doesn't apply to you.
>
> What's the rollout schedule for your finch flag? Will this be available to
> 100% of Chrome users by the time 105 reaches stable (Aug 30)? I'm trying to
> work out what you need to put in the milestone fields. I need more
> information to do that.
>

We just follow the standard finch-backed rollout plan, but with multiple
arms to evaluate performance gains.
So, now we run 30% enabled experiments for Beta, and will start incremental
stable launch from 1% through to 100% once m105 goes to stable and we
complete the launch review, including this I2S step. We'd roll out
speculation rules first, then roll out DUI based prerendering next with a
separate finch config so that we can mitigate the risk and can understand
which feature is the root cause when something wrong happens.

I'm happy to hear more feedback from other blink-dev people and API owners!

Thanks!


> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Aug 24, 2022 at 7:17 AM Angel Raposo 
> wrote:
>
>> Hi Joe,
>>
>> We started the beta behind a finch flag with m105.
>> Can you point me out to where I need to replace the DevTile milestone?
>> I'm quite new on the role, helping the team on a 20% capacity so I may have
>> misconfigured something in the Chromestatus entry before generating this
>> template?
>>
>> Thanks,
>> Angel.
>>
>> On Tue, Aug 23, 2022 at 11:49 PM Joe Medley  wrote:
>>
>>> I think I know why I'm confused, please tell me if this is correct. Did
>>> you label this as being behind a flag (DevTrial) because it's under a Finch
>>> flag? The DevTile milestone fields do not apply to finch flags.
>>>
>>> In which version of beta did the Finch experiment start?
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Aug 22, 2022 at 6:30 PM Angel Raposo 
>>> wrote:
>>>
 Hi Joe,

 Thanks for your questions, Let me share some background of the project
 situation:

 Prerender loads and renders high-likely to be visited web pages before
 the user actually navigates to them, based on different triggers.
 We've already launched a few triggers for Android in stable, e.g.:

- *Direct URL Input

 
  (M101)*:
as the user types the address in the Omnibar, the browser may choose to
prerender a particular site if the user is very likely to browse it. 
 This
is fully approved and already active in stable for a small percentage of
users and we are ramping up.
- *Speculation rules
 (M103)*:
site owners can hint pages, through the speculation rules API, that 
 users
are likely going to browse next. This is fully launched on stable for
Android

 With this I2S, we are aiming to launch Prerender2 for Desktop which
 will enable the same approved triggers for Desktop.
 We already got the approval for beta
 , which
 is under a finch experiment right now with a percentage of users testing
 with positive results.

 Once we get the approval for stable, we'll work on a roll-out plan,
 incrementing slowly the percentage of users adopting the new feature.

 Thanks,
 Angel.


 On Tue, Aug 23, 2022 at 2:57 AM Joe Medley  wrote:

> Angel,
>
> Can you please clarify a few things for me. I'm trying to work out
> whether this is eligible for listing in the beta announcement
> .
>
> You said this shipped in Android already. I only see that it is behind
> a flag in Android. When was this enabled by default? The beta announcement
> doesn't include items that require enabling via the command line or an 
> item
> in chrome://flags. (This is what 'developer trial' refers to.) Items that
> are enabled by default are included whether a flag is present or not.
>
> Given that information, can you please tell me what you're doing on
> desktop?

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

['Joe Medley' via blink-dev]

I think you did everything as right as anyone could. Chrome Status is a bit
confusing when it comes to shipping milestones and flags.

The only thing required for a finch experiment is the "Finch experiment:"
field, which takes a CR bug. Edit your feature, click "Edit all fields",
then search for the field.

Anyone who might be reading this who works on a web platform feature should
stop reading this now. What I'm about to say doesn't apply to you.

What's the rollout schedule for your finch flag? Will this be available to
100% of Chrome users by the time 105 reaches stable (Aug 30)? I'm trying to
work out what you need to put in the milestone fields. I need more
information to do that.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Aug 24, 2022 at 7:17 AM Angel Raposo  wrote:

> Hi Joe,
>
> We started the beta behind a finch flag with m105.
> Can you point me out to where I need to replace the DevTile milestone? I'm
> quite new on the role, helping the team on a 20% capacity so I may have
> misconfigured something in the Chromestatus entry before generating this
> template?
>
> Thanks,
> Angel.
>
> On Tue, Aug 23, 2022 at 11:49 PM Joe Medley  wrote:
>
>> I think I know why I'm confused, please tell me if this is correct. Did
>> you label this as being behind a flag (DevTrial) because it's under a Finch
>> flag? The DevTile milestone fields do not apply to finch flags.
>>
>> In which version of beta did the Finch experiment start?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Aug 22, 2022 at 6:30 PM Angel Raposo 
>> wrote:
>>
>>> Hi Joe,
>>>
>>> Thanks for your questions, Let me share some background of the project
>>> situation:
>>>
>>> Prerender loads and renders high-likely to be visited web pages before
>>> the user actually navigates to them, based on different triggers.
>>> We've already launched a few triggers for Android in stable, e.g.:
>>>
>>>- *Direct URL Input
>>>
>>> 
>>>  (M101)*:
>>>as the user types the address in the Omnibar, the browser may choose to
>>>prerender a particular site if the user is very likely to browse it. This
>>>is fully approved and already active in stable for a small percentage of
>>>users and we are ramping up.
>>>- *Speculation rules
>>> (M103)*:
>>>site owners can hint pages, through the speculation rules API, that users
>>>are likely going to browse next. This is fully launched on stable for
>>>Android
>>>
>>> With this I2S, we are aiming to launch Prerender2 for Desktop which will
>>> enable the same approved triggers for Desktop.
>>> We already got the approval for beta
>>> , which
>>> is under a finch experiment right now with a percentage of users testing
>>> with positive results.
>>>
>>> Once we get the approval for stable, we'll work on a roll-out plan,
>>> incrementing slowly the percentage of users adopting the new feature.
>>>
>>> Thanks,
>>> Angel.
>>>
>>>
>>> On Tue, Aug 23, 2022 at 2:57 AM Joe Medley  wrote:
>>>
 Angel,

 Can you please clarify a few things for me. I'm trying to work out
 whether this is eligible for listing in the beta announcement
 .

 You said this shipped in Android already. I only see that it is behind
 a flag in Android. When was this enabled by default? The beta announcement
 doesn't include items that require enabling via the command line or an item
 in chrome://flags. (This is what 'developer trial' refers to.) Items that
 are enabled by default are included whether a flag is present or not.

 Given that information, can you please tell me what you're doing on
 desktop?

 Also, did you mean to say you were shipping in 105? It goes to stable
 in 8 days. Wouldn't you want this to be in beta first?

 Thanks,
 Joe
 Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195 <(816)%20678-7195>
 *If an API's not documented it doesn't exist.*


 On Thu, Aug 18, 2022 at 12:07 AM 'Angel Raposo' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emails
>
> toyos...@chromium.org, angelrapo...@google.com
>
> Explainer
>
> This I2S aims to expand our efforts on Prerender2 (currently shipped
> only on Android) to Desktop.
>
> The full prerendering revamped explainer can be found at
>
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

['Angel Raposo' via blink-dev]

Hi Joe,

We started the beta behind a finch flag with m105.
Can you point me out to where I need to replace the DevTile milestone? I'm
quite new on the role, helping the team on a 20% capacity so I may have
misconfigured something in the Chromestatus entry before generating this
template?

Thanks,
Angel.

On Tue, Aug 23, 2022 at 11:49 PM Joe Medley  wrote:

> I think I know why I'm confused, please tell me if this is correct. Did
> you label this as being behind a flag (DevTrial) because it's under a Finch
> flag? The DevTile milestone fields do not apply to finch flags.
>
> In which version of beta did the Finch experiment start?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Aug 22, 2022 at 6:30 PM Angel Raposo 
> wrote:
>
>> Hi Joe,
>>
>> Thanks for your questions, Let me share some background of the project
>> situation:
>>
>> Prerender loads and renders high-likely to be visited web pages before
>> the user actually navigates to them, based on different triggers.
>> We've already launched a few triggers for Android in stable, e.g.:
>>
>>- *Direct URL Input
>>
>> 
>>  (M101)*:
>>as the user types the address in the Omnibar, the browser may choose to
>>prerender a particular site if the user is very likely to browse it. This
>>is fully approved and already active in stable for a small percentage of
>>users and we are ramping up.
>>- *Speculation rules
>> (M103)*:
>>site owners can hint pages, through the speculation rules API, that users
>>are likely going to browse next. This is fully launched on stable for
>>Android
>>
>> With this I2S, we are aiming to launch Prerender2 for Desktop which will
>> enable the same approved triggers for Desktop.
>> We already got the approval for beta
>> , which
>> is under a finch experiment right now with a percentage of users testing
>> with positive results.
>>
>> Once we get the approval for stable, we'll work on a roll-out plan,
>> incrementing slowly the percentage of users adopting the new feature.
>>
>> Thanks,
>> Angel.
>>
>>
>> On Tue, Aug 23, 2022 at 2:57 AM Joe Medley  wrote:
>>
>>> Angel,
>>>
>>> Can you please clarify a few things for me. I'm trying to work out
>>> whether this is eligible for listing in the beta announcement
>>> .
>>>
>>> You said this shipped in Android already. I only see that it is behind a
>>> flag in Android. When was this enabled by default? The beta announcement
>>> doesn't include items that require enabling via the command line or an item
>>> in chrome://flags. (This is what 'developer trial' refers to.) Items that
>>> are enabled by default are included whether a flag is present or not.
>>>
>>> Given that information, can you please tell me what you're doing on
>>> desktop?
>>>
>>> Also, did you mean to say you were shipping in 105? It goes to stable in
>>> 8 days. Wouldn't you want this to be in beta first?
>>>
>>> Thanks,
>>> Joe
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Thu, Aug 18, 2022 at 12:07 AM 'Angel Raposo' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 toyos...@chromium.org, angelrapo...@google.com

 Explainer

 This I2S aims to expand our efforts on Prerender2 (currently shipped
 only on Android) to Desktop.

 The full prerendering revamped explainer can be found at

 https://github.com/WICG/nav-speculation/blob/main/README.md

 Specification

 https://wicg.github.io/nav-speculation/prerendering.html

 Design docs


 https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs

 Summary

 Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
 Web page before the user actually navigates to it. The main goal of
 prerendering is to make the next page navigation faster, or ideally nearly
 instant.

 Sites can inform the user agent about which pages the user may likely
 visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
 user is at page A and will likely navigate to page B next). Once the
 prerender is triggered, the browser pre-fetches the main resource,
 instantiates a hidden page, and processes the main resource to fetch and
 process more subresources.

 After shipping Prerender2 for Android (I2S speculation rules triggered
 Prerender2
 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

['Angel Raposo' via blink-dev]

Hi Joe,

Thanks for your questions, Let me share some background of the project
situation:

Prerender loads and renders high-likely to be visited web pages before the
user actually navigates to them, based on different triggers.
We've already launched a few triggers for Android in stable, e.g.:

   - *Direct URL Input
   

(M101)*:
   as the user types the address in the Omnibar, the browser may choose to
   prerender a particular site if the user is very likely to browse it. This
   is fully approved and already active in stable for a small percentage of
   users and we are ramping up.
   - *Speculation rules
    (M103)*:
   site owners can hint pages, through the speculation rules API, that users
   are likely going to browse next. This is fully launched on stable for
   Android

With this I2S, we are aiming to launch Prerender2 for Desktop which will
enable the same approved triggers for Desktop.
We already got the approval for beta
, which is
under a finch experiment right now with a percentage of users testing with
positive results.

Once we get the approval for stable, we'll work on a roll-out plan,
incrementing slowly the percentage of users adopting the new feature.

Thanks,
Angel.


On Tue, Aug 23, 2022 at 2:57 AM Joe Medley  wrote:

> Angel,
>
> Can you please clarify a few things for me. I'm trying to work out whether
> this is eligible for listing in the beta announcement
> .
>
> You said this shipped in Android already. I only see that it is behind a
> flag in Android. When was this enabled by default? The beta announcement
> doesn't include items that require enabling via the command line or an item
> in chrome://flags. (This is what 'developer trial' refers to.) Items that
> are enabled by default are included whether a flag is present or not.
>
> Given that information, can you please tell me what you're doing on
> desktop?
>
> Also, did you mean to say you were shipping in 105? It goes to stable in 8
> days. Wouldn't you want this to be in beta first?
>
> Thanks,
> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Thu, Aug 18, 2022 at 12:07 AM 'Angel Raposo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> toyos...@chromium.org, angelrapo...@google.com
>>
>> Explainer
>>
>> This I2S aims to expand our efforts on Prerender2 (currently shipped only
>> on Android) to Desktop.
>>
>> The full prerendering revamped explainer can be found at
>>
>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>
>> Specification
>>
>> https://wicg.github.io/nav-speculation/prerendering.html
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>
>> Summary
>>
>> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
>> Web page before the user actually navigates to it. The main goal of
>> prerendering is to make the next page navigation faster, or ideally nearly
>> instant.
>>
>> Sites can inform the user agent about which pages the user may likely
>> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
>> user is at page A and will likely navigate to page B next). Once the
>> prerender is triggered, the browser pre-fetches the main resource,
>> instantiates a hidden page, and processes the main resource to fetch and
>> process more subresources.
>>
>> After shipping Prerender2 for Android (I2S speculation rules triggered
>> Prerender2
>> 
>> and I2S for Omnibox triggered Prerender2
>> ),
>> we are now requesting approval to ship Prerender2 for Desktop. This release
>> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>>
>> With this feature, Chrome (Desktop) will start prerendering
>> high-confidence URL suggestions provided by the page using speculation
>> rules or directly by Omnibox. During the prerendering process, a page will
>> process and construct the full DOM tree, including the execution of scripts
>> (this differs from No-state Prefetch
>> 
>> which only prefetches resources and doesn’t execute scripts).
>>
>> Note that we are not shipping cross-origin prerendering, which allows a
>> web page to prerender another page on a different origin.
>>
>>
>> Blink component
>>
>> Internals>Preload>Prerender
>> 
>>
>> TAG review
>>
>> 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

['Joe Medley' via blink-dev]

I think I know why I'm confused, please tell me if this is correct. Did you
label this as being behind a flag (DevTrial) because it's under a Finch
flag? The DevTile milestone fields do not apply to finch flags.

In which version of beta did the Finch experiment start?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 22, 2022 at 6:30 PM Angel Raposo  wrote:

> Hi Joe,
>
> Thanks for your questions, Let me share some background of the project
> situation:
>
> Prerender loads and renders high-likely to be visited web pages before the
> user actually navigates to them, based on different triggers.
> We've already launched a few triggers for Android in stable, e.g.:
>
>- *Direct URL Input
>
> 
>  (M101)*:
>as the user types the address in the Omnibar, the browser may choose to
>prerender a particular site if the user is very likely to browse it. This
>is fully approved and already active in stable for a small percentage of
>users and we are ramping up.
>- *Speculation rules
> (M103)*:
>site owners can hint pages, through the speculation rules API, that users
>are likely going to browse next. This is fully launched on stable for
>Android
>
> With this I2S, we are aiming to launch Prerender2 for Desktop which will
> enable the same approved triggers for Desktop.
> We already got the approval for beta
> , which is
> under a finch experiment right now with a percentage of users testing with
> positive results.
>
> Once we get the approval for stable, we'll work on a roll-out plan,
> incrementing slowly the percentage of users adopting the new feature.
>
> Thanks,
> Angel.
>
>
> On Tue, Aug 23, 2022 at 2:57 AM Joe Medley  wrote:
>
>> Angel,
>>
>> Can you please clarify a few things for me. I'm trying to work out
>> whether this is eligible for listing in the beta announcement
>> .
>>
>> You said this shipped in Android already. I only see that it is behind a
>> flag in Android. When was this enabled by default? The beta announcement
>> doesn't include items that require enabling via the command line or an item
>> in chrome://flags. (This is what 'developer trial' refers to.) Items that
>> are enabled by default are included whether a flag is present or not.
>>
>> Given that information, can you please tell me what you're doing on
>> desktop?
>>
>> Also, did you mean to say you were shipping in 105? It goes to stable in
>> 8 days. Wouldn't you want this to be in beta first?
>>
>> Thanks,
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, Aug 18, 2022 at 12:07 AM 'Angel Raposo' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> toyos...@chromium.org, angelrapo...@google.com
>>>
>>> Explainer
>>>
>>> This I2S aims to expand our efforts on Prerender2 (currently shipped
>>> only on Android) to Desktop.
>>>
>>> The full prerendering revamped explainer can be found at
>>>
>>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>>
>>> Specification
>>>
>>> https://wicg.github.io/nav-speculation/prerendering.html
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>>
>>> Summary
>>>
>>> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
>>> Web page before the user actually navigates to it. The main goal of
>>> prerendering is to make the next page navigation faster, or ideally nearly
>>> instant.
>>>
>>> Sites can inform the user agent about which pages the user may likely
>>> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
>>> user is at page A and will likely navigate to page B next). Once the
>>> prerender is triggered, the browser pre-fetches the main resource,
>>> instantiates a hidden page, and processes the main resource to fetch and
>>> process more subresources.
>>>
>>> After shipping Prerender2 for Android (I2S speculation rules triggered
>>> Prerender2
>>> 
>>> and I2S for Omnibox triggered Prerender2
>>> ),
>>> we are now requesting approval to ship Prerender2 for Desktop. This release
>>> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>>>
>>> With this feature, Chrome (Desktop) will start prerendering
>>> high-confidence URL suggestions provided by the page using speculation
>>> rules or directly by Omnibox. During the prerendering 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

['Joe Medley' via blink-dev]

Angel,

Can you please clarify a few things for me. I'm trying to work out whether
this is eligible for listing in the beta announcement
.

You said this shipped in Android already. I only see that it is behind a
flag in Android. When was this enabled by default? The beta announcement
doesn't include items that require enabling via the command line or an item
in chrome://flags. (This is what 'developer trial' refers to.) Items that
are enabled by default are included whether a flag is present or not.

Given that information, can you please tell me what you're doing on desktop?

Also, did you mean to say you were shipping in 105? It goes to stable in 8
days. Wouldn't you want this to be in beta first?

Thanks,
Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Aug 18, 2022 at 12:07 AM 'Angel Raposo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> toyos...@chromium.org, angelrapo...@google.com
>
> Explainer
>
> This I2S aims to expand our efforts on Prerender2 (currently shipped only
> on Android) to Desktop.
>
> The full prerendering revamped explainer can be found at
>
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>
> Design docs
>
>
> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>
> Summary
>
> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
> Web page before the user actually navigates to it. The main goal of
> prerendering is to make the next page navigation faster, or ideally nearly
> instant.
>
> Sites can inform the user agent about which pages the user may likely
> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
> user is at page A and will likely navigate to page B next). Once the
> prerender is triggered, the browser pre-fetches the main resource,
> instantiates a hidden page, and processes the main resource to fetch and
> process more subresources.
>
> After shipping Prerender2 for Android (I2S speculation rules triggered
> Prerender2
> 
> and I2S for Omnibox triggered Prerender2
> ),
> we are now requesting approval to ship Prerender2 for Desktop. This release
> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>
> With this feature, Chrome (Desktop) will start prerendering
> high-confidence URL suggestions provided by the page using speculation
> rules or directly by Omnibox. During the prerendering process, a page will
> process and construct the full DOM tree, including the execution of scripts
> (this differs from No-state Prefetch
> 
> which only prefetches resources and doesn’t execute scripts).
>
> Note that we are not shipping cross-origin prerendering, which allows a
> web page to prerender another page on a different origin.
>
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/667
>
> TAG review status
>
> All issues have been addressed.
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk: this feature is focused on enabling Prerender on
> Desktop, which is already launched and available for Android.
>
> We believe that some browsers already have prerendering implementations
> which are not specified and may differ from each other, or not always
> exposed to the platform. Our vision is to produce a specification that can
> help improve interoperability. There is a risk that other browsers do not
> converge on a prerendering standard but we hope that we’ll be able to
> address legitimate concerns if any are raised by interested parties.
>
> Compatibility risk: this feature is focused on enabling Prerender on
> Desktop, which is already launched and available for Android. There are
> some use cases that will need to know whether a page is being prerendered
> by the user agent or navigated by the user, e.g. ads and analytics are
> likely examples of this which are supported by already launched features
> such as `document.prerendering` which lets a page know that it’s being
> prerendered.
>
> Chrome Extensions have abilities to interact with web contents and have
> widely used API surfaces. We’ve been keeping in mind compatibility with
> Extensions’ compatibility, including giving enough capability for
> Extensions to properly support Prerender2 [1].
>
> A similar concern applies to (P)NaCl/PPAPI. However, these plugins are on
> a deprecation path. In the meantime, given that NaCl 

[blink-dev] Intent to Ship: Prerender2 for Desktop

['Angel Raposo' via blink-dev]

Contact emails

toyos...@chromium.org, angelrapo...@google.com

Explainer

This I2S aims to expand our efforts on Prerender2 (currently shipped only
on Android) to Desktop.

The full prerendering revamped explainer can be found at

https://github.com/WICG/nav-speculation/blob/main/README.md

Specification

https://wicg.github.io/nav-speculation/prerendering.html

Design docs

https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs

Summary

Prerendering is “pre”-rendering, it’s about pre-loading and rendering a Web
page before the user actually navigates to it. The main goal of
prerendering is to make the next page navigation faster, or ideally nearly
instant.

Sites can inform the user agent about which pages the user may likely
visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
user is at page A and will likely navigate to page B next). Once the
prerender is triggered, the browser pre-fetches the main resource,
instantiates a hidden page, and processes the main resource to fetch and
process more subresources.

After shipping Prerender2 for Android (I2S speculation rules triggered
Prerender2

and I2S for Omnibox triggered Prerender2
),
we are now requesting approval to ship Prerender2 for Desktop. This release
will enable the same triggers (speculation rules and Omnibox) for Desktop.

With this feature, Chrome (Desktop) will start prerendering high-confidence
URL suggestions provided by the page using speculation rules or directly by
Omnibox. During the prerendering process, a page will process and construct
the full DOM tree, including the execution of scripts (this differs
from No-state
Prefetch
 which
only prefetches resources and doesn’t execute scripts).

Note that we are not shipping cross-origin prerendering, which allows a web
page to prerender another page on a different origin.


Blink component

Internals>Preload>Prerender


TAG review

https://github.com/w3ctag/design-reviews/issues/667

TAG review status

All issues have been addressed.

Risks


Interoperability and Compatibility

Interoperability risk: this feature is focused on enabling Prerender on
Desktop, which is already launched and available for Android.

We believe that some browsers already have prerendering implementations
which are not specified and may differ from each other, or not always
exposed to the platform. Our vision is to produce a specification that can
help improve interoperability. There is a risk that other browsers do not
converge on a prerendering standard but we hope that we’ll be able to
address legitimate concerns if any are raised by interested parties.

Compatibility risk: this feature is focused on enabling Prerender on
Desktop, which is already launched and available for Android. There are
some use cases that will need to know whether a page is being prerendered
by the user agent or navigated by the user, e.g. ads and analytics are
likely examples of this which are supported by already launched features
such as `document.prerendering` which lets a page know that it’s being
prerendered.

Chrome Extensions have abilities to interact with web contents and have
widely used API surfaces. We’ve been keeping in mind compatibility with
Extensions’ compatibility, including giving enough capability for
Extensions to properly support Prerender2 [1].

A similar concern applies to (P)NaCl/PPAPI. However, these plugins are on a
deprecation path. In the meantime, given that NaCl permits the page to
perform powerful operations, we are taking the safe route by canceling
prerendering if it triggers  a request to load a NaCl module.

[1]
https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs/edit


Gecko: When we launched Prerender2 for Android, we had some informal
positive discussion with Gecko engineers on the HTML Standard issue tracker
 and in
the HTML triage call
;
formal positions request here:
https://github.com/mozilla/standards-positions/issues/613


WebKit: WebKit already ships URL-bar triggered prerendering, but not any
APIs for letting pages know about it, and it's unclear what strategy they
are using to prohibit disruptive behaviors for prerendered pages. When we
launched Prerender2 for Android, we reached out for a formal positions
request here in the hopes of moving toward interoperability:
https://lists.webkit.org/pipermail/webkit-dev/2022-February/032113.html

Web developers: When we launched Prerender2 for Android, we received
positive feedback from