AJAX continues to raise user expectations for interactivity and performance, and developers are increasingly treating AJAX as a must-have component for their Web applications. As more code is moved client-side and the network model changes, the community is responding by building tools to address the unique performance challenges of AJAX. This article provides a working introduction to these tools and their use evaluating the performance of an AJAX application.

Developing AJAX applications is hard. For developers familiar with traditional Web applications, the transition to AJAX presents a wealth of creative opportunities but is also fraught with potential disaster. In particular, it's easy to write rich, interactive applications that are dreadfully slow. To avoid this fate, aspiring AJAX developers should embrace performance as a feature of the application, not something to deal with only when users start complaining.

This attitude shift is the cost of building fun new AJAX applications. Fortunately, the development community has created tools that make it easy for even the greenest developer to understand both the network and client-side components of AJAX performance.

Network Analysis
Since the earliest days of business on the Web, companies have managed their applications by monitoring the performance of the application across the network. However, this was mostly the domain of operations teams trying to make sure the application was available and performing adequately. Occasionally, this information would make its way back to developers as feedback on areas to optimize in future releases, but developers typically didn't spend too much time thinking about how many objects are loaded on any page, the order of those objects, etc. In some cases, developers or the QA team spend part of the release cycle load testing the application, but this is still more focused on defining or protecting the operational viability of the application.

This approach needs to change. The Web is increasingly a composite world, with third parties providing a mix of code and data to the application in the form of SOAs, CDNs, ads, and Web analytics. In short, you are no longer in direct control of everything sent from your server to the end user's browser. The performance of the application is now dependent on other factors outside of your direct control, such as the infrastructure of the third parties, changes to their code, and the network path between the third party and the Web browser. Unfortunately, end users only see your brand.

AJAX increases the need for developers to analyze performance. The great gift of the AJAX methodology is the flexibility of asynchronous network interaction. Successful AJAX applications do not just present richer interfaces; they present interfaces that hide network latency and feel as responsive to the user as a thick-client application. Think back to the first time you used Google Maps, to that "wow" moment when you realized that panning around the map did not require a page refresh. To build responsive applications, you need to be comfortable analyzing and optimizing all the network operations that happen behind the page.

The unfortunate reality is that, despite the potential of AJAX, it is perilously easy to provide horrible performance when building these more complex applications. First-time AJAX developers can easily fall prey to the siren call of all those shiny, fun new libraries, and, before you know it, an application intended to be more responsive is groaning under the weight of an embarrassment of scripts and stylesheets.

As with most things in life, the way to avoid this problem and realize performance goals is to collect more data. Fortunately, the development community has addressed this need by providing a number of fine network analysis options, all freely available. Network visualization tools allow you to peer inside the application and identify trouble spots in your infrastructure, determine the exact network cost of any third parties, and find ways to optimize the user experience.

Firebug
The first tool we will discuss is Firebug, a comprehensive development toolkit that should already be in your arsenal. Created by Joe Hewitt, Firebug is a tour de force of a Firefox Add On and originally grabbed developer mindshare with its impressive HTML and CSS inspection and editing tools. Version 1.0, released in November 2006, added graphical network monitoring that updates in real time while the page is loading.

Once installed, Firebug is displayed by clicking Tools->Firebug->Open Firebug in Firefox. The bottom half of your Firefox window will now contain the Firebug window. Click on the Net tab in Firebug, and then navigate to any URL in Firefox (see Figure 1). As the page loads, the Net pane displays each request in what is commonly referred to as a waterfall chart. This chart shows the order in which objects are loaded as well as the duration of each request. You can also inspect the request and reply headers and the reply message by clicking on its URL in the waterfall chart.

As good as it is, there are a few key limitations to Firebug's network analysis that leave it a bit short of being the only tool you will need for the job. The data in this waterfall is fairly high level: it doesn't include useful information such as what connection was used for the request or how much time was spent resolving hostnames. Also, the start time for each request is misleading since Firebug only knows the time at which the browser creates the request. What we really want is the time the request is sent over the network.

Most critically, Firebug is a Firefox-only tool, and conscientious AJAX developers need to understand the performance of their applications in all mainstream browsers.

IBM Page Detailer
Another free networking tool, IBM Page Detailer, provides far more detailed information by analyzing network traffic at the operating system level. Page Detailer works with Internet Explorer, Firefox, and other common browsers on Windows 2000 and above.

To begin collecting data with Page Detailer, install and run the application. Now, any page navigation is analyzed. Using Page Detailer takes a bit of patience, however, as the UI does not populate in real time. Typically, you need to wait 3 or 4 seconds after a page has loaded to see your results (see Figure 2).

Once loaded, you'll notice that the waterfall includes another dimension of performance information: each request is displayed as a line of color-coded bars. This is our much sought-after network granularity. Light blue is DNS resolution time, yellow is the time to establish a connection, dark blue is the round-trip time from sending the request to seeing the reply headers, and green is the time to receive the rest of the reply. Unlike the waterfalls seen in Firebug, this data also reflects the exact times that network operations occurred.

