Intent to Prototype: Prerendering
Matt Falkenhagen
Contact emails
Explainer
https://github.com/jeremyroman/alternate-loading-modes/blob/main/README.mdSpecification
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/
Design docs
WIP at https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharingSummary
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>PrerenderMotivation
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
PendingRisks
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.