Re: [resource hints] preconnect, preload, prender

Hey Jonny, great feedback - thanks.


>  I tested more with typical edge/3G latencies and bandwidth. My goal was
> to be able to automatically detect the required resource hints to optimize
> for first display/full page load. After working my way through a number of
> testcases manually I found that this is more complicated than I would like.
>

To clarify, are you testing this by instrumenting the end-client, or via a
proxy?


> What I learned is:
> Tuning page load for one specific page is relatively easy when bandwidth
> is good.
>
> Resource hints can give great results when latency is 500ms or more and we
> have good bandwidth. At 300 ms and with Edge bandwidth it gets harder,
> since it also depends on what you want to optimize for. Also you are more
> often blocked by bandwidth than latency.
>
> Detecting automatically what resource hints optimize the right part of a
> page is complicated.
>

Indeed, this is why embed a lot of smarts into our "predictor" [1] in
Chrome, which includes a variety of signals: user behavior, past history
and navigation patterns, structure of the (previously visited) page, and
more. The hints we are talking about here are meant to augment these
mechanisms: despite our best attempts, there is only so much the UA can do
to infer usage patterns.. and thats where the developer of the site can
step in and provide additional hints: preload / prefetch behavior, custom
preconnect patterns, etc. Given that knowledge, the UA can then take its
current heuristics + user state (bandwidth, latency, custom user overrides,
etc), and figure out how to combine it all in the best way.

[1]
http://www.igvita.com/posa/high-performance-networking-in-google-chrome/#predictor

 Being able to specify number of connections for preconnect can make a
> difference and save seconds towards first display. The browser will of
> course have to limit connections used for preconnects, but if all you need
> is two connections towards one server to optimize first display then I
> think that is fine. As you say in the document it is expected that we will
> have to fall back to dns-prefetch for some connections anyway. Whether that
> is caused by author requesting  six preconnections to three servers or to
> six servers probably should not matter. See also my comments further down
> in the mail.
>
> Adding resource hints to redirects helps.
> Many web pages are already well optimized so benefits from resource hints
> will be smaller.
>

You must have a biased sample... most pages I look at could use a lot of
help when it comes to webperf. ;-)


>  Having a W3C spec would be nice.
>

Yep!

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.
>>>
>>
> I still think it makes sense to be able to program this. As I was testing
> this I had several instances where I tried adding a preconnect, noticed it
> still was not optimal, added a second preconnect to the same server and got
> the behavior I was looking for with a better/faster critical path. The UA
> can still make adjustments based on profile and available resources, but if
> the resources are available why not support it. The UA will of course still
> have to obey max connections per server.
>
>
>
>
>>>
>>>> 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
>>>
>>
>>
>
>