LGTM1 Thanks for the extra details. These results look amazing, so in my mind they significantly outweigh the risk of going first here.
On Thursday, May 12, 2022 at 4:12:19 AM UTC+2 Hiroki Nakagawa wrote: > Let me share more details of the feedback. > > We worked directly with 11 external partners; 8 of them valued the > opportunity offered by Prerendering. > > - Origin Trial results: One of the external partners, Ameba News ( > https://news.ameba.jp/) has tested out same-origin prerendering via > the Origin Trial during April 11 - 17 (1 week testing / around selected > navigations / 2-3% of the traffic). While the site was already meeting CWV > and good LCP, by adopting prerendering, the median LCP improved 2.7x > (827ms > to 302ms) and more importantly the P95 improved by 1.6 seconds [2843ms to > 1195ms] (i.e. Prerendered pages have more consistency in the performance). > - Key challenges: > - All participants identified "knowing what is safe to prerender / > adapting a page to be safe" as a key challenge. We are exploring > follow-ups > to lower the bar. > - DevTools support. We are following up with the devtools team. > - 3P RUM tools to incorporate `activationStart` to correctly > measure FCP / LCP. We will be guiding the RUMs for required changes. > - CrUX to incorporate the prerendering impact. We are following up > with the CrUX team. > > In addition, we worked with one internal partner who got great results > (i.e. the 45% number shared earlier). > > Finally, we received the following feedback from 6 OT participants: > > - Difficulty: moderately easy (3), neither easy nor difficult (2), > Slightly difficult (1) > - Keep using: extremely likely (2), moderately likely (3), can't say > which way (1) > - Alternatives: none (2), fallback to prefetch (2) > > > Thanks, > Hiroki > > On Tue, May 10, 2022 at 10:42 PM Hiroki Nakagawa <[email protected]> > wrote: > >> Hi Yoav, thanks for your comments! >> >> On Tue, May 10, 2022 at 9:48 PM Yoav Weiss <[email protected]> >> wrote: >> >>> >>> >>> 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? >>> >> >> I wonder if the issue is not blocking this I2S. Currently we support only >> the basic syntax like this >> <https://github.com/web-platform-tests/wpt/blob/88cd60961f5cd877cf5083a8874a233f69ae72a2/speculation-rules/prerender/resources/utils.js#L19-L22>, >> >> and such advanced syntax is out of the scope. I think we can incrementally >> support them later without breaking the compatibility. >> >> >>> Any other open issues that may impact the compat or interop risk here? >>> >> >> We audited open issues that could potentially affect compat or interop >> and concluded they have no risks. This document >> <https://docs.google.com/document/d/1eFY7RMoeG7Mdhon9yLs6hKSfi6DYrASBPM-31hWXPDg/edit?usp=sharing> >> >> summarizes the results. >> >> >>> Also, is the opt-in >>> <https://github.com/WICG/nav-speculation/blob/main/opt-in.md> part of >>> this intent? >>> >> >> This I2S doesn't cover the opt-in mechanism. >> >> >>> 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. >>> >> >> We had experiments with several internal/external partners. One of the >> experiments showed that the feature can reduce the latency on their service >> by 45%. Other experiments also showed promising impacts on the CWV metrics. >> According to feedback from the partners, the lack of DevTools support for >> prerendering was challenging. As the "Debuggability" section on this I2S >> mentions, we've actively been developing the DevTools support, so the >> situation should be mitigated soon. Overall, they were supportive of the >> feature and interested in using it on production. >> >> >>> >>>> 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/95894ef5-83cb-4906-a8c8-fad0b0e71f4fn%40chromium.org.
