Re: [resource-hints] first spec draft

A few more comments below.
--
Guy Podjarny | Akamai CTO, Web | www.guypo.com<http://www.guypo.com/> | @guypod<http://twitter.com/guypod/>

From: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>
Date: Friday, July 11, 2014 at 1:01 AM
To: Guy Podjarny <gpodjarn@akamai.com<mailto:gpodjarn@akamai.com>>
Cc: public-web-perf <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: [resource-hints] first spec draft

 *   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.
Damn auto-correct... I meant should preload block onload (the load event of the current page). Seems less obvious to me, but my vote is still no, unless they resource was discovered as a full resource further down.

Ah, hmm, interesting. I'm inclined to say that if you're loading resources via preload hint *and* they are not used before onload, then you shouldn't be using the preload hint for those resource anyway? The idea for preload is to help get the pixels on the screen faster by fetching critical resources sooner.. if you have resources that are not used until after onload, you're just creating unnecessary contention and you're probably better of scheduling them as part of "regular" page render process?

I think preloading resources which are likely needed would be a fair use of this feature. This may be because you have two resources and expect one to be used, and/or if you suspect you have the time to get them as you’re waiting for the page to load anyway. Either way, I don’t think that should be the guiding factor here.

IMO once a resource is used, it takes on the attributes of the actual resource, including changing its priority and any onload related behavior. If it’s not used, though, I think it shouldn’t block onload.
And I think the spec should state it explicitly.


 *   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).
I think you're referring to unilateral prerenders done by the browser, I think it's different when the page explicitly asks for it.

I don't see why this is any different. Most dynamic pages are no-cache due to personalization, etc.

Personalization shouldn’t prevent “Cache-control: private” instructions.



I think this is especially important for prefetch. If a web dev wants it cached, they should specify a cache private instruction.

I think I created unnecessary confusion with "cache grace" language.. should be fixed now.

I understand this isn’t a cache in the traditional sense, but at the end of the day it’s still logically a cache no matter what you call it. If you fetch content ahead of time, and don’t know how much time will elapse before you’ll use it, the website must have control over how long  the fetched resource will be valid for. You can do this by making this “grace TTL” a configured parameter, but IMO the best path is simply to not have a grace TTL, and use the standard caching instructions.

If a resource is not cacheable, even on a browser, it shouldn’t be prefetched/pre-rendered. You may need heuristics when you do this unilaterally, but when someone enters an explicit hint into the page, I think the requirement is on them to ensure it’s cacheable.


 *   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.
Isn't srcset short enough to consider here at least?

What about srcset? The preload scanner (or regular doc parser) will find it, evaluate it, and initiate the right fetch. Or, am I missing your point?

What I meant was: can’t we support prefetch of srcset, by having the context/type state “srcset”, and having the URL hold the srcset-format text? Same thing for the Link header.
It feels like an overkill to fit Picture into this format, but srcset seems light enough to make it reasonable.



ig