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: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(copy Proposal template)
(first draft)
 
Line 1: Line 1:
This is an empty page that describes what should be documented about a problem and the different solutions proposed to address it. Feel free to copy this template to when creating a new page.
DOM events on prerenders which provide applications with prerender status updates.


:''Brief description of the problem to solve.''
== Why Events? ==


== Use Case Description ==
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.
''Complete description of the use case.''


=== Current Limitations ===
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.
''Explanation of why the current markup is insufficient.''


=== Current Usage and Workarounds ===
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.
''Some evidence that this feature is desperately needed on the web.  You may provide a separate examples page for listing these.''


=== Benefits ===
=== Example Applications ===


''Explanation of how and why new markup would be useful.''
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.


=== Requests for 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.


* <cite>[http://example.com Source]</cite> <blockquote><p>I would like this feature ...</p></blockquote>
=== Alternatives & Workarounds===


== Proposed Solutions ==
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


=== My Solution ===
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.
:''Brief description of the solution and of how it address the problem at hand.''


==== Processing Model ====
== Proposed Solution ==
:''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''


==== Limitations ====
=== List of Events ===
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''


==== Implementation ====
* '''PrerenderStartEvent''' The prerender described by this link element has been launched.
:''Description of how and why browser vendors would take advantage of this feature.''
* '''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.


==== Adoption ====  
=== Limitations ===  
:''Reasons why page authors would use this solution.''
 
Similarly to iframe, the '''PrerenderLoadEvent''' & '''DOMContentLoadedEvent''' may expose cross site web timing attacks.
 
 
== Bibliography ==
 
* 'Web Developers Guide to Prerendering' [https://developers.google.com/chrome/whitepapers/prerender]
* 'Using the Page Visibility API' [https://developers.google.com/chrome/whitepapers/pagevisibility]


[[Category:Proposals]]
[[Category:Proposals]]

Latest revision as of 22:13, 7 November 2012

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]