Intent to Ship: Prerender2 for Desktop
Angel Raposo
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
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
Launch bug
Estimated milestones
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.
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
--
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
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
- 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
Angel Raposo
Joe Medley
Takashi Toyoshima
Thank you for your feedback.
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.
I'm happy to hear more feedback from other blink-dev people and API owners!
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG_mChsefDmx88PxMCy_gyCcHm%2BPzKXDy51VOe5HvMczag%40mail.gmail.com.
Software Engineer, Google
TAMURA, Kent
--
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.
Software Engineer, Google
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGfDVX7aWqdHt9skKSsnZcvvGHa9F6ZWshvGnVDJ24EAQ%40mail.gmail.com.
Daniel Bratell
LGTM3
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUr2bVZHm-GCy0Eh18rXY4HcZ0yv2EEsT_S1o7ORm%2BCtg%40mail.gmail.com.
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
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e6aff414-3ed1-2714-7d59-7dcfb7582391%40gmail.com.
Takashi Toyoshima
https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
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.
Yoav Weiss
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=sharingThis 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.
Dave Tapuska
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWo1dYYKB-HfEi19BW0isGziXbd57GpMLp6pT9rPSH1rA%40mail.gmail.com.