Re: [resource hints] preconnect, preload, prender

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
>