Thursday, March 27th, 2008p>
Between cranking on Acid 3 tests, the WebKit crew has explained some issues in Optimizing Page Loading in the Web Browser:
It is well understood that page loading speed in a web browser is limited by the available connection bandwidth. However, it turns out bandwidth is not the only limiting factor and in many cases it is not even the most important one.
From the figure it is clear that while available bandwidth is a significant factor, so is the connection latency. Introducing just 50ms of additional latency doubled the page loading time in the high bandwidth case (from ~3200ms to ~6300ms).
Antti Koivisto goes on to explain why latency has such an impact, and how it is related to the browser having to figure out â€œall the associated resourcesâ€ for a page, and the bane of
Problems start when a document contains references to external scripts. Any script can call document.write(). Parsing canâ€™t proceed before the script is fully loaded and executed and any document.write() output has been inserted into the document text. Since parsing is not proceeding while the script is being loaded no further requests for other resources are made either. This quickly leads to a situation where the script is the only resource loading and connection parallelism does not get exploited at all. A series of script tags essentially loads serially, hugely amplifying the effect of latency.
And now where WebKit comes into the picture….. they have put in some nice optimizations:
The latest WebKit nightlies contain some new optimizations to reduce the impact of network latency. When script loading halts the main parser, we start up a side parser that goes through the rest of the HTML source to find more resources to load. We also prioritize resources so that scripts and stylesheets load before images. The overall effect is that we are now able to load more resources in parallel with scripts, including other scripts.