[webkit-dev] Feature Announcement: Link Prerendering API

[Gavin Peters (蓋文彼德斯)]

Link Prerendering is a feature of chromium to load entire web pages ahead
of navigation.  The feature has been enabled in our release branch for some
time, and prerender links are found on many web sites, and are emitted by
Google Web Search for first results sometimes.  To learn more about
prerendering, see https://developers.google.com/chrome/whitepapers/prerender

I'm working on removing <link rel=prerender ...> loads from the main
resource loading path, and instead giving the platform a prerendering
interface.  Right now, prerenders are a type of resource request.  In the
chromium port, our network stack catches the prerender loads, aborts them,
and asynchronously launches a prerender.  We've been having a really good
experience with prerendering in chrome, and we're at the point where to
help more sites adopt it, we need a better API; the load events are not
quite right for prerenders, and prerenders are not quite network requests
in many ways.  Using a cachedresourceloader to fire off a load for a
request that will not return data didn't quite make sense.

Reviews are still ongoing, but the first few steps of this API are being
worked on at https://bugs.webkit.org/show_bug.cgi?id=82478 , and in
https://github.com/gavinp/git.webkit.org/pull/2 [1].  Please, follow along
if you're interested.  There's a corresponding chrome CL tracking this api
at http://codereview.chromium.org/9875026/ , however that CL is not quite
as up to date.  I should update it in the next day or two, though.

This first set of changes lets prerendering launchers signal that they want
a prerender to be dropped, simply by removing the link element from the
document.  A separate signal is sent to the prerendering platform when the
page is navigated away from.  As well, prerenders are now sent to the
platform fragment clean, and the code path doesn't include things like a
cached resource loader, which for a prerender didn't really make sense.

This API has been talked about at whatwg, at
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035065.html, and
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-April/035394.html .

- Gavin

[1] I'm very happy with how a github pull request lets me easily show a
change that has a lot of plumbing like this in layers.  The interface for
this aspect of it is great.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120412/0c7a43e4/attachment.html>