Re: [resource-hints] first spec draft

On 13.07.2014 12:54, Ilya Grigorik 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>

I see the discussions on whether prefetch should be merged with 
prerender. Now I am starting to think that prefetch should be merged 
with preload instead and lazyload be supported by both preconnect and 
preload. Both could trigger after the onload event and this would mean 
that both could be supported for next page navigation optimization. As 
it is today it is likely the preconnect would be optimized away by 
having too many preconnects for one pageload, but that would be less of 
a problem if they were triggered after onload. Of course a preload could 
implicitly include preconnect, but using that may not always be desirable.

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