Intent to Ship: Prerender2 for Desktop

386 views
Skip to first unread message

Angel Raposo

unread,
Aug 18, 2022, 3:07:54 AM8/18/22
to blin...@chromium.org, Takashi Toyoshima

Contact emails

toyo...@chromium.org, angelr...@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 initial web developers testing the speculation rules triggers (see https://github.com/WICG/proposals/issues/2 for positive sentiments on speculation rules triggered).



Other signals: When we launched Prerender2 for Android we created a public request for feedback published (https://web.dev/speculative-prerendering/#feedback-welcome) which is currently being managed through: https://github.com/WICG/nav-speculation/issues



Ergonomics

This feature is triggered by the speculation rules API and Omnibox. We don't anticipate any conflict with other Platform APIs.


IT admins can disable Prerender2 via the existing group policy "NetworkPredictionOptions"


We are shipping the same web-exposed APIs previously launched on Android: document.prerendering, prerenderingchange event and performanceEntry.activationStart timing.



Activation

There are two mechanisms to trigger a prerender:
(1) Speculation rules in which developers can immediately take advantage of this feature by defining suggestions that the user agent will take into consideration when deciding if a page is likely going to be browsed next.

(2) Omnibox where the user agent decides if an URL should be prerendered according to different heuristics.
Both of these triggers are already shipped for Android. With this request, we want to allow Desktop to also trigger Prerender2 in the same scenarios.


The feature should just work for most existing pages but developers should be aware of restrictions on prerendering content (they cannot play audio or perform other disruptive behavior, etc.). As we grow our reach of navigations by enabling the Desktop version, we will pay special attention to the  documentation available to developers.


We’ve also paid close  attention to extensions. We believe that extensions shouldn’t be affected by this feature as the restricted features are deferred behind a Promise resolution, and many extensions appear to just work transparently.


To report breakages in extensions developers have two options: they can comment on the extensions related compatibility issue at https://crbug.com/1351312, or they can discuss the desired API surface in the mail group: https://groups.google.com/a/chromium.org/g/chromium-extensions.



Security

We are scaling an already shipped feature in Android to cover Desktop.

The speculation rules API was the first use of the Multiple-Page Architecture, which is a significant change to Chromium's internals. Both MPArch and the speculation rules API underwent significant security review. From a web-exposed perspective, the security and privacy concerns are smaller, because this feature is restricted to the same-origin case only. WebView application risks

Prerendering is not supported on WebView and doesn’t deprecate or change behavior of existing APIs directly.



Debuggability

We are actively talking to the DevTools team about adding general Prerender support to it [metabug] with a current focus in providing meaningful debugging messages.
The current MVP is to reveal the status of prerendered pages so web developers can know if prerendering succeeded or not.


See [this document] for our longer-term plan for improving the experience of debugging prerendering with DevTools.


Prerendered pages are also visible in chrome://process-internals.




Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. Prerender2 was originally shipped on Android. This Intent expands it to cover Windows, Mac, Linux, and Chrome OS. It remains disabled on Android WebView.



Is this feature fully tested by web-platform-tests?

We have written a lot of web platform tests using speculation rules as the trigger:

https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned


Flag name

Prerender2


Requires code in //chrome?

True


Tracking bug

https://crbug.com/1278141


Launch bug

https://crbug.com/1332400


Estimated milestones

DevTrial on desktop

105


DevTrial on Android

Already shipped on 103



Anticipated spec changes

With this I2S we are aiming to scale already shipped APIs to Desktop.


When we shipped the speculation rules, we reviewed all the current pending discussions and all of them were resolved with the initial launch without causing compatibility issues.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5197044678393856


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFWCB1n7W-gfr9b8FTNtB1bNDnYJ_%3DkSfWiY%2BtfGyqjuXe52zA%40mail.gmail.com



This intent message was generated by Chrome Platform Status.



--
Angel Raposo  |  Engagement Manager  |  angel...@google.com  |   Google Japan G.K.  


This email may be confidential or privileged.  If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person.  Thanks.

The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation.  No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.

もし、このメッセージが誤って貴殿に送信されたと思われる場合には、機密情報を含んでいる可能性もありますので、どなたにも転送せず、添付ファイルも含めて削除していただくとともに、発信者にその旨をお伝えいただきますようお願いいたします。

Joe Medley

unread,
Aug 22, 2022, 1:57:27 PM8/22/22
to Angel Raposo, blink-dev, Takashi Toyoshima
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 | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA9vRHy7_o1ftcTz2-pC5rOPtZRhas5PGLw4HJ--v%2Bewkvcoww%40mail.gmail.com.

Joe Medley

unread,
Aug 23, 2022, 10:49:17 AM8/23/22
to Angel Raposo, blink-dev, Takashi Toyoshima
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 | jme...@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 <angel...@google.com> 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.

Angel Raposo

unread,
Aug 23, 2022, 1:07:36 PM8/23/22
to Joe Medley, blink-dev, Takashi Toyoshima
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 <jme...@google.com> wrote:

Angel Raposo

unread,
Aug 24, 2022, 10:17:06 AM8/24/22
to Joe Medley, blink-dev, Takashi Toyoshima
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.

Joe Medley

unread,
Aug 24, 2022, 1:06:38 PM8/24/22
to Angel Raposo, blink-dev, Takashi Toyoshima
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 | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Takashi Toyoshima

unread,
Aug 29, 2022, 5:05:20 AM8/29/22
to Joe Medley, Angel Raposo, blink-dev
Hi, Joe.

Thank you for your feedback.

On Thu, Aug 25, 2022 at 2:06 AM 'Joe Medley' via blink-dev <blin...@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!
 


--
Takashi Toyoshima
Software Engineer, Google

TAMURA, Kent

unread,
Aug 30, 2022, 2:53:31 AM8/30/22
to Angel Raposo, blin...@chromium.org, Takashi Toyoshima
LGTM1.
It's pretty safe to expand support to desktop platforms, and it seems there are no negative signals.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA9vRHy7_o1ftcTz2-pC5rOPtZRhas5PGLw4HJ--v%2Bewkvcoww%40mail.gmail.com.


--
TAMURA Kent
Software Engineer, Google


Yoav Weiss

unread,
Aug 30, 2022, 4:59:32 AM8/30/22
to TAMURA, Kent, Angel Raposo, blink-dev, Takashi Toyoshima
LGTM2 to expand support for desktop.

Daniel Bratell

unread,
Aug 31, 2022, 10:35:01 AM8/31/22
to Yoav Weiss, TAMURA, Kent, Angel Raposo, blink-dev, Takashi Toyoshima

Daniel Bratell

unread,
Aug 31, 2022, 5:20:30 PM8/31/22
to Yoav Weiss, TAMURA, Kent, Angel Raposo, blink-dev, Takashi Toyoshima

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

Takashi Toyoshima

unread,
Sep 1, 2022, 2:24:28 AM9/1/22
to Daniel Bratell, Yoav Weiss, TAMURA, Kent, Angel Raposo, blink-dev
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.

Thanks!

Yoav Weiss

unread,
Sep 1, 2022, 2:49:24 AM9/1/22
to Takashi Toyoshima, Simeon Vincent, Daniel Bratell, TAMURA, Kent, Angel Raposo, blink-dev
On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima <toyo...@chromium.org> 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

Dave Tapuska

unread,
Sep 1, 2022, 10:23:10 AM9/1/22
to Yoav Weiss, Takashi Toyoshima, Simeon Vincent, Daniel Bratell, TAMURA, Kent, Angel Raposo, blink-dev, Devlin Cronin, Simeon Vincent
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.

Yoav Weiss

unread,
Sep 5, 2022, 5:33:54 AM9/5/22
to Dave Tapuska, Takashi Toyoshima, Simeon Vincent, Daniel Bratell, TAMURA, Kent, Angel Raposo, blink-dev, Devlin Cronin, Simeon Vincent
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?

Dave Tapuska

unread,
Sep 6, 2022, 9:52:56 AM9/6/22
to Yoav Weiss, Takashi Toyoshima, Simeon Vincent, Daniel Bratell, TAMURA, Kent, Angel Raposo, blink-dev, Devlin Cronin, Simeon Vincent
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.

Yoav Weiss

unread,
Sep 6, 2022, 9:58:05 AM9/6/22
to Dave Tapuska, Takashi Toyoshima, Simeon Vincent, Daniel Bratell, TAMURA, Kent, Angel Raposo, blink-dev, Devlin Cronin, Simeon Vincent
SG! My LGTM still stands :)
Reply all
Reply to author
Forward
0 new messages