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 <https://groups.google.com/a/chromium.org/g/blink-dev/c/EdW7O8yG7Jc/m/ypgp7pIjBAAJ?utm_medium=email&utm_source=footer> and I2S for Omnibox triggered Prerender2 <https://groups.google.com/a/chromium.org/g/blink-dev/c/ogegRwcRlcs/m/Aso1a0UcBgAJ>), 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 <https://developers.google.com/web/updates/2018/07/nostate-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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload%3EPrerender> 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 <https://github.com/whatwg/html/issues/7533#issuecomment-1022051187> and in the HTML triage call <https://github.com/whatwg/html/issues/7488#issuecomment-1029510684>; 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 <https://chromestatus.com/feature/5740655424831488> 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 <https://bugs.chromium.org/p/chromium/issues/detail?id=1217029>] 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 <https://docs.google.com/document/d/1YEAfcuBjwlJn7GG6po8AFteObG15r9ro63fdFfcMvoI/edit>] 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <https://docs.google.com/document/d/1eFY7RMoeG7Mdhon9yLs6hKSfi6DYrASBPM-31hWXPDg/edit> 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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFWCB1n7W-gfr9b8FTNtB1bNDnYJ_=ksfwiy+tfgyqjuxe5...@mail.gmail.com> This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- Angel Raposo | Engagement Manager | angelrap...@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. もし、このメッセージが誤って貴殿に送信されたと思われる場合には、機密情報を含んでいる可能性もありますので、どなたにも転送せず、添付ファイルも含めて削除していただくとともに、発信者にその旨をお伝えいただきますようお願いいたします。 -- 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/CAA9vRHy7_o1ftcTz2-pC5rOPtZRhas5PGLw4HJ--v%2Bewkvcoww%40mail.gmail.com.
