On Fri, Jan 8, 2010 at 3:00 AM, Mike Belshe <m...@belshe.com> wrote:

Nice testing!

But for HTTP; the key seems to the pre-rendering-ready escape hatch in
> DocLoader::preload.  Removing this gives me most all of the benefit.  The
> comment says it pretty clearly:  "Don't preload images or body resources
> before we have something to draw. This prevents preloads from body delaying
> first display when bandwidth is limited."  For SPDY, there is more benefit
> by continuing to preparse aggressively - I suspect this is due to the finer
> grained prioritization where it can continue to send requests up without
> impacting the clogged downlink channel.
>

Yeah, this is currently really optimized for best first display, not for
total load time.

In my testing that escape hatch was pretty important for first display if
the case was bandwidth limited (several seconds on some major sites on 3G).
It is not surprising that it may somewhat hurt total load time in high
bandwidth/high latency case.

Ideally we would have per-site estimate of the current bandwidth and latency
values available so we could tune things like this dynamically.

Any testing of changes here should consider first display times too, not
just total load time.


   antti
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to