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

[Maciej Stachowiak]

On Jan 13, 2011, at 2:49 PM, Gavin Peters (蓋文彼德斯) wrote:

> 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)
> 
I am skeptical of this testing and I would like to see the details. Anything you can put in a Link header in response headers, you can also put in a <link> element in the HTML response document. Even if the response is dynamically generated and therefore slow overall, it should be possible to emit a fixed portion with the prefetch hints. Therefore this strikes me as a workaround for poor Web application design.
> 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 suppo
> 
It's not obvious how it could work, since a load triggered by a Link header has no associated element, and in fact starts before any elements exist. So there is nothing that can act as the event target. If you think it can be done, how about a proposal?

Regards,
Maciej


> - 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
> 
> _______________________________________________
> 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/20110114/a1a51730/attachment.html>