Re: [resource-hints] first spec draft

(slowly catching up after a vacation...)

Everyone, thanks for the great feedback! Issues I've extracted so far:
https://github.com/igrigorik/resource-hints/issues?state=open

If you see something missing on that list, please open a ticket. I'm going
to try and get a new draft out next week.

ig


On Tue, Jul 22, 2014 at 4:54 AM, Jonny Rein Eriksen <jonnyr@opera.com>
wrote:

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