On Wed, 14 Mar 2012, Gavin Peters (蓋文彼德斯) 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.

On Mon, 9 Apr 2012, Gavin Peters (蓋文彼德斯) wrote:
> 
> 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/ .
> 
> [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/