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:
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 signalWebKit
: No signal. Appears to have some form of prerendering already.Web developers
: No signals
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.