Intent to Prototype: Prerendering

238 views
Skip to first unread message

Matt Falkenhagen

unread,
Dec 15, 2020, 6:21:02 PM12/15/20
to blink-dev, Chromium Loading Performance, Domenic Denicola, Kinuko Yasuda, Jeremy Roman

Contact emails

(some contacts; not the entire team)
dom...@chromium.orgfal...@chromium.orgkin...@chromium.orgjbr...@chromium.orgloadi...@chromium.org

Explainer

https://github.com/jeremyroman/alternate-loading-modes/blob/main/README.md

Specification

There is an existing Prerender section in the Resource Hints specification, but we are working to create a more complete specification. A very early draft can be seen at

https://jeremyroman.github.io/alternate-loading-modes/


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.


Blink component

Internals>Preload>Prerender

Motivation

To speed up page loads. Chrome previously had a prerender mechanism that was replaced with No State Prefetch. No State Prefetch is simpler and safer, but doesn't generally result in the instant page load experience that we think is possible with prerendering. We intend to prototype prerendering again to see if we can bring it back successfully. We are working on a design that considers the issues of the previous incarnation, which included undesirable side-effects, resource consumption, low hit rate, privacy and security issues, and code complexity.


Initial public proposal

It is a feature that has existed in browsers over the years. A recent proposal is here

TAG review

None yet. We will request one when the first experiment and design is more concrete.

TAG review status

Pending

Risks



Interoperability and Compatibility

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. Prerendering can depend on UA-specific heuristics. For example, the browser might trigger prerendering when it predicts the next navigation, without the need for a page to use an API. However, there is necessarily web-visible behavior, since it involves fetching the page and executing its scripts. Some of the prerendering milestones may also require new API surface, as outlined at https://github.com/jeremyroman/alternate-loading-modes. The plan is for each API change to have its own Chrome Status entry and Blink Intent process. Some APIs under consideration include:

  • Triggering API: this might be the existing <link rel="prerender">, or it may be a different API or have some way to distinguish from the legacy behavior, if appropriate.
  • Target Opt-In API: a way for a target site to opt-in to prerendering.
  • Prerendering Detection API: a way for a page to know whether it's being prerendered. Previously this was `document.visibilityState == "prerender"` but that is no longer implemented in browsers and was removed from the specification.

These APIs still need to be designed and we will evaluate interoperability and compatibility as part of that process. Regarding compatibility, some use cases will need to know whether a page is being prerendered. Ads and analytics are likely examples of this. The Prerendering Detection API will be offered for this reason, 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.


Gecko: No signal

WebKit: No signal. Appears to have some form of prerendering already.

Web developers: No signals

Activation

The first milestones will require as little developer intervention as possible. Developers may need to use the Prerendering Detection API if desired to distinguish between prerendering pages and visible pages, though. Developers that want to increase the number of prerendered page visits will be able to use the triggering and opt-in APIs of later milestones.



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

No

Tracking bug

https://crbug.com/1126305

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.

Matt Falkenhagen

unread,
Dec 15, 2020, 6:23:27 PM12/15/20
to blink-dev, Chromium Loading Performance, Domenic Denicola, Kinuko Yasuda, Jeremy Roman


2020年12月16日(水) 8:20 Matt Falkenhagen <fal...@chromium.org>:
Oops, this section was lost in editing. This should be: "It will be tested with WPT to the extent possible. Some behavior may be internal or UA-dependent and require a different set of tests."
Reply all
Reply to author
Forward
0 new messages