[webkit-dev] Feature Announcement: Link Prerendering API

[Gavin Peters (蓋文彼德斯)]

I'd also like to ask specifically for guidance from reviewers, especially
on ports other than Chromium, about how to handle the new files in WebCore
that are part of the Link Prerendering API.  Should I add them to other
ports build files?

The new files in WebCore that are only important to ports that have
prerender on on are currently WebCore/loader/Prerenderer.*,
WebCore/loader/PrerendererClient.*, WebCore/platform/PrerenderHandle.h.
 Those files basically all just have #if ENABLED(LINK_PRERENDER)
surrounding the entire implementation.  If you aren't using prerendering,
they are empty files.

I can see the arguments on this both ways.  If I add them to the build
files, then of course things will be easier for the lucky hacker adding
prerender to another port in the future.  We'll also benefit from having
build files that are close to each other; every bit that we drift apart is
more pain.

Against adding to the other ports, I see that these are translation units
that will slow down compiles; this is particularly true for anyone building
with a smaller number of CPUs, where compile time and not link time
dominates.  Why subject hard working hackers to any slowdown for a feature
they don't use?  And besides, prerendering is a complex feature with much
deeper implications than WebKit; whoever turns on prerendering in other
implementations is not going to be put off by adding a few files to their
project.

WebKit-dev, wdyt?

- Gavin


On Thu, Apr 12, 2012 at 5:50 PM, Gavin Peters (蓋文彼德斯) <gavinp at webkit.org>wrote:

> 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/ec44ca5c/attachment.html>