Re: [resource-hints] first spec draft

>
> Looks good.
> I find the magic number 300 to be out of place in a spec focused on hints
> to the browser. I suggest you just say the UA should make an attempt to
> retain it for a reasonable time.
>

Fair enough. I just wanted to provide a reference point.


>  - (Re)prioritization:
> https://github.com/igrigorik/resource-hints/issues/1
>
> Does SPDY or HTTP2 support such renegotiation?
>

Deployed SPDY does not, HTTP/2 does via PRIORITY frame:
http://tools.ietf.org/html/draft-ietf-httpbis-http2-13#section-6.3


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

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


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

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

ig