Saturday, November 04, 2006

Increasing your Internet Explorer concurrent connections - and optimizing Page Load time

Here's a time-saving tip that will work to some peoples' advantage ...

Once upon a time, Internet connections used to be ever so slow, via slow dial-up or leased telephone lines: in the 1970s and 1980s 8 Kbps (kilobits per second) to 14.4 Kbps, later 28.8 Kbps or 34 Kbps. And in the late 1980s to mid-to-late 1970s -- with modem compression -- even up to a "blazingly fast" 64 Kbps (this was a nominal rate, but in practice it usually averaged around 40 to 50 Kbps).

In those days, when Internet Explorer came out [with Windows 95] it seems that Microsoft decided to strictly follow the standard for HTTP V1.1 (as laid out in RFC2616) and restricted an IE session to a maximum of two connections with any one server.

The effect of this wasn't too noticeable with those old, slow line speeds. Web browsing and file transfers were generally held back by the line speed rather than the connection limit.

But these days, with far faster broadband speeds, the effects of this connection limit are much more noticeable: once you have two downloads running, the next (third) one is suspended until one of the two active downloads finishes.

There's a tip at Microsoft for increasing the connection limit (to, say, 10 concurrent connections), but only use it if you're comfortable with editing the Windows registry. Refer to Microsoft support article 183110 ... WinInet limits connections per server

The article warns:

By changing these settings, you cause WinInet to go against the HTTP protocol specification recommendation. You should only do this if absolutely necessary and then you should avoid doing standard Web browsing while these settings are in effect.

However since I made the change several months ago I haven't noticed any detrimental effects -- but your mileage might vary! I can now run quite a few more than two downloads at once, which interleave nicely with each other thus reducing the overall elapsed file transfer time.

You will find other articles discussing this topic by doing a Web search such as:

UPDATE, 14 November 2006:
I just came across the following article by Aaron Hopkins: Optimizing Page Load Time which mentions the above (about the number of connections) but covers a much broader field, aimed at web developers. It starts off:

"It is widely accepted that fast-loading pages improve the user experience. In recent years, many sites have started using AJAX techniques to reduce latency. Rather than round-trip through the server retrieving a completely new page with every click, often the browser can either alter the layout of the page instantly or fetch a small amount of HTML, XML, or javascript from the server and alter the existing page. In either case, this significantly decreases the amount of time between a user click and the browser finishing rendering the new content.

While working on optimizing page load times for a high-profile AJAX application, I had a chance to investigate how much I could reduce latency due to external objects. Specifically, I looked into how the HTTP client implementation in common browsers and characteristics of common Internet connections affect page load time for pages with many small objects."
Aaron then gives quite a few tips, and finishes off with:
While the tips above are intended to improve your page load times, a side benefit of many of them is a reduction in server bandwidth and CPU needed for the average page view. Reducing your costs while improving your user experience seems it should be worth spending some time on.

1 comment:

  1. Number of concurrent connections is the next largest limitation for AJAX XMLHTTP development (after restriction to open another domains). This causes that if an AJAX application is open in several browser windows and 2 of the windows make request to the server, the instances of the application in other windows will queue their outgoing requests while one of the connections is released. The worst thing is that (as far as I know) there is no way to programmatically determine if there are any available "lines", so you would avoid sending the request and notify the user. And of course you can not abort the connection issued from another window.