In HttpWatch version 7.1 we’ve added support for Firefox 4.0 Beta 7 and made some improvements for the IE 9 beta.

The first change was driven by the minimal user interfaces used by the latest Firefox and IE betas. By default, no toolbars or status bars are displayed on which HttpWatch can add a button. This change makes sense as it frees up more screen space for displaying a web page, but makes it difficult to open HttpWatch without using a keyboard shortcut or reconfiguring the browser.

Our solution was to add an menu entry on the context menu in each browser:

The other major change is the use of the DOMContentLoaded event to add the DOM Load event to time charts recorded in the IE 9 Beta:

There are also seven new columns available for the main request grid including the page event timings (e.g. Render Start, Page Load, etc) and the values shown on the Network tab in the Summary window:

The page level summary data from these columns is now included in the CSV export:

A full list of the other improvements and fixes made in this release is available on the version history page.

We recently moved our blog from a Jumpbox VM to Windows 2008 R2 using the Microsoft Web Platform Installer. It makes setting up WordPress a doddle on Windows as it automatically installs and configures PHP, MySQL, IIS and WordPress in a couple of easy steps:

One performance benefit we got immediately was that HTTP compression was enabled by the installer in IIS 7.5 reducing the download size of any text based content:

In true dogfooding style we decided to use HttpWatch to look for some other easy performance gains. The first problem evident from the waterfall time chart was how the images in a typical blog post dominate the download process. Here’s the empty cache visit to the blog as seen by HttpWatch:

The relatively slow download of the blog post images is due to the fact that we’re in the UK, but our servers are in the US. It doesn’t really matter how fast an internet connection you use, the latency introduced by distance always has an effect on download speeds.

Content Delivery Networks (CDNs) provide a solution to this problem. They have servers located around the world that are able to serve cached content to web users with lower latency. We’re already a customer of MaxCDN so we fired up the control panel and created a new pullzone CDN that would serve content from our blog:

For convenience was also set up a new DNS entry for blogcdn.httpwatch.com that points at the MaxCDN subdomain:

We prefer to do that so that if there’s ever an issue with the CDN we can quickly point the CNAME back to the original source of the files.

The next step was to get WordPress to use the new hostname for the images we include in each blog post. There are several wordpress plugins that can do this but we settled on using CDN Rewrites as it allowed us to enter one simple rule:

This change caused a significant difference in the page load time:

Using a CDN like this provided two performance related benefits:

1. The files were downloaded much more quickly from the local CDN node than from the server in the US
2. Using a second hostname reduced the blocking of other resources on the same page

A few people have asked when HttpWatch will support the IE 9 Beta. We’ve got a few IE 9 specific enhancements planned, but the latest version of HttpWatch already works with it:

The IE 9 beta has a great new minimalist user interface. It’s so minimal in fact that it may initially give you the impression that HttpWatch is not available.

The default Tools menu:

is a cut down version of the normal Tools menu. You can access HttpWatch on the normal Tools menu by pressing F10 or permanently enabling the menu bar:

The HttpWatch toolbar button is still available but it’s on the Command bar and that’s hidden by default. If you permanently enable the Command bar then the HttpWatch button will always be visible:

If you prefer to keep the default IE 9 user interface configuration, you can still access HttpWatch by using the Shift+F2 shortcut key when the keyboard focus is in the web page itself.

IE 9 now keeps track of how much overhead each add-on contributes to the page load time (Navigation) as well as the overhead during the loading of a new IE window. This confirms that the HttpWatch add-on has no significant impact on the performance of IE: