Re: [resource-hints] first spec draft

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.

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)?

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!

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.
    *   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<http://www.guypo.com/> | @guypod<http://twitter.com/guypod/>

From: <Nottingham>, Mark <mnotting@akamai.com<mailto:mnotting@akamai.com>>
Date: Wednesday, July 9, 2014 at 4:08 AM
To: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>
Cc: public-web-perf <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: [resource-hints] first spec draft
Resent-From: <public-web-perf@w3.org<mailto: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<mailto: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<mailto:mnot@akamai.com>    https://www.mnot.net/