Re: [resource hints] preconnect, preload, prender

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


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