The cost of this accuracy is separation from the browser world of Firebug. The latency between loading a page and seeing data can be frustrating, and there are times when data never populates. While Page Detailer is the only tool for the job when you need complete, accurate network metrics, its lack of a polished feel leaves room for the browser-centric tools.

Client-Side Profiling
Earlier, we discussed why, due to new opportunities and complexities, AJAX developers need to focus more on network performance. Another significant challenge is managing the performance implications of moving so much code out to the client side. In pre- AJAX applications, it was fairly uncommon to have 1,000s lines of JavaScript running in a page. With AJAX, that is now the norm, and running all of this code takes time.

Anecdotal evidence from developers of complex AJAX applications suggests that fully 50% of the latency experienced by the user can be purely client side, so network optimization can take you only so far. Since the impact of client-side code is felt farthest from our traditional areas of control (our own datacenters), we need new tools to measure that impact. Fortunately, again, the development community is providing them.

Firebug
When Firebug added network analytics tools in version 1.0, it also added a world class JavaScript profiler, currently unrivaled in free tools. To profile a page load, click the "Profile" button at the top of the Firebug pane, then load a page in Firefox. Once the page has completed loading, click "Profile" again, and the Firebug Console tab will display a detailed performance table covering every JavaScript method called while loading the page (see Figure 3).

Working left to right, Figure 3 shows the function name, the number of times it was called (Calls), the percentage of total JavaScript execution time represented by this function (Percent), total time spent within the function (Own Time), and total time spent in this function and anything called by this function (Time). The Avg, Min, and Max columns provide statistical information for individual, rather than aggregate, calls to the function. The last column is a link to the location of the function: clicking it opens the function in Firebug's JavaScript debugger.

It should be noted that you are not restricted to profiling page loads. Imagine that you have built an AJAX interaction where a link click loads some JSON content via XmlHttpRequest, transforms the content into HTML, and inserts the result into a DIV. If you want detailed information on the performance of those steps, you can load your application, click Profile, click the AJAX link, and click Profile again once the DIV has populated. Firebug will show you the performance detail for that span of the AJAX interaction.

The ability to control profiling is nice, but it has its limits. Firebug shines as a broad spectrum analyzer, a way to look at the potentially hundreds of functions contained within the application and decide where to direct optimization efforts. Once you begin optimizing, though, you often want to focus on more granular performance metrics, sometimes within or across function boundaries in ways that are not easy to accomplish with Firebug.

As we saw with network analysis, Firebug is limited to Firefox. JavaScript performance can differ significantly across browsers, so optimizing for Firefox is not guaranteed to provide optimal performance in other mainstream browsers.

Firebug Lite
What we need is a tool for collecting specific, targeted performance metrics across a broad range of browsers. Again, Joe Hewitt has created an excellent solution in the form of Firebug Lite, a JavaScript library that provides a subset of Firebug's features across browsers. Including Firebug Lite into the application is as simple as unpacking the ZIP to a directory on your Web server and adding code similar to the code below.

<script language="javascript" type="text/javascript" src="/path/to/firebug/firebug.js"></script>

Firebug Lite adds a console object to the window scope and exposes several debugging APIs from the console. Of particular interest to us are the timing functions: console.time(name) to begin a timing interval and console.timeEnd(name) to end the interval. The name of the timing interval can be any value, as long as the same value is used for time and timeEnd.

As an example, I built a demo application that uses Dojo Charts to create a graphic purely on the client side. Dojo creates charts using VML on Windows and SVG on other supported browsers (currently Mozilla variants, Opera, and recent WebKit nightlies). Since different browsers use different implementations, I wanted to see the performance of rendering a chart in each browser, so I wrapped the render function in Firebug Lite timing calls, as shown below.

dojo.addOnLoad(function(){
    console.time('render chart');
    charts[0].render();
    console.timeEnd('render chart');
});

Firebug Lite creates a console area, hidden by default, that is displayed by hitting Ctrl-Shift-L (or ?+Shift+L on Mac). This console pane contains the results of any debugging or profiling calls you add to the application. Opening the console for my newly instrumented application (see Figure 4) shows a 5ms render time for this specific run.

Creating these timing metrics is as easy as writing a few lines of JavaScript code, but collecting and analyzing these results across browsers, with enough data points to be statistically relevant, can become tedious. My employer, Gomez, has created a third-party service that can intercept profiling calls from Firebug Lite running in real users' browsers and store them on a centralized server for analysis. Using this technique, I worked with the Dojo team to benchmark the performance of Dojo Chart across all supported browsers.

Summary
Developing AJAX applications presents new opportunities for performance excellence and performance tragedy. To deal with these challenges, the community has created a variety of tools for understanding both the network and client sides of AJAX performance. With knowledge of these tools, you can build rich applications that exceed your users' expectations.