Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Hiroki Nakagawa]

Contact emails

nhi...@chromium.org, navigat...@chromium.org

Explainer

This feature: https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md

This trial: https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.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 loads a web page before it is needed, so that when the actual navigation to that page occurs, it can be shown instantly.

This experiment is for the specific case of same-origin prerendering triggered by the Speculation Rules API. An earlier, related experiment supported prefetching using this API. This is a separate experiment that requires its own origin trial token.

This experiment has some limitations. See the explainer for details.

Blink component

Internals>Preload>Prerender

TAG review

https://github.com/w3ctag/design-reviews/issues/667

TAG review status

Pending

Risks

Interoperability and Compatibility

Interoperability risk: 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.

Compatibility risk: Some use cases will need to know whether a page is being prerendered. Ads and analytics are likely examples of this. This feature exposes `document.prerendering` to detect prerendering, but there is a risk of sites that would benefit from using the API, not using it. We believe that this risk is tractable because prerendering has existed in Chrome in the recent past and currently exists in some other browsers. We also intend to add a header to network requests like `Purpose: prefetch` so that origin servers can identify requests for prerendered pages.

Gecko: No signal

WebKit: No signals, while Safari appears to have some form of prerendering already.

Web developers: No signals

Other signals: No signals

Ergonomics

This feature is triggered by the Speculation Rules API: https://chromestatus.com/feature/5740655424831488

Activation

Developers can use the Speculation Rules API to use the feature. The feature should just work for most existing pages. Developers should be aware of restrictions on prerendering content (they cannot play audio or perform other disruptive behavior, etc). This feature would benefit from good documentation.

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.

Goals for experimentation

To evaluate how the prerendering feature works on real sites before shipping it by default. This is a large feature and it's risky to ship without trying it first on real sites. We will be evaluating performance, stability, and correctness, and any other feedback the sites have when they use this feature.

Reason this experiment is being extended

The sites participating in this trial need more time to set up their services with the feature. We would like to collect more data from them for evaluating the feature.

Ongoing technical constraints

None

Debuggability

Currently DevTools does not work for prerendered pages. On activation, DevTools must be closed and reopened in order to inspect the page. We have plans to add DevTools support for prerendering. A meta bug for this work is at https://crbug.com/1217029.

As a very small support, prerendered pages are visible in chrome://process-internals. Also final results of prerendering are shown in chrome://histograms.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

This feature is only supported on Android at first. As the feature is a cross-cutting one, where almost all of Chrome's features must be potentially taught about prerendered pages, we are starting with a single platform and expanding later.

Is this feature fully tested by web-platform-tests?

Partially tested. We’re now upstreaming wpt_internals/ tests (document).

Flag name

Prerender2

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1126305

Launch bug

https://crbug.com/1167987

Estimated milestones

Previous experiment timeline: M94 to M98

Requested extension timeline: M99 to M103

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5355965538893824

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

What are the milestones for the continued experimentation?

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABj5diM0QEn5hBg1r80PWFw6qpXhCVmC05p0qh5KT5h9xKh19Q%40mail.gmail.com.

[Hiroki Nakagawa]

Hi Yoav,

The requesting milestones are from M99 to M103 (The previous milestones were from M94 to M98).

[Mike West]

Was any site able to try this out during the initial experimental period? Or is this really just a delayed start to the trial? I think it's reasonable to extend out 4 additional milestones, but if you really didn't see any usage at all, it might be reasonable to consider this as a new starting date as opposed to an extension. 

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABj5diNgh5%3DhSt_%3DAd1fKAC8ot8nqzpghFg_S58oih8mJDzhmQ%40mail.gmail.com.

[Hiroki Nakagawa]

Hi Mike,

We are aware that some sites are now running their experiments. In addition to that, another site has been preparing for the experiment. We are now actively helping them.

[Mike West]

In that case, do you need 4 more milestones? We've set a cap of 9 milestones for OTs generally; this would bring y'all to 8. Do you need that entire period if folks are actively experimenting now? If folks started testing in 97, extending to 100 would give them 4 milestones to work with, which might be enough?

-mike

[Hiroki Nakagawa]

Good point. I think actually they don't need 4 more milestones for starting the experiment, so extending to 100 should be enough. Let me change the requesting milestones as follows:

Estimated milestones

Previous experiment timeline: M94 to M98

Requested extension timeline: M99 to M100

 

[Mike West]

LGTM. Good luck with the extension!

-mike

--

-mike