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

[Gavin Peters (蓋文彼德斯)]

Hi!

I'm returning to this work now, and I see that folks have been quiet about
this since I posted my plan.  Here's how I'm going to proceed:

Step 1: I will add beforeload to prefetch & icon rel types.  Expect a CL for
this soon.
Step 2: I will add a new subresource rel type, which will have higher
priority than prefetch, otherwise be the same.
Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from
html/HTMLLinkElement.cpp
Step 4: We land the Link header parser directly (bug 51940)
Step 5: Add beforeload events to the Link header?

Comments?

On 24 January 2011 18:10, Adam Barth <abarth at webkit.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110222/d5f9fbca/attachment.html>