On 2/11/22 07:20, Kouhei Ueno wrote:
Contact emails
loading-...@chromium.org <mailto:loading-...@chromium.org>,
noam.j.rosent...@gmail.com <mailto:noam.j.rosent...@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
<https://github.com/whatwg/html/issues/7533>
The corresponding TAG review is w3ctag/design-reviews#667 <https://github.com/w3ctag/design-reviews/issues/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
<https://developers.google.com/web/updates/2018/07/nostate-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
<https://groups.google.com/a/chromium.org/g/blink-dev/c/tcbtZoQIlvI/m/K26gVfbUAQAJ>) 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 <https://docs.google.com/document/d/1GenZDPbTzRyp038gh8A_ylIoVTfKt40MFyg7Ek_7L58/edit>.
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
<https://groups.google.com/a/chromium.org/g/blink-dev/c/tcbtZoQIlvI/m/K26gVfbUAQAJ>).
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
<https://docs.google.com/document/d/1sUbxYSu1o5G76tA4UW_xxgcfcOn8j6NlJc_Go0Gwb_Q/edit?usp=sharing>
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
<https://bugs.chromium.org/p/chromium/issues/detail?id=1217029>]. 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
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/public/mojom/web_feature/web_feature.mojom;l=3482>] 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
<https://blog.chromium.org/2011/06/prerendering-in-chrome.html>. 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
<https://github.com/whatwg/html/issues/7533#issuecomment-1022051187>and in the HTML triage call
<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
https://github.com/WICG/proposals/issues/2 <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 <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? Link
to test suite results from wpt.fyi <https://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
<https://github.com/web-platform-tests/wpt/issues/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
<https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned>
(Currently Chromium tests this using VirtualTestSuites [cs
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/virtual/prerender/README.md>] instead of
EnableExperimentalWebPlatformFeatures, so the tests are not green on wpt.fyi.)
Entry on the feature dashboard <http://www.chromestatus.com/>
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+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@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>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/10449294-c515-ebe5-4f37-98490197df4f%40gmail.com.
