W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2014

Re: [resource-hints] first spec draft

From: Ilya Grigorik <igrigorik@google.com>
Date: Sat, 12 Jul 2014 22:17:01 +0200
Message-ID: <CADXXVKrmfBH1H3CQ4V0ZqwsRk8HatDhMHfJTCVt1AVjmr7syTg@mail.gmail.com>
To: Peter L <bizzbyster@gmail.com>
Cc: "Nottingham, Mark" <mnotting@akamai.com>, "Podjarny, Guy" <gpodjarn@akamai.com>, public-web-perf <public-web-perf@w3.org>
On Fri, Jul 11, 2014 at 10:20 AM, Peter L <bizzbyster@gmail.com> wrote:
> I understand the motivation, but I still think this exposes knobs that
> should be left to the user agent. The number of connections will vary by
> users connection type, time of day, protocol, and so on, all of which are
> dynamic. Browsers already track this kind of information and adapt their
> logic to take this into account - e.g. chrome://dns/ (see "Expected
> Connects" column). With HTTP/2 this is also unnecessary (and I say that
> with awareness of your recent thread on http-wg on the subject :)).
> Resource hints should provide a means for the UA to improve current
> behavior in the case when the UA has no history to go on about the page.
> For instance, if a page talks to 15 domains, but only one of those domains
> serves more than one resource, the server can know this and the UA can
> preconnect more efficiently (opening one connection for single resource
> domains and more for the multiple resource domains) if it is informed. I'm
> not understanding the argument against sending this information.

It's an extra layer of complexity that would be used by very few people
responsibly, and it's an attribute that serves no purpose in HTTP/2 world.
If you want to solve this problem for your site *today*, just upgrade to
HTTP2 / SPDY - no need to wait for a new spec, and it works across all
major browsers.

>>    - Content type as text sounds a bit error prone. Would
>>    “text/javascript” cover “x-application/javascript” too? Is there a way to
>>    normalize content types?
>> Jake proposed using "context" instead, which I really like, but need to
> do some more digging on:
> https://github.com/igrigorik/resource-hints/issues/6
> Context seems vague to me but maybe I'll just wait until there is better
> definition of each possible context value. It feels like we're blending
> multiple bits of information here in a way that will lead to confusion. Why
> not just indicate priority in a priority attribute (the UA can ignore or
> use as it likes) and then a bool to indicate if the resource is an image so
> the correct Accept header can be added to the request?

Exposing prioritization controls is not a bolt-on feature, its an entire
spec in its own right, which is why I'm punting on it. We need to think
about prioritization classes; how different content types + classes mix;
reprioritization; dependency trees, and so on. Assuming such spec is
introduced at later time, RH hints could be annotated with it.

>>    - The earlier spec discussed preload hints URLs that were generated
>>    via javascript. I think this is very powerful as it allows the browser to
>>    preload dynamically generated URLs. For instance, URLs with sessionID or
>>    Date or rand appended to them.
>> Yes, this is what preconnect covers. We don't know the URL, but if we
> know the origin we can at least complete the handshake:
> https://igrigorik.github.io/resource-hints/#preconnect (example 1)
> Right. But we should look to go beyond preconnects to make the web as fas
> as we can. One of the primary reasons concurrency is so low is due to
> client side dynamically generated URLs. I think we should provide a
> mechanism to preload these in the event these scripts are predictable.

I don't see how we can solve this in a reasonable (and simple) manner.

Received on Saturday, 12 July 2014 20:18:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:39 UTC