Ajax Performance

Is this ironic? Do you think? [Update]

A site with ‘Performance’ in the name, performing horribly. I have a ticket open with my hosting provider.

While we wait for resolution, feast on this chunky load average:

ajaxperf@slice:~$ uptime
07:55:12 up 1 day, 22:43, 10 users, load average: 55.28, 56.66, 80.70


UPDATE: They moved me to a different host, so performance looks much happier now.

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.

Real world case study in slimming down bandwidth consumption

One issue I keep coming back to here is the hidden, cumulative cost of bandwidth as traffic scales. Another case study showed up a few days ago from Jeff Atwood at Coding Horror. Using traffic patterns from a popular article published in February, he found 4 useful techniques for bandwidth optimization: offload images to a third party, use HTTP compression, offload RSS hosting, and compress JavaScript and CSS.

Offloading images ties in well to my discussion of connection parallelism back in December. Loyal readers will recall the tip for using DNS wildcards to trick the browser into assigning more connections to your host, but that does nothing to reduce your bandwidth costs. The solution I suggested is appropriate when you want to maximize connection parallelism and have bandwidth to spare.

Images hosted by a third party are allocated two connections, and none of the bandwidth tracks back to your infrastructure. I’m curious whether any of the third party hosts allow you to make use of the DNS hack to also get the benefits of 6 connections over their pipes. That would truly be the best of both worlds — outsourced hosting and as much parallelism as the browser can handle.

Jeff recommends using Amazon S3 for image hosting, and that echoes what I’ve heard from numerous other users. At $0.20 per GB transferred, it’s hard to argue with the economics. This is a great solution if you have the time or energy. If anyone knows whether DNS wildcarding works with S3, I would love to hear about it.