Download and Buy Now Link

Blocked time and IE 8

March 31, 2008

A common question we hear from our customers is “What is the Blocked time in HttpWatch and why are we seeing some much of it?”

The Blocked time in HttpWatch is shown as a gray block at the start of a request:

Blocked Time

We measure this time by looking at the time interval between these two events:

  1. The point at which IE determines that it requires the resource at a certain URL. For example, it may have downloaded some HTML and encountered an <img> tag that refers to a GIF file.
  2. At some later time IE peforms a network action required to download or validate a cached copy of the resource.

During this time interval, IE will check the cache to see if the resource is stored locally, determine what headers and cookies would have to be sent in a GET request to the server, and if necessary, wait for an existing connection to become available.

Although, IE is multi-threaded and could start downloading many resources in parallel it is subject to a connection limit per host name. The HTTP 1.1 specification (RFC2616) recommends that HTTP clients should have no more than two connections active per host name. Therefore, a web page that has all its embedded images, CSS and javascript files on the same hostname (e.g. www.example.com) will only be able to use a maximum of two connections to download content.

Here’s a screenshot from HttpWatch that shows what happens when you force a refresh (Ctrl+F5) of our home page using IE 7:

Two connections per host in IE 7

At any one time, only two HTTP requests are actively downloading content. The rest are in the blocked state waiting for their turn to use one of the two connections to the web server. The two yellow segments in the first two requests indicate that two TCP connections were made to the server (a yellow segment in an HttpWatch time chart indicates the TCP connect time).

For many web pages this has a major performance impact and is a strong motivator for reducing the number of round trips whenever possible.

Microsoft has just released IE 8 Beta 1. One of the most significant changes compared to IE 7 is that the maximum number of connections per host name has been changed. If you are on a fast, broadband connection it now uses a maximum of six rather than two connections per host name.

BTW, if you are going to use HttpWatch with IE 8 Beta 1 please make sure that you download and install version 5.3.

This screen shots shows the six connections being made with IE 8 and the increased concurrency during download:

Six connections per host in IE 8

The increase in the number of connections leads to a major reduction in blocked time. We found that the load time for our home page, with an empty cache, is on average 50% less in IE 8 Beta 1 compared to IE 7.

Steve Souders, author of ‘High Performance Web Sites’, has written a blog post entitled ‘Roundup on Parallel Connections’ that discusses the connection limits of other browsers and the possible effect on existing web servers.

8 Comments

  • I think, you have mixed up the blocked time and the wait time. The wait time (Gray Band) is the time the browser waits to schedule a connection and the red band are server and network intrinsic?

  • Jose,

    In HttpWatch, we refer to the gray block as the ‘Blocked’ time, because the browser is blocked waiting for a connection.

    We refer to the red block as the ‘Wait’ time as this the period of time within which the browser is waiting for a response from the server. As you say, this delay is made up the server response time and the latency of the network.

    You could argue that these terms could be used the other way around, but that is the terminology we settled upon when we added the time chart feature to HttpWatch.

  • Interesting how the fact that proxy script time could be embedded in this time. I used other tools to confirm this since the 5.x version of HTTPWatch Pro that i use won’t single out the proxy download time which could be embedded in this blocked time.

    Of course you would see that only on the first request.

    We had issues with our proxy server environment and so this is how we pretty much deduced it, and using other tools besides HTTPWatch, since HTTPWatch is not deep enough with characterizing the proxy download time.

    Maybe a new version will have that soon? (hint hint)