Thursday, March 27th, 2008

The importance of bandwidth versus latency

Category: Browsers, Performance, WebKit

<p>

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 document.write():

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.

The situation is made worse by scripts that load additional resources. Since those resources are not known before the script is executed it is critical to load scripts as quickly as possible. The worst case is a script that load more scripts (by using document.write() to write <script> tags), a common pattern in Javascript frameworks and ad scripts.

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.

Related Content:

Posted by Dion Almaer at 7:22 am
3 Comments

++++-
4.4 rating from 19 votes

3 Comments »

Comments feed TrackBack URI

The ability to 1) load other resources in parallel with scripts and 2) re-order resources to optimize download and rendering times are the biggest performance improvements I’ve heard of from the latest round of browsers. Optimizing downloads (increased parallelization) and fast JS execution (esp. DOM interaction) are the keys to making today’s web apps faster. It’s great to see these teams so focused on performance.

Comment by souders — March 27, 2008

This is great news! I wonder what the firefox guys are doing about this.

Comment by sovtek — March 27, 2008

Latency is very important. This is why when downloading a large, single file (such as a software trial) getting a local mirror doesn’t matter that much, as the total time will be much the same.
Having a local server for continuously browsing a site with many small resources is of much greater benefit as there is less latency for each request and the site will be noticeably faster.

Comment by mike08 — March 30, 2008

Leave a comment

You must be logged in to post a comment.