22676 2013-07-15 23:11:18 +0000 APIs for page prerendering 2015-09-17 09:17:22 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED P3 enhancement Needs Impl Interest 1 ian ian annevk ian igrigorik mike contributor oldest_to_newest 90750 0 ian 2013-07-15 23:11:18 +0000 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/ 90809 1 ian 2013-07-16 17:38:49 +0000 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. 123223 2 annevk 2015-09-16 09:55:25 +0000 Ilya, your work superseded this, right? 123231 3 igrigorik 2015-09-16 18:30:09 +0000 Yes. There is more work to be done on it, but it should be handled in the RH spec. 123238 4 annevk 2015-09-17 09:17:22 +0000 This is now https://w3c.github.io/resource-hints/.