Contact emails [email protected] [email protected], [email protected], [email protected], [email protected]
Explainer This feature: https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md Larger project: 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/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing 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 tell the user agents 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. We would like to ship same-origin speculation rules prerendering. With this feature, Chrome will start prerendering high-confidence URL suggestions provided by the page using speculation rules. During the prerendering process, a page will process and construct the full DOM tree, including the execution of scripts (this differs from the prefetching resources using No-state Prefetch <https://developers.google.com/web/updates/2018/07/nostate-prefetch>) 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). The website can know that it is being prerendered (document.prerendering) and when it was activated (prerenderingchange event, performance.activationStart timing). These APIs have already been approved by the previous intent-to-ship for Omnibox prerendering <https://docs.google.com/document/d/1GcB_oII6-3s24M_3ebcp5bzAtNNY5i_wh1c0jgJvv8k/edit> . Note that we are not shipping cross-origin speculation rules, which allows a web page to prerender another page under a different domain (external site). 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> . 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 Closed Risks Interoperability and Compatibility Compatibility 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. To solve this challenge, this feature exposes `document.prerendering` which indicates if the page is prerendered or not. We understand that there’s always a risk of sites, that would benefit from using this API, not actually using it. We believe that this risk is tractable because: (1) triggering a prerender isn’t an entirely new behavior. E.g. Chrome used to have a prerendering feature a long while ago <https://blog.chromium.org/2011/06/prerendering-in-chrome.html> triggered by URLs entered in the navigation bar (2) Similar behaviors are already present in other browsers, e.g. “Preload Top Hit” feature in Safari To give more flexibility to web authors (site owners) who want to implement speculation rules, we are already including a header to network requests as `Purpose: prefetch` so that origin servers can identify requests for prerendered pages and decide how to handle them. A new header will be included to provide a CORS safelist alternative using `Sec-purpose: prefetch;prerender` https://fetch.spec.whatwg.org/#cors-safelisted-request-header https://chromestatus.com/feature/6247959677108224 There’s also a future risk of the speculation rules specification changing <https://github.com/WICG/nav-speculation/blob/main/triggers.md#rules>: including new rules, modifying previous ones, etc. We do not expect to make backward-incompatible changes to the speculation rules format, but if we did, the user agent wouldn’t be able to understand the rules (which would define them as null), opting out of the prerender which wouldn’t cause any visible effect (apart from a slower loading time for the next navigated page as it won’t be prerendered). We are working closely on the tracker https://github.com/WICG/nav-speculation/issues which contains currently 8 non-blocking open discussions related with compatibility (1 of them covering cross-origin which we are not shipping with this I2S) Interoperability We believe that some browsers already have prerendering implementations which are not well-specified and may differ from each other. 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. The danger here is that different browsers have different ways to trigger a prerendered page, and prerendered pages behave differently in different browsers. Prerendering is a web-visible behavior, since it involves fetching the page and executing its scripts. Prerendering can depend on UA-specific heuristics. For example, the browser might decide to act on a hint to prerender based on the system load, and the presence of other prerenders. We do not intend to codify heuristics in the specification. A conforming browser might simply ignore all hints to prerender a page. Discussions around speculation rules and the broader prerender feature has already been initiated with different players: 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>; 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 developers: We’ve already received positive feedback from initial web developers testing the feature. See https://github.com/WICG/proposals/issues/2 for positive sentiments on speculation rules triggered by different partners who are willing to implement the feature into their sites. Other signals: There’s 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 IT admins can disable Prerendering via the existing group policy "NetworkPredictionOptions" This feature will be used in combination with the APIs which already shipped as part of omnibox prerendering: document.prerendering, prerenderingchange event, and performanceEntry.activationStart timing. Activation Developer needs to opt-in by defining the speculation rules on the page. Please notice that this doesn’t ensure the prerender of the next navigation as speculation rules are only used as suggestions to improve the heuristics of the user agent choosing which page to prerender. As hints, speculation rules may be followed by the browser (prerendering the page) or ignored completely (e.g. lowend device without resources to prerender the page). Security This feature is the first use of the Multiple-Page Architecture, which is a significant change to Chromium's internals. Both MPArch and this feature in particular underwent significant security review. See the design doc for more details. >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 This feature 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>]. The current MVP is to reveal the prerendered page status in the panel so web developers can know if they finished successfully or not. We also have a long term plan <https://docs.google.com/document/d/1nK1TqDMeE0dgl4TGk9Ne4vzKzgv7nkfgmAVbvR6TtM0/edit> to show different debugging status messages in DevTools but there's no specific messages currently discussed that are focused only on speculation rules, only the "generic" ones at prerender feature level. Your thoughts are welcome if specific debugging logs regarding speculation rules would be required. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/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 (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.) Flag name Prerender2 Requires code in //chrome? False Tracking bug https://crbug.com/1295143 Launch bug https://crbug.com/1316557 Sample links For a demo of prerendering generally, and its effect on websites, https://prerender2-specrules.glitch.me/ shows it triggered by speculation rules. Estimated milestones OriginTrial android last 102 OriginTrial android first 94 DevTrial on android 94 Anticipated spec changes There are currently 8 open discussions <https://github.com/WICG/nav-speculation/issues?q=is%3Aissue+is%3Aopen+label%3A%22prerendering%22+label%3A%22affects-compat%22+> which could potentially modify the API in the future. Having said that, half of them were opened in 2020/2021 which means they have been in discussions for a long term and we don’t expect immediate changes required in the short term. We have reviewed all the current pending discussions <https://docs.google.com/document/d/1eFY7RMoeG7Mdhon9yLs6hKSfi6DYrASBPM-31hWXPDg/edit> and we believe they won’t cause compatibility issues as most of them will be resolved with the initial launch. We’ll keep working on the tracker and updating our roadmap doc <https://docs.google.com/document/d/1GenZDPbTzRyp038gh8A_ylIoVTfKt40MFyg7Ek_7L58/edit?usp=sharing> if we detect any changes. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5355965538893824 Links to previous Intent discussions Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/3JwGNnqH3QI/m/Ey103Q-yAQAJ Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/Kpp6uJJRrqI/m/GTo_aF0qEQAJ This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- Angel Raposo | TPM Prerender (20% role) | [email protected] | 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA9vRHxK26yKNbkcL3uWGcGHGDEZpQBSBy3Avbp%2BqAV4iTpaOg%40mail.gmail.com.
