Re: [resource-hints] first spec draft

Notes below.

From: "bizzbyster@gmail.com<mailto:bizzbyster@gmail.com>" <bizzbyster@gmail..com<mailto:bizzbyster@gmail.com>>
Date: Tuesday, July 15, 2014 at 4:25 PM
To: Guy Podjarny <gpodjarn@akamai.com<mailto:gpodjarn@akamai.com>>
Cc: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>, "Nottingham, Mark" <mnotting@akamai.com<mailto:mnotting@akamai.com>>, public-web-perf <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: [resource-hints] first spec draft

"If a resource is not cacheable, even on a browser, it shouldn’t be prefetched/pre-rendered."

I disagree. Cacheability is completely orthogonal to prefetchability. For example, I would like a user to see a different image each time he/she visits a page. Therefore I mark that image as non-cacheable. At the same time, I'd like for my user to see the page as fast as possible and so I'd like for the image to be prefetched.

IMO this is what stale-while-revalidate is for, and possibly short TTLs as well. The resource in this case is cacheable, and just needs a frequency of updates.


How about if resource retrieved via a preload hint can be used until the onload event regardless of cache headers?

I’m definitely good with that, I thought I mentioned it before but perhaps I didn’t.
My concern is with prefetch and prerender of non-cacheable resources, not with preload. In preload, I think it’s fine (and in fact, desirable) that the browser reuse the resource as long as the onload event hasn’t taken place (and perhaps even a bit after).




Peter
On Jul 14, 2014, at 2:50 AM, "Podjarny, Guy" <gpodjarn@akamai.com<mailto:gpodjarn@akamai.com>> wrote:



Guy Podjarny | CTO, Web BU | @guypod | www.guypo.com<http://www.guypo.com/>

On Jul 13, 2014, at 11:55, "Ilya Grigorik" <igrigorik@google.com<mailto:igrigorik@google.com>> wrote:

On Fri, Jul 11, 2014 at 10:59 AM, Podjarny, Guy <gpodjarn@akamai.com<mailto:gpodjarn@akamai.com>> wrote:
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.

I think the behavior you are describing is already covered by "lazyload":
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload

<link rel="preload" href="thing.js" lazyload>

Building up these behaviors from small and reusable primitives is a better path than creating exceptional cases.
So you're saying the default case would be to block onload? Why?

I agree lazyload would prevent the onload delay, but it's also coupled with lowering the priority of the download.

All that said, all I was asking for is an explicit statement about how these pre-X interact with onload. I will restate that my vote is to make them not block onload, but I can live with lazyload supporting that. Either way, I think it should be explicitly stated in the spec.


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

History lists come to mind and I'd argue that pre{fetch,render} belong in that same bucket:
http://tools.ietf.org/html/rfc7234#section-6

"no-store" seems like the right directive that would/could abort a pre{fetch,render}. That said, afaik, the implemented browser behavior for no-store differs even there for history lists, and the HTTP spec language is (intentionally) loose.. Mark, any thoughts or suggestions?

As an aside, a scan over recent HTTP Archive run shows that ~24% of HTML responses advertise "no-store".

Again, this is irrelevant IMO, as we're talking about explicit pre-X instructions here, so overall cache stats for sites that never considered or had the option to use those don't apply.


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

I think this is what you're actually after: https://github.com/igrigorik/resource-hints/issues/11 - right?

That would indeed serve the use-case, if in a more verbose way. That said, I was assuming, based on past conversations when discussing picture, that there'll be strong pushback from the browsers to it. If we get this issue accepted, srcset support seems less critical (though still a bit useful). If we don't, it's important.



ig