Successful AJAX-based applications provide a better end-user experience than traditional Web sites. Fast performance is absolutely essential to deliver on this potential. The large number of technologies and the additional complexity that AJAX adds to the mix creates significant headaches in tracking down performance bottlenecks and related issues.

So where do you start tracking down performance-related problems? The answer is logical: by delving into the raw performance data of your application. Perhaps a pedantic suggestion, but by not adequately analyzing and measuring the data, you're relying only on hunches and past experience. Fortunately, we now have a number of highly useful open source and commercial tools available to assist us in this tedious process.

The best place to begin a thorough search & destroy mission is with HTTP-level performance problems that can be resolved in server configuration and fine-tuning. Is the caching configured properly? Are there issues with load balancing? How many concurrent requests per server before performance suffers? AJAX applications typically reduce the data size per request, but highly aggressive polling can saturate your servers with too many requests.

When using the Apache Web server, two useful open source tools are Apache Bench, which is great for concurrency testing, and Tsung, which provides a replay proxy mode to monitor system performance under a variety of scenarios. Similar commercial and open source tools exist for other Web servers as well. Push the limits of your servers and find out what makes them fall down.

As AJAX applications become increasingly common, users expect real-time updates to accompany their real-time experience. To be effective, real-time or highly collaborative applications require a significant amount of AJAX polling to make the application work. If this is simply too demanding on your Web server, you may want to consider switching to a Comet server implementation such as Cometd, Lightstreamer, KnowNow, or lighttpd. Comet servers are optimized for longer-lived connections and higher volumes of concurrency than typical Web servers.

A general rule of thumb with polling: if the response time for a request is comparable to that of your polling interval, you're either polling too frequently, or your server is taking too long to return useful information.

The performance of SQL queries is essential to any AJAX application as is the Input/Output (I/O) performance of your database. Bonnie++ is a useful tool that helps you quickly track down disk I/O issues. SQL query performance is the topic of hundreds of articles, but sometimes simple EXPLAIN statements and a healthy dose of query log analysis will suffice to slow or eradicate performing queries.

Analyzing performance over the Internet and verifying that you're getting the correct data from the server to the browser is the next step in your quest. A number of tools exist to assist with this analysis. Wireshark, formerly known as Ethereal, is a network protocol analyzer that provides complete insight into all data across the wire for your computer or network. LiveHTTPHeaders, a Firefox extension, allows easy viewing of all normal HTTP traffic, XMLHttpRequests, and Comet traffic, including the viewing of full headers in the Firefox browser. Firebug, a debugging extension for Firefox, among its many capabilities, lets you view not only script errors and XMLHttpRequest information, but also measures the load times of various resources such as script and image files.

For those of you waiting for me to get to the JavaScript-specific performance optimization techniques, we've arrived. With AJAX applications, many of our performance issues happen before we even get to the code that's executed in the browser. Now that you have effectively ruled out issues outside the scope of the Web browser, it's time to take a closer look at your JavaScript code. If you're using an AJAX toolkit such as Dojo, you may already have profiling code to supplement Firebug. For example, a Dojo contributor recently found an instance where the code to create a chart was calling attr.nodeName.toLowerCase() 540,000 times, consuming 15s of time at page load! Moving this one line of code inside a loop drastically fixed the performance of the Dojo Charting component.

Looking specifically for code that's called a lot of times or that takes a lot of time per call are the first places to investigate. Seemingly harmless calls to code in your libraries can be expensive operations, especially when iteration, recursion, and/or large data sets come into play, and a quick performance profile will expose these resource hogs.

It's easy to get caught up in the excitement of using a solid JavaScript toolkit, and forgetting that your application doesn't have to use every feature provided in your toolkit of choice! And even if the toolkit or browser lets you do something, it doesn't mean it's an effective use of system resources. For example, Dojo provides an excellent aspect-oriented programming (AOP) advice system for method-to-method event connection. However, you should only be using this when necessary, not in every instance that one method needs to call another one, since the cost for each connect instance is more than a simple method-to-method call.

Assuming that your toolkit has helped you avoid memory leak issues prevalent in Internet Explorer 6, and to a lesser extent Firefox 1.5, there's still a limit on the number of objects that can be instantiated in memory at once in any browser before you experience a significant drag on performance. Our general experience is that Safari 1.2/2 allows the fewest number of objects, Internet Explorer 6/7 are better, and Opera and Firefox are significantly better than that. It would be great to see a quantitative study that compares the memory consumption and relative performance limits of object instantiation.

In further evaluating browser performance, you should be looking for expensive operations that cause CPU spikes, excessive memory consumption, or leaks, and seek out alternative or more efficient approaches. Unfortunately, each major browser's JavaScript and DOM implementations are different, and what works well in one browser doesn't necessarily perform well in another.

When looking at the initial page load time, significant consideration should be given to the number of requests and the size of each request being made on the server. One large file is preferable to a large number of small files, provided that you aren't preloading a large amount of code that's rarely used by your application. The Dojo package system and build tools solve this problem for Dojo users, and Dojo ShrinkSafe is useful with any JavaScript code. For image files, it's worth considering the construction of image sprites to reduce the number of requests for small image files.

Predictive auto-fetching of images is another optimization technique. This technique was made popular by the Google Maps team. In this application, images of locations just outside the boundaries of the currently viewable map region are loaded in the background after the application has finished loading.

In analysis, it's important to note that synchronous requests to a Web server block execution and give the user the perception of a hanging browser. So embracing best practices for asynchronous application development is crucial in creating sophisticated Web applications. That said, too many concurrent asynchronous requests can lead to similar issues, so appropriate queuing of requests is a good practice.

Browser-specific issues are a significant reason for the proliferation of AJAX toolkits. Unfortunately, not every browser inconsistency is solved by your toolkit alone. For example, Internet Explorer by default enforces a two-connection limit per server, but it's possible to work around this issue with the clever wildcard-masking of aliases. Additionally, caching of images loaded by JavaScript in Internet Explorer requires significant workarounds when your application design contains many image files. Browsers literally have thousands of quirks and idiosyncrasies, so starting with a good toolkit and regularly reading developer blogs and Web sites will keep you "in the know" on the latest workarounds.

Given that AJAX applications are intended to be faster and more feature-rich than traditional Web sites, it's imperative that speed and performance aren't lost in the excitement of adding new capabilities to your existing app. I've only scratched the surface of what's required and what's possible in optimizing performance, but with a little patience, a good set of tools, and an understanding of HTTP and current browser issues, you'll have a good process to begin eliminating performance issues before they turn into performance nightmares.