Re: [resource-hints] first spec draft

Comments inline.

On Jul 12, 2014, at 4:17 PM, Ilya Grigorik <igrigorik@google.com> wrote:

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

I'd like to see this functionality built into web servers so that they automatically learn the optimal way to load a page and then send hints down to the browser based on what they have automatically learned. So this complexity will be hidden from the admin. In general we need to move away from a web that requires web developers and admins to do the right thing and towards one that learns and automatically renders pages optimally.

As I've argued on the HTTPbis mailing list (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1637.html), web browsers that use multiple HTTP2/SPDY connections per domain will be faster than those that use just one, at least until QUIC has been widely deployed. But thinking about it further I realize that preload (today's subresource) hints give the UA information on how many resources it should expect to download from each domain. So the benefit of including expected connects in the pre connect hint would only apply to non-preloadable resources. This can often still be a large number of resources but it' s a smaller effect than I was originally thinking.
>>> 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.

Sounds good.
>> 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. 
How about the following?
<link rel="preload" href=generateUrl() type="image/webp">
> 
> ig