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:

In our last post Asynchronous Google Analytics is Better but Not Faster, we ran some tests using HttpWatch in Firefox 3.6 and IE 8 to see if the asynchronous version of the Google Analytics (GA) script was really faster as many have claimed.

We found the following:

1. Changing from the synchronous to asynchronous GA snippet make no significant difference in page load time over a typical broadband connection
2. When we tried simulating a slow download of the ga.js file, we did find that the asynchronous version of GA isolated the page from this potential performance problem – but only in IE.
3. When we simulated a slow download of the GA image beacon, we did not see a difference between the two versions of GA. In IE, the image always downloaded in the background without holding up the page load event. In Firefox, a slow GA beacon always held up the page load.
4. We found that the asynchronous version of GA completed the GA beacon request much sooner on slow pages allowing the analytics data to be collected even when the user left the page early

Our overall conclusion was that due to point 4) the asynchronous version of GA was worth using because you were more likely to get analytics data from slow pages. The only potential performance benefit we found was in item 2) but we ignored that because:

• It only applied to IE
• There’s a high chance the ga.js file will be cached (unlike the beacon file) before the user visits a page
• In our experience the components of GA always download quickly, often in a 100 ms or less on a typical broadband connection

One of the comments we received was that we should really have tested with IE 6 and 7 as those browsers are more prone to script blocking issues.

So, here are the condensed results of running the same tests in IE 6 and 7:

Do Pages Load Faster With Asynchronous Google Analytics in IE 6 and 7?

As before there was no significant performance advantage. Here are the IE 6 time charts with an empty cache:

And the IE 7 charts with a primed cache:

Would Google Performance Problems Have Less Impact With Asynchronous Google Analytics in IE 6 and IE 7?

We found that IE 6 and 7 behaved the same as IE 8 when we simulated the slow download of the GA image beacon. It didn’t matter which version of the GA script we used. The image always downloaded in the background without affecting the page load time:

When we tried slowing the download of the ga.js file, we found that IE 6 and IE 7 benefited from the asynchronous version of GA in the same way as IE 8:

Is Data More Likely to be Recorded by Asynchronous Google Analytics During Early Page Exits in IE 6 and IE 7?

Again, we saw the same behavior as IE 8. Using the asynchronous version of GA increased the chance of collecting analytics data when a user left a page early.

Conclusion

We found no differences in our tests with IE 6 and IE 7 compared to IE 8. Asynchronous GA is worth using because it increases the chance of gathering data from slow pages, but you shouldn’t expect to see faster page load times unless you encounter a slow, uncached ga.js file in IE.

So why doesn’t asynchronous GA deliver significant performance gains as widely claimed? We believe it is down to the following factors:

1. The synchronous version of the GA script is included at the bottom of the <body> tag minimizing it’s impact on the rest of the page
2. The files used by GA typically download so quickly that in most cases any improvement has minimal impact on the overall page load time
3. The asynchronous loading techniques don’t seem to work in Firefox for either component and only help with the ga.js file in IE