Re: [resource hints] preconnect, preload, prender

On 07.02.2014 18:04, Ilya Grigorik wrote:
> 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?

I instrumented the client.

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

I wanted to see if it was possible to load Alexa top 500 sites and see 
if resource hints could be applied automatically. It is probably 
possible but quite complex. So I decided to focus my efforts elsewhere.


>     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. ;-)

Ah, yes. It was very biased, I loaded mobile sites only and focused on 
first display. :)

>     Having a W3C spec would be nice.
>
>
> Yep!
> ig
>
>>
>>     On Wed, Jan 22, 2014 at 3:30 PM, Yoav Weiss <yoav@yoav.ws
>>     <mailto:yoav@yoav.ws>> wrote:
>>
>>
>>
>>
>>         On Wed, Jan 22, 2014 at 9:09 PM, Ilya Grigorik
>>         <igrigorik@google.com <mailto:igrigorik@google.com>> wrote:
>>
>>             On Mon, Jan 13, 2014 at 4:17 AM, Yoav Weiss <yoav@yoav.ws
>>             <mailto:yoav@yoav.ws>> wrote:
>>
>>                 On Wed, Jan 8, 2014 at 7:32 PM, Ilya Grigorik
>>                 <igrigorik@google.com
>>                 <mailto: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
>>             <mailto: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 <mailto: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 <http://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
>>
>>
>>
>
>

Received on Monday, 10 February 2014 11:06:01 UTC