Re: [resource hints] preconnect, preload, prender

On 13.01.2014 13:17, Yoav Weiss 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.
> * 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.

Agreed, that makes sense to me as well.

> * "Prefetch hints should be interoperable with Link headers to allow 
> simple FEO / proxy optimization" - That would indeed be extremely 
> helpful for FEO proxies
> * In the use-cases section, shouldn't the "prefetch" section be 
> renamed to "preload+lazyload"?

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:

Loading yahoo.co.jp I normally get first display after 4.9 seconds. With 
2 prefetches and 4 preconnects I get first display after 3.0 seconds. 
This site is what I consider decently optimized, but I have relatively 
high latency from Norway to Japan, hence the high first display time. 
The page completes load after about 9-10 seconds, with resource hints 
this becomes 7.5-8.5

Loading 163.com I normally get first display after 43-58 seconds (from 
Norway, hopefully it is better for the sites target audience). With 3 
prefetches and 4 preconnects I get first display after 12-23 seconds. 
This site is ranked #17 in Alexa, but gives a lot of problems on load 
from Norway. Probably due to IP address issues. Anyway, with a simple 
ruleset it becomes 2-4 times faster. Page load complete varies a lot but 
improves well with hints.

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 hints are given on a redirect, what should happen in the main 
document? Should we specify that if a document has 2 preconnects then it 
should not trigger more of those if the same preconnects are also found 
in the main document?

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

For the yahoo test it was beneficial to support two connections for the 
preconnect.

Next I intend to test more with local fast sites but reduced bandwidth 
in a more typical EDGE/3G setting.

Jonny Rein Eriksen
Opera Software