Intent to Ship: Omnibox Prerendering
Kouhei Ueno
Contact emails
loadi...@chromium.org, noam.j.r...@gmail.com
Component
Internals>Preload>Prerender
Explainer
https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md
Spec
https://wicg.github.io/nav-speculation/prerendering.html
Discussion about upstreaming into HTML and elsewhere: whatwg/html#7533
The corresponding TAG review is w3ctag/design-reviews#667. (That review was for speculation-rules triggered prerendering, which has a superset of the considerations for omnibox-triggered prerendering.)
Summary
We would like to ship omnibox (i.e., URL bar) prerendering. With this feature, Chrome will start prerendering the high-confidence omnibox autocomplete suggestions. Chrome is currently prefetching resources for high-confidence suggestions using No-state Prefetch, but with this feature we will be further processing the webpage, including the DOM tree construction and script execution.
While this is a user agent feature, this is an observable change to the prerendered websites. This prerendering affects how the prerendered pages are processed. The website gets loaded before the navigation is committed, and the side-effects are delayed until activation (the actual navigation to the website was committed). We also would like to add a simple APIs (document.prerendering) to directly let the website know that it is being prerendered and when it was activated (prerenderingchange event, performance.activationStart timing).
Note that we are not shipping speculation rules triggered prerender2 (I2E extension) with this I2S, which allows web pages to prerender other web pages. We will come back (hopefully soon) with a separate I2S. For details about our web exposed changes shipping plan, please consult this doc: Interoperability Roadmap for Shipping Prerender2 Incrementally.
Link to “Intent to Prototype” blink-dev discussion
We don’t have a corresponding “Intent to Prototype”. This was implemented as a variation of other prerender2 triggers (Speculation rules I2E).
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
We plan to roll out omnibox-triggered prerendering from Android platforms, where we already have the MPArch coverage. Eventually, we will enable this on all platforms.
Demo link
For a demo of prerendering generally, and its effect on websites, https://prerender2-specrules.glitch.me/ shows it triggered by speculation rules (which are not part of this Intent).
Instruction: Demonstration of URL-bar-triggered Omnibox prerendering
Demo page: https://omnibox-prerender.glitch.me/
Debuggability
We are actively talking to the devtools team about adding general Prerender support to it [metabug]. The MVP is to expose the prerendered page status in the panel so web developers can know if they finished successfully, or they couldn’t proceed due to its feature restrictions.
We currently don’t have a plan to add devtools support specifically for the omnibox prerender trigger (your thoughts are welcome!).
Measurement
We have implemented UseCounters [cs] to monitor the usage of the properties added by this I2S.
Risks
Compatibility
There is a non-zero chance that the behavior of the prerendered sites can be broken. The prerendered pages are loaded and rendered before user actually navigates to the websites, so there will be some number of prerenders that are false positives, which end up not being used. The websites will observe the requests, and can run some JavaScript, which can have side effects.
That said, triggering a prerender from the address bar isn’t an entirely new behavior. Chrome used to have a prerendering feature a long while ago. A similar behavior is also present in other browsers (e.g. “Preload Top Hit” feature in Safari).
For omnibox prerendering, we minimize this by having a high confidence threshold value: We only issue prerendering for omnibox input that we are confident that the user will navigate to the page.
Interoperability
Gecko: 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. We have 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 / Framework developers: N/A - The omnibox prerendering (scope of this I2S) is triggered without web author opt-in. See https://github.com/WICG/proposals/issues/2 for positive sentiments on speculationrules triggered prerendering.
Ergonomics
These features will be used by speculation rules-triggered prerender as well.
Activation
Developer activation is not needed. Omnibox prerendering is triggered by Chrome.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
It is not currently possible to trigger the omnibox prerendering path specifically from web platform tests. We have filed web-platform-tests/wpt#32726 to discuss making it possible and will be working on driving that forward in collaboration with other browsers.
In the meantime, we have written a lot of web platform tests using speculation rules as the trigger. These exercise many of the same code paths and can be adapted once an appropriate API is available for testing URL-bar-triggered prerendering:
https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned
(Currently Chromium tests this using VirtualTestSuites [cs] instead of EnableExperimentalWebPlatformFeatures, so the tests are not green on wpt.fyi.)
Entry on the feature dashboard
Olli Pettay
> Contact emails
>
> loadi...@chromium.org <mailto:loadi...@chromium.org>, noam.j.r...@gmail.com <mailto:noam.j.r...@gmail.com>
>
> Component
>
> Internals>Preload>Prerender
>
>
> Explainer
>
> https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md
> <https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md>
>
>
> Spec
>
> https://wicg.github.io/nav-speculation/prerendering.html
> <https://wicg.github.io/nav-speculation/prerendering.html>Discussion about upstreaming into HTML and elsewhere: whatwg/html#7533
>
>
> The corresponding TAG review is w3ctag/design-reviews#667 <https://github.com/w3ctag/design-reviews/issues/667>. (That review was for
>
>
> Summary
>
> We would like to ship omnibox (i.e., URL bar) prerendering. With this feature, Chrome will start prerendering the high-confidence omnibox autocomplete
> suggestions. Chrome is currently prefetching resources for high-confidence suggestions using No-state Prefetch
>
>
> While this is a user agent feature, this is an observable change to the prerendered websites. This prerendering affects how the prerendered pages are
> processed. The website gets loaded before the navigation is committed, and the side-effects are delayed until activation (the actual navigation to the
> website was committed). We also would like to add a simple APIs (document.prerendering) to directly let the website know that it is being prerendered
> and when it was activated (prerenderingchange event, performance.activationStart timing).
>
>
> Note that we are not shipping speculation rules triggered prerender2 (I2E extension
>
> Link to “Intent to Prototype” blink-dev discussion
>
> We don’t have a corresponding “Intent to Prototype”. This was implemented as a variation of other prerender2 triggers (Speculation rules I2E
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> We plan to roll out omnibox-triggered prerendering from Android platforms, where we already have the MPArch coverage. Eventually, we will enable this
> on all platforms.
>
>
> Demo link
>
> For a demo of prerendering generally, and its effect on websites, https://prerender2-specrules.glitch.me/
> <https://prerender2-specrules.glitch.me/>shows it triggered by speculation rules (which are not part of this Intent).
>
>
> Instruction: Demonstration of URL-bar-triggered Omnibox prerendering
>
> Demo page: https://omnibox-prerender.glitch.me/ <https://omnibox-prerender.glitch.me/>
>
> Debuggability
>
> We are actively talking to the devtools team about adding general Prerender support to it [metabug
>
>
> We currently don’t have a plan to add devtools support specifically for the omnibox prerender trigger (your thoughts are welcome!).
>
>
> Measurement
>
> We have implemented UseCounters [cs
>
>
> Risks
>
> Compatibility
>
> There is a non-zero chance that the behavior of the prerendered sites can be broken. The prerendered pages are loaded and rendered before user
> actually navigates to the websites, so there will be some number of prerenders that are false positives, which end up not being used. The websites
> will observe the requests, and can run some JavaScript, which can have side effects.
>
>
> That said, triggering a prerender from the address bar isn’t an entirely new behavior. Chrome used to have a prerendering feature a long while ago
>
> For omnibox prerendering, we minimize this by having a high confidence threshold value: We only issue prerendering for omnibox input that we are
> confident that the user will navigate to the page.
>
>
> Interoperability
>
> Gecko: Some informal positive discussion with Gecko engineers on the HTML Standard issue tracker
> <https://github.com/whatwg/html/issues/7488#issuecomment-1029510684>;
FWIW, that positive signal was to have a spec for this. The spec proposal has not been reviewed and obviously the spec is still missing quite a bit.
It is a bit surprising to ship anything when there is no clear spec how it all should behave.
(It is for example quite surprising that one could use BroadcastChannel with a prerendered page. And [DelayWhilePrerendering] also has very surprising
behavior)
-Olli
formal positions request here:
> https://github.com/mozilla/standards-positions/issues/613 <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. We have 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
> <https://lists.webkit.org/pipermail/webkit-dev/2022-February/032113.html>
>
>
> Web / Framework developers:N/A - The omnibox prerendering (scope of this I2S) is triggered without web author opt-in. See
>
> Ergonomics
>
> These features will be used by speculation rules-triggered prerender as well.
>
>
> Activation
>
> Developer activation is not needed. Omnibox prerendering is triggered by Chrome.
>
>
> to test suite results from wpt.fyi <https://wpt.fyi>.
>
> In the meantime, we have written a lot of web platform tests using speculation rules as the trigger. These exercise many of the same code paths and
> can be adapted once an appropriate API is available for testing URL-bar-triggered prerendering:
>
>
> https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned
> <https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned>
>
> (Currently Chromium tests this using VirtualTestSuites [cs
>
>
>
> https://chromestatus.com/feature/5710069172797440 <https://chromestatus.com/feature/5710069172797440>
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLVDPme9kEnB6NdeDHO6krO77D-GN8MMKzYAv8oLCyAtwA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLVDPme9kEnB6NdeDHO6krO77D-GN8MMKzYAv8oLCyAtwA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Olli Pettay
--
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/CAPVAxLVDPme9kEnB6NdeDHO6krO77D-GN8MMKzYAv8oLCyAtwA%40mail.gmail.com.
--
Domenic Denicola
FWIW, the comment in the HTML spec triage was positive feedback to have a spec for this.The current spec proposal clearly is missing still quite a few cases (is the idea really that one can use BroadcastChannel with prerendered page? and the webidl annotation behaves rather oddly)So it is surprising to see this shipping already now.
- The careful auditing of all APIs to see how they should behave in prerendering.
- Introducing a well-specified Sec-Purpose: prefetch header, instead of the unspecified X-moz: prefetch or X-Purpose: preview headers.
- Considering how to handle edge cases such as redirects, 204s, Content-Disposition: attachment, or pages that do client-side navigation while being prerendered.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2B07GXTt370Y9GVCMn160%2BbuxM_9MizBjbhjMrOsUXQixjcSQ%40mail.gmail.com.
Yoav Weiss
On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <olli....@gmail.com> wrote:FWIW, the comment in the HTML spec triage was positive feedback to have a spec for this.The current spec proposal clearly is missing still quite a few cases (is the idea really that one can use BroadcastChannel with prerendered page? and the webidl annotation behaves rather oddly)So it is surprising to see this shipping already now.Thanks for chiming in, Olli!I have a rather different take. As the team's spec mentor, I'm impressed with the spec work the team has done, on taking what most other browsers have treated as a not-to-be-specified user agent UI feature, and turning it into something much more rigorous and developer-friendly. For example:
- The careful auditing of all APIs to see how they should behave in prerendering.
- Introducing a well-specified Sec-Purpose: prefetch header, instead of the unspecified X-moz: prefetch or X-Purpose: preview headers.
- Considering how to handle edge cases such as redirects, 204s, Content-Disposition: attachment, or pages that do client-side navigation while being prerendered.
I think there's definitely still work to be done, as we try to move from the current world where every browser does something different into one that's more fully predictable for web developers. But I think this is similar to other features, like bfcache, where for many years the heuristics and rules used were unspecified (e.g. Cache-Control, unload handlers, BroadcastChannel), and then we've started a slow convergence process as browsers start to care more about interoperability.We can definitely tweak things, like Olli's example of BroadcastChannel, over time and as other browsers indicate willingness to converge.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9wncTSBUmyAmF7L3fpB2HAzxTLSp-O6Dh04NKLpsE0Ag%40mail.gmail.com.
Noam Rosenthal
I agree with Domenic that it's great to see this kind of feature, that was traditionally unspecified, getting some clearer developer visibility and a spec. While there may still be missing pieces, this seems like a good start. I'm looking forward to further spec discussions that would hopefully lead to convergence and better interop.On Fri, Feb 11, 2022 at 11:39 PM Domenic Denicola <dom...@chromium.org> wrote:On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <olli....@gmail.com> wrote:FWIW, the comment in the HTML spec triage was positive feedback to have a spec for this.The current spec proposal clearly is missing still quite a few cases (is the idea really that one can use BroadcastChannel with prerendered page? and the webidl annotation behaves rather oddly)So it is surprising to see this shipping already now.Thanks for chiming in, Olli!I have a rather different take. As the team's spec mentor, I'm impressed with the spec work the team has done, on taking what most other browsers have treated as a not-to-be-specified user agent UI feature, and turning it into something much more rigorous and developer-friendly. For example:
- The careful auditing of all APIs to see how they should behave in prerendering.
- Introducing a well-specified Sec-Purpose: prefetch header, instead of the unspecified X-moz: prefetch or X-Purpose: preview headers.
- Considering how to handle edge cases such as redirects, 204s, Content-Disposition: attachment, or pages that do client-side navigation while being prerendered.
I think there's definitely still work to be done, as we try to move from the current world where every browser does something different into one that's more fully predictable for web developers. But I think this is similar to other features, like bfcache, where for many years the heuristics and rules used were unspecified (e.g. Cache-Control, unload handlers, BroadcastChannel), and then we've started a slow convergence process as browsers start to care more about interoperability.We can definitely tweak things, like Olli's example of BroadcastChannel, over time and as other browsers indicate willingness to converge.One potential problem with that approach is that sites may grow to rely on that existence of e.g. BroadcastChannel and may break when we take that away.I don't think that's a risk for the current I2S, as developers are not aware that the page is being prerendered outside of the page itself, so the chances of them trying to communicate with it are low.But that can be a risk for the speculation rules based API, which would be good to mitigate.
Domenic Denicola
Noam Rosenthal
Alex Russell
Noam Rosenthal
hey folks,Looking at this in API OWNERS this morning, I wasn't able to see an obvious developer opt-out. The spec and explainer talk about letting the server opt-out, but it appears that the primary way that would happen is aborting a response. This is a potentially expensive and surprising for servers. Has there been any thought about supporting a response header that would allow a response document to opt into, e.g., only prefetch behavior but not prerendering?
Noam Rosenthal
Maybe a weird side-effect, but think of web.whatsapp.com: You have the tab open already, open a new tab, enter web.whatsapp.com, so you'll get an action item in the omnibox to switch to the already open tab - but with prerendering this leads to web.whatsapp.com showing you've opened the site in a new tab (even though you didn't - it got prerendered), making the "switch to already open tab" suggestion useless.Is this something site maintainers will have to fix or on the chromium side? (Prerendering interaction with already open tabs)
Jacob G
Kouhei Ueno
Hi,
While we are discussing, we would like to continue the incremental roll out of the feature to non-Stable channels. As of now, we are testing out the feature on 60% of Dev/Canary channels, and 60% of Beta channels. The rollout is limited to Android Chrome (limitation of the current implementation).
We expect the rollout to affect at most a tiny fraction of the Internet traffic generated by Chrome. The population of the Beta/Dev/Canary channels combined is less than a few percent of Stable population, and the navigation subject to prerendering on Prerendering-enabled Chrome is less than a percent.
Let me try to summarize the state of the discussion here (including the questions we’ve received out-of-band).
Q: Do you offer an opt-out mechanism to developers?
A: Yes. The opt-out mechanism is now covered in this section of the explainer.
Q: What can we do about prerender breaking “switch to already open tab” on WhatsApp?
A: We are updating the BroadcastChannel interaction [spec, implementation]. In addition, we are delaying ServiceWorker#postMessage too, to address a similar issue [crbug]
Q: Can Enterprise disable the feature by a policy?
A: Yes - we respect the existing NetworkPredictionOptions group policy.
Q: What is the status of https://github.com/whatwg/html/issues/7533?
A: The issue is a general “call for feedback” issue. Individual issues are tracked on wicg/nav-speculation issue tracker.
Q: Since prerendering risks breaking certain websites, what are the mitigation measures planned?
A:
Prerendering is not entirely new. It used to be available in Chrome M13 until M63 and has been available in many other browsers such as: Safari since at least 2014, Opera from 2017, and more recently launched in Edge. We assume that the risk of breakage is relatively low given these pre-existing conditions. That said, we will remain prudent while relaunching this feature.
Take a slow and transparent approach to our rollout:
We’ll be careful around ramping up the experiment group population that we will be monitoring the metrics and user reports closely.
We’ll also be transparent about the rollout config on this blink-dev thread.
We’ll be keeping in touch with various partners to ensure that everything is good on their end.
Before going to Stable, we’ll publish a heads-up article on one of our blogs with the following content:
What’s being experimented with (e.g. prerendering on Chrome for Android from the Omnibox)
Things to know about this feature (e.g. how it triggers, how it manifests itself, how it works)
How to do hands-on testing, what to do if something breaks (e.g. opt-out), how to share feedback to help us get this right.
Being as conservative as other prerendering browsers (such as Edge and Safari), as well as having the following extra mitigations:
Allowing developers to opt-outs.
Disabling prerendering on features known to be problematic or surprising (e.g. BroadcastChannel, Media, and Sensor APIs)
--
Kouhei, on behalf of the Prerender2 team
--
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/CAGttnEWV-HxsXds4W-ZcH_Aro4uvG1%2BjLmkM9io6xApi8LpjGA%40mail.gmail.com.
Alex Russell
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Noam Rosenthal
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Mike West
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7bb9cb46-420e-4111-9be5-93eae359f606n%40chromium.org.
Mike Taylor
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dd1fiaO0ner0xAKNub%2BaZYr00OWRXACHM3xygyVMKAKLw%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b8906a1b-4dcb-8654-6c09-5d80da3516a8%40chromium.org.
Joe Medley
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWgLcLeK9dJ9%2Bp2LTg--6AMXsV%2BPyEkHHa9v2JJLwxk1Q%40mail.gmail.com.
Angel Raposo
Hi,
Following the previous discussion on this thread, I wanted to share a couple of updates:
We have updated the web.dev article with the current state and some useful information for web developers as requested. This includes Omnibox prerendering and the new HTTP header `Sec-Purpose: prefetch; prerender`
We are also ramping up the experiment gradually, at a very low rate, so we can monitor the situation and we haven’t detected any issues so far. We’ll keep a close eye as we ramp up the roll out
Thanks,
Angel.