Re: [resource hints] preconnect, preload, prender

I've taken another run at the doc (substantial overhaul):
https://docs.google.com/document/d/1HeTVglnZHD_mGSaID1gUZPqLAa1lXWObV-Zkx6q_HF4/

- Merged use-case sections with each hint
- Added "proposed behavior" section for each hint
- Dropped "preload+lazyload" in favor of separate preload and prefetch
hints

Would appreciate any feedback!

ig


On Wed, Jan 22, 2014 at 3:30 PM, Yoav Weiss <yoav@yoav.ws> wrote:

>
>
>
> On Wed, Jan 22, 2014 at 9:09 PM, Ilya Grigorik <igrigorik@google.com>wrote:
>
>> On Mon, Jan 13, 2014 at 4:17 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>>
>> On Wed, Jan 8, 2014 at 7:32 PM, Ilya Grigorik <igrigorik@google.com>
>>>  wrote:
>>>
>>>> As per our discussions before the break, I've added a "use cases"
>>>> section to the document to highlight where and how each hint can be used:
>>>> https://docs.google.com/a/google.com/document/d/1HeTVglnZHD_mGSaID1gUZPqLAa1lXWObV-Zkx6q_HF4/edit#heading=h.nbuj0xq5vk0g
>>>>
>>>> Any additional examples + general feedback on what's there would be
>>>> much appreciated!
>>>>
>>>
>>> Looks awesome! I have my reservations regarding using "preload" and
>>> "preload lazyload" to signify semantically different types of resources.
>>> While "prefetch" was confusing, it had this advantage, since these types of
>>> resources should behave differently under certain scenarios. maybe
>>> "preload" and "nextpage-preload"?
>>>
>>> A few specific comments:
>>> * In the "preload - current page" section - What's the reason for "UA
>>> should not apply any content-specific processing on preloaded resources"? I
>>> agree that it's probably not a good idea to do so when the CPU is busy, but
>>> assuming it is not, why shouldn't the UA process these resources (e.g. JS
>>> parsing or image decoding). OTOH, it *must* not execute JS or apply CSS
>>> them before they appear in the page.
>>>
>>
>> The intent was to separate the cases of "prerendering" a resource - e.g.
>> say I point prerender at an image or JS asset - vs "just" prefetching it.
>> That said, as others have previously noted, "prerendering" a JS/img
>> resource may be somewhat confusing -- open to ideas here on how to message
>> it better.
>>
>> That said, the alternative is to defer this logic to the UA entirely...
>> Arguably, this is more of a resource scheduling / availability and
>> implementation question.
>>
>
> +1 for deferring it to implementations.
>
>
>>  The primary use case I had in mind when writing that is something like
>> an infinite image gallery: I want to issue preload requests as the user
>> scrolls or is interacting with individual resource, and I also want the
>> browser to decode the images ahead of time where possible such that I can
>> deliver a smooth 60FPS experience.
>>
>>
>>> * In the "preload+lazyload" section - Shouldn't the "UA should not
>>> cancel preload requests across page navigations" part refer *only* the
>>> preload+lazyload? I'd assume that requests for resources that are supposed
>>> to be preloaded for current page would be canceled across navigations.
>>>
>>
>> Yep, that was the intended behavior. Sounds like I need to rework it to
>> make it more clear.
>>
>>
>>> * In the use-cases section, shouldn't the "prefetch" section be renamed
>>> to "preload+lazyload"?
>>>
>>
>> As I was writing the doc I kept flipping back-and-forth between (a)
>> introducing preload and preload+lazyload vs. (b) keeping prefetch and
>> introducing preload (current page). In the examples section I went with
>> (b)... and I need to make the doc consistent.
>>
>> With benefit of time, I'm now leaning towards (b): keep prefetch to mean
>> "fetch this for future navigation", and adding a new hint for preload,
>> which can act as a declarative way to communicate with the preload scanner
>> (i.e. current page).
>>
>> Before I overhaul the doc, yay / nay? Other ideas?
>>
>
> Yay! :)
>
>
>>
>> On Mon, Jan 20, 2014 at 8:56 AM, Patrick Meenan <pmeenan@webpagetest.org>wrote:
>>>
>>>  On 1/20/2014 5:32 AM, Jonny Rein Eriksen wrote:
>>>
>>> During testing I realized it would be helpful if the resource hints
>>> could be given on the redirect from http://yahoo.co.jp/ to
>>> http://www.yahoo.co.jp/. But I am not sure if the content of a redirect
>>> is even parsed once a location header is seen by the client?
>>>
>>> If we defined header-based alternatives for each of the directives then
>>> the preconnect information could be passed on the response headers along
>>> with the redirect.  As a bonus, it also makes it really easy for an admin
>>> to enable preconnects on a site-wide basis without having to make any
>>> content changes.
>>>
>>
>> Yep. At least in theory, we already have a well-defined mapping for this
>> stuff. For example:
>> *<link rel="preload" href="jquery.js">* is equivalent to: *Link:
>> <jquery.js>; rel=preload*
>>
>>
>> On Mon, Jan 20, 2014 at 2:32 AM, Jonny Rein Eriksen <jonnyr@opera.com>
>>  wrote:
>>
>>> I have been testing resource hints lately. I started with high latency
>>> sites and the results I got were interesting. These hints are hardcoded in
>>> the browser, so not completely realistic, but still a good indication. All
>>> testing is with empty cache:
>>>
>>> This also implies that if we want to support two or more preconnects to
>>> one server then we need to specify that with something like:
>>> <link rel="preconnect" connections="*2*" href="//somehost.com">
>>>
>>
>> FWIW, I think we should defer the connection counts to the UA. The actual
>> (optimal) number of connections will vary based on client connection
>> profile and available resources on the client.. Plus, most UAs have some
>> form of a predictor which can remember optimal connection counts and hosts
>> and use that information on repeat visits.
>>
>>
>>> Next I intend to test more with local fast sites but reduced bandwidth
>>> in a more typical EDGE/3G setting.
>>>
>>
>> Awesome, thanks for digging into this stuff!
>>
>> ig
>>
>
>