Re: [resource-hints] first spec draft

On Fri, Jul 11, 2014 at 10:59 AM, Podjarny, Guy <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.

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

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

ig