- From: Jonny Rein Eriksen <jonnyr@opera.com>
- Date: Mon, 10 Feb 2014 12:05:19 +0100
- To: Ilya Grigorik <igrigorik@google.com>
- CC: public-web-perf <public-web-perf@w3.org>, Patrick Meenan <pmeenan@webpagetest.org>, Yoav Weiss <yoav@yoav.ws>
- Message-ID: <52F8B26F.1040509@opera.com>
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