[webkit-dev] PreloadScanner aggressiveness

Antti Koivisto koivisto at iki.fi
Mon Jan 11 01:21:00 PST 2010

On Fri, Jan 8, 2010 at 3:00 AM, Mike Belshe <mike at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100111/14efb528/attachment.html>

More information about the webkit-dev mailing list