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.

Bibliography

• 'Web Developers Guide to Prerendering' [1]
• 'Using the Page Visibility API' [2]