- From: Jonny Rein Eriksen <jonnyr@opera.com>
- Date: Tue, 04 Feb 2014 12:49:46 +0100
- To: Ilya Grigorik <igrigorik@google.com>, public-web-perf <public-web-perf@w3.org>
- CC: Patrick Meenan <pmeenan@webpagetest.org>, Yoav Weiss <yoav@yoav.ws>
- Message-ID: <52F0D3DA.7080800@opera.com>
On 30.01.2014 19:17, Ilya Grigorik wrote: > I've taken another run at the doc (substantial overhaul): > https://docs.google.com/document/d/1HeTVglnZHD_mGSaID1gUZPqLAa1lXWObV-Zkx6q_HF4/ > > - Merged use-case sections with each hint > - Added "proposed behavior" section for each hint > - Dropped "preload+lazyload" in favor of separate preload and prefetch > hints > > Would appreciate any feedback! Good work Ilya, it is looking better and better. 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. 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. 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. Having a W3C spec would be nice. Jonny > > 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 Tuesday, 4 February 2014 11:50:23 UTC