[whatwg] Prerendering and APIs

[Gavin Peters (蓋文彼德斯)]

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?