[webkit-dev] beforeload & link (esp rel prefetch)

[Adam Barth]

2011/1/20 Gavin Peters (蓋文彼德斯) <gavinp at chromium.org>:
> I also have thought about how we can go forward, I'd like folks
> comments on this:
>
> Step 1: Land bug 51941, a refactoring of the HTMLLinkPrefetch element
> which pulls out loading for rel types prefetch, icon and dns-prefetch.

That sounds like a reasonable first step if we want to go forward with
Steps 4 and 5.  Perhaps it would make sense to delay this work until
we're ready to do Step 4?

> Step 2: Add beforeload to at least prefetch & icon rel types, and hey,
> why not dns-prefetch too!  Do this to fix bug 52577.

It seems reasonable to add beforeload events to prefetch.  Icon is
probably worth doing too.  I'm less sure about dns-prefetch because
that doesn't actually generate a "load" so to speak.  Maybe leave it
off in the first iteration?

My slight reservation here is that, from a privacy standpoint, there's
no reasonable way to prevent a web site from leading information back
to its server.  However, many privacy extensions take a "best effort"
approach rather than an "airtight" approach.  In that sense,
generating these events seems valuable because it improve what these
folks can build.

> Step 3: Add rel type subresource (same as rel type prefetch, only
> higher priority for in-page resources) (need to create a bug for
> this).

This seems valuable.  My understanding is that subresource is similar
to prefetch, just with a different priority (i.e., "please prefetch
this URL in time for it to be used by a subresource of this page").

> Step 4: Add Link header, providing rel types subresource, prefetch &
> dns-prefetch only (currently bug 51940).

This step also makes sense to me because these headers don't modify
the semantics of the document.  Supporting them in headers means that
web sites can optimize their performance using middleware boxes
without hacking up their HTML.

> Step 5: Add beforeload events to the Link header (as a followup after
> bug 51940).

This seems somewhat odd to me, but I guess it makes sense.  There's
some question about where to fire these events, but presumably firing
them on the document itself would be fine.

I'm willing to believe that my perspective might be biased because
I've been talking to Gavin about these features for a while.  I
certainly don't want us to move forward here if folks don't think this
is a beneficial course of action.

Adam