On Fri, Apr 22, 2022 at 7:27 PM 'Angel Raposo' via blink-dev < [email protected]> wrote:
> 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 > https://github.com/WICG/nav-speculation/issues/160 seems like something we'd want to settle before shipping? Any other open issues that may impact the compat or interop risk here? Also, is the opt-in <https://github.com/WICG/nav-speculation/blob/main/opt-in.md> part of this intent? > > 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. > It'd be great if you could share more details about the origin trial, feedback we received and if possible, user benefits from OT participants trying this out. > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA9vRHxK26yKNbkcL3uWGcGHGDEZpQBSBy3Avbp%2BqAV4iTpaOg%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVva-gDQ2F6PM1D9mh-1bXkSVi3EqmDryy_V7uK%3DDeiJg%40mail.gmail.com.
