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 <a...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
