The latest update to HttpWatch adds support for Firefox 14 and includes a new AttachByTitle method on the Controller automation class:

Previously, it wasn’t possible to attach HttpWatch to instance of IE created by the Selenium browser automation framework because Selenium doesn’t provide access to the IE’s IWebBrowser2 interface. The new AttachByTitle method makes it possible to attach HttpWatch to any instance of IE or Firefox so long as the page has a unique title.

For example, here’s the sample code included with HttpWatch 8.4 that demonstrates how to use a unique page title with Selenium:

// Use Selenium to start IE
InternetExplorerDriver driver = new InternetExplorerDriver( pathContainingIEDriverServer);
 
// Set a unique initial page title so that HttpWatch can attach to it
string uniqueTitle = Guid.NewGuid().ToString();
IJavaScriptExecutor js = driver as IJavaScriptExecutor;
js.ExecuteScript("document.title = '" + uniqueTitle + "';");
 
// Attach HttpWatch to the instance of IE created through Selenium
Plugin plugin = control.AttachByTitle(uniqueTitle);
 
driver.Navigate().GoToUrl(url);

If you wanted to use Firefox, Selenium and HttpWatch together the only change required is the use of the FirefoxDriver class instead of the InternetExplorerDriver:

// Need to base Selenium profile on an existing Firefox profile that has HttpWatch enabled
FirefoxProfile defaultProfile = (new FirefoxProfileManager()).GetProfile("default");
IWebDriver driver = new FirefoxDriver(defaultProfile);
 
// Set a unique initial page title so that HttpWatch can attach to it
string uniqueTitle = Guid.NewGuid().ToString();
IJavaScriptExecutor js = driver as IJavaScriptExecutor;
js.ExecuteScript("document.title = '" + uniqueTitle + "';");
 
// Attach HttpWatch to the instance of Firefox created through Selenium
Plugin plugin = control.AttachByTitle(uniqueTitle);
 
driver.Navigate().GoToUrl(url);

You can find these sample programs in the HttpWatch program folder after you install version 8.4:

Earlier this year Mozilla shifted from releasing a new version every year or so, to once every six weeks.

So in the previous four years we had five major new builds of Firefox, but this year we’ve already had versions 4, 5 and 6.

Releasing often seems like a good idea; unless you’re in a controlled corporate environment or you develop extensions for a living.

While changing to this new model, Mozilla largely gave up on backwards compatibility to speed up their development process. In the past many interfaces were said to be ‘frozen’ meaning that script based and native binary extensions could rely on using them at any point in the future. That’s all changed so anything can be updated. There’s no guarantee that code in an extension will work with a new version of Firefox.

For native binary components like HttpWatch the picture is much worse. Binary components must be recompiled to work with each new release:

That means it’s impossible for us to ship a version of HttpWatch that will work with a future release of Firefox. Also, we have to add at least one new DLL to our install program for every new Firefox release. It’s not just developer centric tools like HttpWatch that are affected. Even consumer focussed add-ons like RoboForm need updating for every Firefox release.

Of course, Chrome has always been frequently updated but it has a much smaller extension ecosystem because it doesn’t have the range of APIs available in Firefox or Internet Explorer. Therefore, the frequent updates to Chrome don’t cause as many issues because there are less extensions and the extension API is less likely to change as it is so much more restricted.

In comparison, Microsoft has been the master of backwards compatibility across versions of Internet Explorer. For example, HttpWatch 3.2 was last compiled nearly 5 years ago but still works with IE 9 on Windows 7:

IE’s longer release cycles and excellent backwards compatibility really appeal to corporate users compared to Firefox’s new release model.

There was even some talk of increasing the frequency of the Firefox releases to once every five weeks or less. The resulting discussion on Slashdot gave rise to these negative comments about the change:

Have they totally lost it? It’s not like the browser world is making sudden great progress. It’s a mature technology. The big problem today is getting stuff fixed.

Sorry i have other things to do than repackage FF for deployment every 5 weeks.

What FF user actually wants this model? Most of them don’t. Releasing at the same speed as Chrome isn’t going to win over Chrome users, but it will chase FF users off. That’s what we’re seeing here.

If they keep this up, I will remove it from our labs. I am not going to deal with this s**t. Release bug fixes as often as you need to, but new features need to be something that doesn’t happen too often. I can’t go and test this s**t every few weeks, nor do I want to deal with things that are outdated. I like FF, but this policy they have is pushing me to dump it. I haven’t yet, but we’ll see.

Extensions stop working at random without any good reason and in record time. So many of us use Firefox over Chrome because of extensions. This plan is just terrible.

Of course, we are biased because short release cycles for Firefox create more work for us. What do you think?

[polldaddy poll=”5521932″]

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