Ajax Performance

Microsoft’s Ajax View

As I’ve mentioned in previous posts, I think client side instrumentation is critical to understand the performance of code running within the browser. We are all familiar with this approach at its most basic: new Date().getTime() metrics, displayed via alert. I’m also a fan of aggregating these results from end users as a logical extension of development-time instrumentation.

Of course, these approaches require manual instrumentation, and that may not scale adequately since it requires more work for the developer. Sometimes we want to do more broad spectrum analysis, to determine what areas of the application may be performance bottlenecks, what part of the city is on fire. Firebug’s profiler works well for this, but it is only available for Firefox. Sometimes the fire is in a different place from browser to browser, so we need a way to analyze performance across browsers and platforms.

There are a growing number of tools trying to serve that need. A few months ago I discussed jsLex, a tool that uses an ant task to instrument all JS in the source tree, with a server component to aggregate the metrics from your browsers. Microsoft has created something similar with Ajax View, a proxy-based solution that intercepts and instruments, based on policies you define, JS bound for your browser. Where this approach suffers relative to jsLex is that you must configure each browser to treat Ajax View as its upstream proxy, and that’s somewhat onerous if you have a group of developers, or an internal beta test network, hitting the application.

It’s always nice to see new performance instrumentation approaches. It’s an area of Ajax performance measurement that hasn’t been terribly well served yet, but there seems to be a lot of active research in the area now.