Ajax Performance

Current concerns with Ajax

I was honored to receive a question from a reader about what concerns me with the current state of Ajax development, what looms as an unresolved issue. I was doubly honored to see that Michael Mahemoff received the same question.

It probably comes as no surprise, but performance and focus on the user experience is my biggest concern with Ajax. The original motivation for Ajax, the reason it had such a visceral ‘Wow!’ factor the first time we saw Google Maps, is that it has the potential to require the absolute theoretical minimum of network usage: once the application has been loaded, only the data necessary to service user interactions must be sent over the wire. Further, those updates can be handled unobtrusively and with minimal perceived latency. The problem is, that goal is difficult to achieve, and most developers don’t have the tools, process, or experience to know quite how to attack the problem.

I work with Ajax developers who cover the spectrum of experience, from neophyte to rock star, and focus on performance is typically reserved for the high end of the curve. The truly savvy developers move beyond making functional and accessible applications to making fast and supportable applications. They employ advanced techniques like structuring the application so that the content necessary for a page to be perceived as ‘interactive’ is loaded as early as possible, with supporting logic streamed in unobtrusively at DOM ready time, for example. And most importantly, they test the hell out of these performance optimizations, as well as any new features and functions, before and after shipping the application to production.

There are a few factors in play which conspire to keep performance focus in the domain of the very experienced. First is that Ajax development has historically been very hard. New and intermediate developers are focused on building an accessible, cross browser application that employs Ajax techniques to enhance user experience. The skills required to make this happen are considerable, but toolkits, development tools, documentation, and training are gradually making this plateau more attainable.

Development tools brings me to the second constraint on performance focus. Without adequate tools, the browser is largely a black box, and it’s easy to add hundreds of kB of library code, botch cache and compression settings, overuse connections, or otherwise commit the little sins that add up to poor end user performance. All of these are difficult to see at development time where latency to the application, probably residing on the same intranet as the developer, is so low.

I think Firebug helps partially address this issue, especially as 1.0 adds network latency visualization and JavaScript profiling — you can really see how all the pieces fit together. Unfortunately, those features are Firefox-only, but they are such a competitive advantage for Firefox that I expect Firebug to redefine our expectation for development tools. Internet Explorer, Safari, and Opera will need to provide similarly capable applications in the future.

The major weakness of Firebug, as with any development tool, is that it can only provide insight from the developer’s perspective, and it’s difficult to extrapolate those insights into an understanding of end user experience. Without the tools and process in place to set and manage performance goals, from the end user’s perspective, development tools can only do so much.

This lack of end user understanding leads me to the final issue, the extent to which Ajax development increasingly involves tying together content from multiple disparate sources directly within the browser. Applications are increasingly composite, and our understanding of the total performance of the system decreases as we add third party logic and data into the application. A development time analysis tool can provide some insight into application performance, but we need a broader suite of cross browser tools for use from initial development, through pre-deployment QA, and for the lifetime of the application in production.