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

[Gavin Peters (蓋文彼德斯)]

Thanks everyone for your replies on link headers and rel types.

Mike Belshe from Chrome team put together a spec for these as part of Server
Hints for SPDY.  His server hint information is at:
https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint,
and link rel=subresource is at
https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint/link-rel-subresource.
 The bottom line for rel=subresource is that we've found in early
experiments that some page loads, especially of pages with dynamic content,
are sped up by 15-20%; it's much more than mere milliseconds that we're
talking about here.  I'd like to do more experimentation with this, and to
continue this we'd like to both have this rel type (with its prioritization)
and the Link header (with its early arrival).

Link rel types significantly change the semantics of each link.
 rel=stylesheet changes the HTML page's presentation, and in bug 20018,
Alexey raised some good points about how this affects saving web pages, and
I think these rel types in an HTTP header are justifiably more
controversial.  But that having been said, the rel types prefetch,
subresource, dns-prefetch are basically network level; they are instructions
about cache seeding.  No resultant document should view differently based on
these headers; only faster.

I agree that beforeload support could be more pervasive than it is today.
 The exclusion of prefetch, icon and dns-prefetch from beforeload events
bears revisiting.  But are these insurmountable?  Currently the bug up for
review, bug 51941 doesn't remove beforeload handling from anything that had
it.  The semantics of beforeload handlers for link headers wrt extensions
bear some thought, but I suspect these can be solved: can we create another
bug for adding this support?

- Gavin




On 13 January 2011 12:48, Alexey Proskuryakov <ap at webkit.org> wrote:

>
> 13.01.2011, в 09:14, Julian Reschke написал(а):
>
> >> I'm wondering what the use cases are. To me, adding a way for metadata
> to change document behavior sounds like a misfeature - it adds significant
> complexity to the system, while taking away existing functionality. As a
> specific example discussed in this thread, we'd break some browser
> extensions like Incognito if resource loading could bypass onbeforeload. As
> another example, we'd break<base> element.
> >
> > Well, there are document types where you *can't* inline the metadata.
>
>
> Indeed, and I don't have anything against metadata as long as it doesn't
> directly modify actual data. For example, Last-Modified and Cache-Control
> are quite obvious example of what can be in HTTP headers. Despite the
> practical/historical difficulties that I mentioned with Content-Type, it's
> arguably a valid example of metadata, too.
>
> Subresource references on the other hand are a part of a document, not of
> its metadata. Am I just missing a reason why one would want to prefetch
> subresources for a JPEG image?
>
> > We should distinguish between the act of declaring the link, and the
> moment where a potential fetch actually happens (it doesn't always happen,
> after all).
> >
> > I agree that stuffing things just to get a fetch to happen "earlier"
> maybe a premature optimization.
>
>
> Optimizing prefetch to start before actual document data arrives is highly
> controversial, but I believe that it's the primary reason why we're
> considering the Link header implementation.
>
> - WBR, Alexey Proskuryakov
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110113/5916e3e7/attachment.html>