This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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/
On Wed, 7 Nov 2012, Gavin Peters (蓋文彼德斯) wrote: > > I'm continuing to work on <link rel=prerender>, an API in WebKit, > implemented by Chrome, which allows applications to request pages be > loaded early for faster navigation. This is a leading cause of 0ms > navigations on the web! > > As we've explored this feature, we've continued to add to the API to > allow more applications to benefit from prerender, and measure that > benefit. At launch time, prerenders lasted 30s in Chrome before > being removed to prevent stale navigations. Now, the default is 5m, > in part because we use application removal of a <link rel=prerender > ...> element as a signal to kill the prerender, similar to the > <applet> or <object> element. > > I just wrote up a short proposal at: > http://wiki.whatwg.org/wiki/Link_prerender_events discussing the > next idea we're working on. > > By passing events to applications using prerenders, the applications > will better measure their use of prerender, and better control how > they are launched (serially or in parallel). The proposal has the > details. > > There's patches already in work to do this in WebKit and Chrome, see > https://bugs.webkit.org/show_bug.cgi?id=96474 for WebKit and > http://codereview.chromium.org/10918189/ for the embarrassingly out > of date Chrome version of this patch.
Ilya, your work superseded this, right?
Yes. There is more work to be done on it, but it should be handled in the RH spec.
This is now https://w3c.github.io/resource-hints/.