Intent to Experiment: Same-origin prerendering triggered by the speculation rules API
Matt Falkenhagen
Contact emails
fal...@chromium.org, navigat...@chromium.org
Explainer
This feature:
https://github.com/jeremyroman/alternate-loading-modes/blob/main/same-origin-explainer.md
Larger project:
https://github.com/jeremyroman/alternate-loading-modes/blob/main/README.md
Specification
https://jeremyroman.github.io/alternate-loading-modes/ (early draft)
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:
Only same-origin prerendering is permitted. Cross-origin redirects cause prerendering to be cancelled. Any navigation away from the initial prerendered page also cancels the prerendering (exception: same-document navigations are allowed).
We only process rules being added; removal of rule sets is presently ignored.
We only accept list rules. (Eventually we envision also supporting document rules based on selectors and/or URL patterns.)
A page can only trigger a single prerender.
The `score` property has no effect. We prerender the first hint encountered.
Only Android is supported. Desktop and Android WebView is not yet supported.
Only devices with 2GB+ of memory can prerender a page. However, this threshold might be tuned later.
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. Until browsers converge on a standard, browsers will have different methods to trigger prerendered pages and prerendered pages will behave slightly differently in different browsers, but that is the state of things today and what this effort is trying to address.
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 implementation 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 pertaining to prerendered pages.
In Chrome's former prerendering feature, `document.visibilityState == 'prerendering'` could be used to detect prerendering, and some sites may still have that code. However, it will not detect the new prerendering. The reasoning behind this is discussed here.
Note that Chrome has a <link rel="prerender"> feature which triggers No State Prefetch (and prefetching with speculation rules also triggers this). This experiment does not affect that feature, while we envision migrating <link rel="prerender"> to trigger prerendering later. Perhaps prerendering can also fall back to No State Prefetch in cases where prerendering is not possible due to device constraints.
Gecko: No signal
WebKit: No signals, while Safari appears to have some form of prerendering already.
Web developers: No signals
Ergonomics
This feature is triggered by the speculationrules API: https://chromestatus.com/feature/5740655424831488
It would be straightforward to change the method to trigger this feature though.
Activation
Developers can use the speculationrules 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 one of the first uses of the Multiple-Page Architecture (MPArch), which is a significant change to Chromium's internals. Both MPArch and this feature in particular underwent significant security review. See the Security section of the design doc for some 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.
Ongoing technical constraints
None
Debuggability
It is TBD how to integrate with DevTools. Currently DevTools does not work for prerendered pages. On activation, DevTools must be closed and reopened in order to inspect the page. 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.
To measure the impact of the feature, we recommend that sites use RUM to measure CWV metrics or their own key performance indicators in the wild. As part of this feature, we add activationStart to Navigation Timing to help with measuring user-perceived latency.
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?
We will add WPT to the extent possible. Some behavior may be internal or UA-dependent and require a different set of tests.
We have a suite of tests at wpt_internal that are intended to be upstreamed to WPT. The primary blocker is a WebDriver API to trigger prerendering in a deterministic fashion suitable for testing: https://crbug.com/1226460
Flag name
Prerender2
Requires code in //chrome?
False, but some features in //chrome need to be aware of prerendering pages.
Tracking bug
Launch bug
Estimated milestones
OriginTrial Android First 94
OriginTrial Android Last 98
Demo
https://prerender2-specrules.glitch.me/
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5355965538893824
This intent message was initially generated by Chrome Platform Status and then manually edited.
Chris Harrelson
--
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/CAJ_xCikXj%3D76qQuysz%3DgCpbNb9kNF8bKqmJUokavZh%3Dq_HOMoQ%40mail.gmail.com.