A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Link prerender events
DOM events on prerenders which provide applications with prerender status updates.
Why Events?
Current applications use the link type “prerender” to launch preemptive renderings of target URLs, including running scripts. Prerender can greatly speed up speed transitions when the target site is chosen judiciously.
The actual speedup experienced by users from prerendering depends on if (and which) proposed prerenders are launched by the application, and which user navigation is taken. Applications gathering these user statistics for speed improvement thus need to know which platform prerenders were launched, and with what latency.
Applications launching multiple prerenders may wish to serialize launching the prerenders if some are more likely navigation targets than others, but without status information on all of the pending prerenders, this is difficult.
Example Applications
http://codereview.chromium.org/ is a Rietveld instance that currently uses link rel=prerender to launch a prerender of the next file in the review: http://codereview.chromium.org/11288002/diff/12001/chrome/renderer/prerender/prerender_dispatcher.h . It could be very beneficial to also prerender the previous file, since users often flip both ways. But since it’s very common to quickly flip forward through short trivial changes, it’s best to not prerender previous until the prerender for next is quite far along, to minimize resource contention. However, the current prerender API makes this difficult to serialize: launching both at the same time will make the most common next case slower, and using a timer will not maximize the benefit of this feature.
Hypothetically, whatwgmagazine.com is a web magazine that is interested in deploying prerendering throughout the magazine for many links like “next page” or search results for stories. Because they’re aware of the cost of prerenders, they also want to be sure that they’re deploying them effectively and getting good benefit. So they track which prerenders are started and stopped, and on navigation away, perform an async XHR to upload statistics. Using this, whatwgmagazine.com is able to remove prerenders that are never navigated to (perhaps because they time out, or the target page uses too much memory...), and they’re able to characterize the time savings from prerendering in the launcher, which can also report on failed prerenders. They remove prerenders that don't get used, and they add prerenders that do trigger earlier.
Alternatives & Workarounds
For the multiple prerender case, the browser could internally serialize multiple prerenders (and is currently free to do so). In this case then, applications lose
For performance, target pages can use the Web Visibility API to track the length of time from being created in the “prerender” state until they become visible or hidden. However, this won’t permit tracking cancelled/stop prerenders unless target pages are transmitting a heartbeat. As well, this requires instrumentation of the target pages, and so it can’t be used to track cross site prerendering effectiveness.
Proposed Solution
List of Events
- PrerenderStartEvent The prerender described by this link element has been launched.
- PrerenderStopEvent The prerender described by this link element has been stopped, for any reason. Browsers may only give prerenders a limited lifetime. They may cancel prerenders that use too many client resources. They may cancel prerenders in background tabs, etc...
- PrerenderLoadEvent The prerender described by this link element has received its document load event.
- PrerenderDOMContentLoadedEvent The prerender described by this link element has received its DOM content loaded event.
Limitations
Similarly to iframe, the PrerenderLoadEvent & DOMContentLoadedEvent may expose cross site web timing attacks.