Re: [resource-hints] first spec draft

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.

ig