Re: [resource-hints] first spec draft

Ilya,

Thanks for writing this up. Adding my comments on the draft to Guy's comments.

Peter


On Jul 9, 2014, at 9:20 AM, "Podjarny, Guy" <gpodjarn@akamai.com> wrote:

> Hi Ilya, 
> 
> Looks good! 
> I’m definitely a supporter for the concept here. 
> 
> Re the naming, I find resource hints reasonable, but some other options may be preparser-hints or predictive-hints .
> 
> Here are a few comments in the doc order (not order of importance):
> 
> 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.
> 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.

> 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?)
> 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? 
> Should preload resources delay unload? (my vote is no)
> 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)?
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?
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.
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.
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?
As per our other email thread, we should include object version information in the preload hint so as to minimize cache re-validation requests.

> Section 2.3 & 2.4 (prefetch/prerender):
> What happens if a user navigates to the next page while a resource is being downloaded? (I would suggest the resource keeps downloading, but we need a timeout of sorts – perhaps the onload of the next page?)
> If prefetch works across unload, does it somewhat compete with the Beacon API?
> Re Link header support : Big thumbs up!
+1

> 
> 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
> For prefetch & prerender, use the cache instructions (no grace period or changes)
> A couple of additional questions:
> How would these hints, and specifically preload, interact with Client Hints? 
> What about srcset and the picture element (e.g. Native conditional loading mechanisms)?
> Cheers,
> Guypo
> -- 
> Guy Podjarny | Akamai CTO, Web | www.guypo.com | @guypod
> 
> From: <Nottingham>, Mark <mnotting@akamai.com>
> Date: Wednesday, July 9, 2014 at 4:08 AM
> To: Ilya Grigorik <igrigorik@google.com>
> Cc: public-web-perf <public-web-perf@w3.org>
> Subject: Re: [resource-hints] first spec draft
> Resent-From: <public-web-perf@w3.org>
> Resent-Date: Wednesday, July 9, 2014 at 4:08 AM
> 
> Hey Ilya,
> 
> Had a quick look, like it so far.
> 
> A couple of nits:
> 
> 1) The name is really generic. Something more decriptive would be better, e.g., "Link Relations for Browser Performance" (yes, I know that's not as catchy)
> 
> 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.
> 
> 3) Those link relations will need to be registered...
> 
> 
> On 9 Jul 2014, at 3:35 am, Ilya Grigorik <igrigorik@google.com> wrote:
> 
>> First run at the spec based on previous discussions [1] and feedback:
>> https://igrigorik.github.io/resource-hints/
>> "This specification defines preconnect, preload, prefetch, and prerender hints that the developer, or the server generating or delivering the resources, can use in an interoperable way to assist the user agent in the decision process of which origins it should connect to, which resources it should fetch to improve performance, and which resources may be required by the next navigation."
>> Feedback, nitpicks, etc., all welcome!
>> ig
>> [1] https://docs.google.com/document/d/1HeTVglnZHD_mGSaID1gUZPqLAa1lXWObV-Zkx6q_HF4/edit#
> 
> --
> Mark Nottingham    mnot@akamai.com    https://www.mnot.net/
> 
> 
> 
> 
> 
>