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

[Mike Belshe]

2011/1/14 Maciej Stachowiak <mjs at apple.com>

>
> 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.
>

The statement above makes it sound like I said there was a 15+% speedup from
this generically - that is certainly not the case!  It is very dependent on
content.  The testing was done almost two years ago and not by me.  You can
find some of it on the chromium.org website; but because it is old data and
not by me, I don't want to cite it as accurate.  I simply want to say that
there is some promise.   We're actively ready to do experimentation with
this inside of Chrome; but we need some leeway on testing it.  It's a
chicken and egg- we can't test it in real scenarios if we don't build it.

Regarding poor web page design - You're right, webpages can always optimize
around this.  But, the web page optimization space is moving more and more
to smart servers, and automated optimizers.  Web document developers
shouldn't need to know how to do these optimizations - it is something they
are inherently not good at, and with every new site layout, they can easily
regress.  Enabling the HTTP level headers for this allows accelerators to
monitor when these headers are appropriate and automatically insert them in
an efficient manner.  We are planning to test this case.

Mike



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