Re: [resource-hints] first spec draft

Thanks for the responses. Some follow-up comments...

> On Jul 10, 2014, at 5:41 PM, Ilya Grigorik <igrigorik@google.com> wrote:
> 
> Peter, Guy, Mark, thanks for the feedback! Comments inline.
> 
>> On Tue, Jul 8, 2014 at 8:08 PM, Nottingham, Mark <mnotting@akamai.com> wrote:
>> 2) The "Caching Grace Period" section seems a bit iffy to me... I wouldn't express this as being an override of the caching policy, but rather of it being applied *after* the cache; i.e. the rendering engine itself effectively caches it for next use.
> 
> Yep, great point. Will suggested the same and I've took a run at reworking that section. Let me know how this looks:
> https://github.com/igrigorik/resource-hints/issues/5
> 
> 
>> On Thu, Jul 10, 2014 at 7:27 AM, <bizzbyster@gmail.com> wrote:
>>> On Jul 9, 2014, at 9:20 AM, "Podjarny, Guy" <gpodjarn@akamai.com> wrote:
>>> Section 2.1 (preconnect):
>>> One delta between pre connect and dns-prefetch is cost to the UA. My understanding is that establishing a connection is more expensive in resource utilization than DNS prefetch too. Therefore, dns-prefetch may be used more lightly, and perhaps it’s a reason to not think of dns-prefetch as a preconnect.
> Fair enough. That said, I think this is something worth experimenting with.. All modern browsers are already doing preconnects anyway (without the hint and based on own heuristics), so I'm not sure that the dns-prefetch upgrade would change the picture by much. I'll see if I can get some data from HTTP Archive on how often dns-prefetch is used in the wild.
>>> For some domains (e.g. Your CDN domain), it’ll actually be helpful to open multiple connections, not just one (assuming no SPDY/HTTP2). Specifying a number sounds too wrong, but does it make sense to put a weight factor on the preconnect? Maybe a “primary” vs “secondary” domain? Could be getting into the diminishing returns space.
>> 
>> I agree that it is helpful to open multiple connections for many domains but don't see a problem with specifying a number. The draft argues that the UA is "is in the best position to determine the optimal number" of connections per domain. But this is not always the case. If the server were able to receive and leverage feedback from browsers ("past request patterns" in the draft) then it could know more about the capabilities of various domains. For instance, we see some servers allow a large number of concurrent connections and others enforce strict low limits. I think it makes sense to include a suggested number of connections in the pre-connect hint. The UA is free to ignore that suggestion.
> 
> 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.

>>> Section 2.2 (preload):
>>> With today’s implementations, double downloading of preloaded resources is a major issue. Would be good to make some explicit definitions about how to handle a resource that has been requested as a preload resource already and is now seen on the page. An obvious rule should be to not double download, but others may be more complex (e.g. What if we communicated a low prio via SPDY/HTTP2?)
> - Matching retained responses with requests: https://igrigorik.github.io/resource-hints/#matching-request
> - (Re)prioritization: https://github.com/igrigorik/resource-hints/issues/1 
>>> 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?
>>> Should preload resources delay unload? (my vote is no)
> Preload hints are for the *current* page. As a result they are cancelled as part of onunload. If you need the request to span across navigations, you should be using prefetch, which is used to load resources for next navigation.
>>> What should preload (and prefetch) do in case the resource request got a temp error (e.g. 502)
>>> How should the UA handle cookies set in a response to a preload (or prefetch)?
> Hint-initiated requests are not special in any way: think of any request initiated by the preload scanner today, all the same behaviors here. If the request fails, it fails.. it sends the same cookies, and so on. 
>  
>> A few more to add to this list:
>> How to handle the fact that cookies may have changed between the requesting of the preload resource and the requesting of the resource by the renderer either due to a Set-Cookie or a locally executed javascript? Perhaps we could add an attribute that indicates that the resource is cookie-sensitive or not?
> We don't. You have the same race condition today with the preload scanner sending early fetches for JS/CSS.  
Yes but preload hints create the ability to exacerbate this race since these hints allow prerequesting resources much earlier. If we just assume cookies do not need to match, that is fine. But I think the spec should say something about it so we have consistent behavior across browsers.
>> 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.
>> By viewing past behavior, especially with resource priorities in HTTP/2, the server can actually know quite a bit more than the browser about resource priorities. It would be great if the server could provide the UA with a hint as to the importance of the object. Is it a serializing resource? Does visual completeness depend on it? This information could be communicated via a simple low, medium, high type scheme and the spec could provide description as to what these values mean.
> That's what type/context is meant to provide. Today we don't have a more fine grained mechanism to communicate priorities. Perhaps we should, but I think that's a separate discussion. 
>> In order to make optimal use of a connection pool, it's valuable to know the size of a resource ahead of time. Is it possible to include an expected-size attribute?
> *If* we were to consider introducing this, I don't think its limited to hints. As such, I think this is a separate discussion. 
>> As per our other email thread, we should include object version information in the preload hint so as to minimize cache re-validation requests.
> I still think that subresource integrity is the right place to discuss this: http://www.w3.org/TR/SRI/#caching-optional-
Okay. But it might be useful to cross-reference here since the "digest" attribute in this case is a performance optization.

>>> Section 3.4 (Caching grace period):
>>> Since these hints are explicitly added, I think we can be a bit more strict in what we require.
>>> My vote would be:
>>> For preload, do the same thing the preparser does, which I believe means use the resource regardless of whether it’s cacheable, as long as you’re in the midst of loading the current page (may require some definition of when has the page finished loading, which I suspect the preloader deals with too). If you go to another page, revert to the cache instructions on the resource.
>> +1
> 
> Yes, this should be covered by the new "matching requests" section.
>>> For prefetch & prerender, use the cache instructions (no grace period or changes)
> This would cripple prefetch and prerender because most dynamic content is marked as non cacheable. Think of prerender as opening a background tab (or middle click, if you prefer), except that the tab is invisible and is then instantly swapped-in on navigation as long as it hasn't expired (insert reasonable TTL here.. Chrome uses 300 seconds).
>>> A couple of additional questions:
>>> How would these hints, and specifically preload, interact with Client Hints? 
> Assuming CH is implemented, the relevant hints would be advertised on the outbound request. Nothing special.
>>> What about srcset and the picture element (e.g. Native conditional loading mechanisms)?
> I don't see any concerns here. If you have conditional loading then you must evaluate those conditions.. With native <picture> those conditions will be executed by the preparser (yay) if the main doc parser is blocked... Yes, you may not be able to stick a Link header hint or put a <link> hint in the head of the doc, but such is the cost of conditional fetches. On the other hand, if you *know* you need a specific file regardless, feel free to hint it.
> 
> ig