[whatwg] Prerendering and APIs

[Gavin Peters (蓋文彼德斯)]

Hi whatwg!

Since sending the below message, I've spent some time thinking about how to
handle the two cases I described in my initial posting, timeouts and load
events, and I think that both can be handled inside of the existing markup
framework on <link rel=prerender...> elements.

Also, I forgot to include some documents in my earlier post; here's
Chrome's instructions to web developers for prerendering:
https://developers.google.com/chrome/whitepapers/prerender .

Now, three weeks later here's an update on where my thoughts are on the
problems I introduced in my original email, along with my status in
addressing them:


*==Canceling Prerenders Using the Link Element==*

Some pages may want to keep the prerenders they launch fresh.  A search
engine, for instance (like Google Web Search, which currently issues
prerenders) will not want users to navigate to stale prerenders.  The
simplest way, and I think a way consistant with both the current link
element, and existing use of markup, is to cancel the prerender associated
with a link element when the link element is removed from the document.

This is both similar to, and different from, the behaviour of other
elements when they are removed from documents.

It is different from what happens when an img element, for instance, is
removed from a document.  Most browsers I've tested informally continue to
load an img element even after it's removed from the document; and this
serves a purpose: inserting the same img element into the document at a
different location results in a seamless continuation of the img load.

However, this is strikingly similar to two other cases: when a <link
rel=stylesheet ...> element is removed from the document, in WebKit, we
remove the stylesheet from the document, although this isn't explicitly
specified in 4.12.5.11,
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-stylesheet.

It is also similar to what happens on removal of an object or applet
element.  In 15.3.1 discussing the applet element, the state of a JVM is
discussed as dependent on insertion and removal from a document.  In 4.8.4,
the object element specifically requires a plugin unload when the object
element is removed from the DOM.


*==Load Events/Statistics==*

The web visibility API[1][2][3][4] provides a great way for targets of
prerenders to detect prerendering.  I'd like launching sites to have some
means to detect some information about the prerenders they're launching, to
for instance gather analytics on if the prerenders being launched are all
going unused, which prerenders are working best (keeping in mind that the
current chrome prerender implementation only allows one prerender at a
time), etc...

For that, I propose we fire events at the link element; similar to an
iframe the standard load events load, error, abort, and possibly loadstart.
 The abort event will be sent when the prerender is dropped by the browser,
for instance due to a timeout, or due to the prerendered site doing an
illegal action (i.e. XHR DELETE).  These events will allow a launching site
to track uptake of target prerenders, particularly in conjunction with <a
ping=...> on the relevant outgoing link.


*==Status==*

I'm currently working on an implementation of the first part, canceling, in
WebKit & Chrome, with some early architectural reviews coming back in
https://bugs.webkit.org/show_bug.cgi?id=82478 and
http://codereview.chromium.org/9875026/ .

whatwg, WDYT?

- Gavin


[1] https://developers.google.com/chrome/whitepapers/pagevisibility
[2] https://developer.mozilla.org/en/DOM/Using_the_Page_Visibility_API
[3]
http://ie.microsoft.com/testdrive/Performance/PageVisibility/Default.html
[4] http://www.w3.org/TR/page-visibility/




On Wed, Mar 14, 2012 at 11:35 AM, Gavin Peters (蓋文彼德斯)
<gavinp at chromium.org>wrote:

> We're having great luck in Chrome with <link rel=prerender href=foo>.  If
> that element with that rel attribute is in your document, Chrome launches a
> hidden tab that we swap in and stitch into history if the user navigates
> there.  Navigation is as quick as switching tabs, you either join an
> in-progress load or an already loaded page, depending.  It's really
> increased the number of 0ms navigations chrome does!  "0ms: it's not just
> for about:blank any more."
>
> Right now, while Chrome registers and sends onload/onerror events to link
> elements for prefetch, we don't do that for prerender.  Actually, it's a
> bit of a bug, but we always instantly send onerror to rel=prerender link
> elements.
>
> Hundreds of sites are using it now.  Prerender instructions are also
> sometimes inserted by GWS in results, which makes clicking on search
> results faster.  But I have some concerns:
>
>
> *==First Concern: Timeouts==*
>
> One concern we've had feedback on from sites trying to adopt the feature
> is maintaining prerender freshness.  Right now, out of an abundance of
> caution, we keep prerenders alive for a maximum of 30s.  That short limit
> has caused at least one site we know of to abandon the feature out of
> frustration.  While 30s may be a great timeout for a search engine that
> wants to make sure you go to a fresh news site, for instance, 30s probably
> makes sense.  For a magazine or blog using it for a next article, maybe
> they'd be OK with the prerender being around indefinitely, or some amount
> longer.
>
> But this means we need more control at two places.  Target sites should be
> able to control the amount of prerendering done of them, that's true.
>  Today, though, I'd like to talk about launching sites.  I think launching
> sites need a mechanism to cancel prerenders that they've launched, and also
> to specify to launch prerenders with other than a short timeout.
>
>
> *==Second Concern: Load Events/Statistics==*
> *
> *
> I'd like sites using Prerendering to be able to track the performance that
> this feature is getting them.  We're in a good spot on target sites for
> that today; we have implemented the visibility API which exposes a
> visibility state "prerender."  The API has a visibility change event, so a
> target site has relatively good information they can collect.
>
> But launching sites right now have nothing; they insert the link prerender
> element, and that's that.  Just like link rel=prefetch, I think this event
> could return, just as a cross-origin iframe does, onload/onerror/onabort
> (onabort for instance when we aren't prerendering, or won't launch that
> prerender for some other reason?).  But that isn't quite there: there's
> lots of reasons that the prerender could go away after onload.  For
> instance, if a prerender attempts to launch an XHR DELETE, we both don't
> complete the request, and we drop the prerender.  By this point, we've
> already fired off a load event at the page possibly, so if we send onabort,
> that will be an onabort after onload, which I think is novel?  Although I
> guess <audio> can send abort many times, though it never sends load,
> instead it sends the suite of media loading events.
>
>
> *==Conclusion==*
>
> No conclusions yet.  I just have these two interesting problems.  I'd love
> to hear what anyone else thinks about these problems?
>
<