Ajax Performance

What is a page? Part 1

One of the benefits of working for a web performance testing company is that you work directly with customers who are pushing the boundaries of what is possible on the web. We started seeing our first proto-Ajax sites in 2003, though of course those were muddled messes of IE5+ proprietary code (DHTML Behaviors, anyone?). Fortunately, history hasn’t been kind to that approach, and the Ajax revolution of the last two years has been built on the pillars of W3C standards and graceful degradation.

We have made progress, and I believe Ajax is inevitable and nothing less than the future of the web. However, we are in the early days of adoption, and Ajax is still a relatively immature technology for commercial use. How can I tell? Let’s take a look at Ryan’s key indicators of immature technology:

• A fragmented landscape for the new developer The number of Ajax libraries outnumbers commercial Ajax sites. That’s cool — the zeal of the community is awe inspiring, and great work is being done to build out a broad and deep foundation for client-side development in the browser. So, choice is good, but too much choice is overwhelming to the senses. How is a web developer assigned to Ajaxify the existing portal by Joe PHB, CIO Magazine subscriber, to decide how to get her feet wet? In many cases she can’t, leading to…
• Reinventing the wheel There are a bewildering number of libraries on the market, none of which are established enough to demand the attention of the neophyte developer. And for the developer lucky enough to be assigned Ajax work, the temptation to cut teeth writing XHR code from the ground up is irresistible. At this point, I’m pleasantly surprised when I see a customer site that uses Prototype, Dojo, etc. Developers are writing their own apps from the ground up at least twice (make that thrice) as often as they are using existing libraries, in my experience.
• SLAs? What the hell are they? I was at an Ajax conference session earlier this year where a major web company was pitching their services for integration into commercial, for pay, mashups. I asked what guarantees they could offer about the service levels of their application since mashup builders would have real dollars riding on their performance (a hugely self-serving question for a web performance company employee to ask, I admit). The answer? “You can have an SLA, but it will cost you” along with some equivocation about how important performance is to them. If you ask the same question of DoubleClick or any other traditional web advertising provider, you will get a very different (and much more comforting) answer, and your contract will likely include clauses that amount to punitive damages if the provider can’t meet those guarantees. That’s a hallmark of a mature, commoditized space.

Immature is by no means a pejorative. Our current location on the tech adoption curve is wholly appropriate. These things take time, and implementing Ajax requires a significant shift in approach from web developers, testers, and operations groups. I think we are at the point where our early commercial adopters are starting to poke their heads up from developing their shiny new applications and wonder how exactly to apply their existing frameworks for understanding and managing those applications in production.

Over the coming days and weeks, I will talk about my experience working with customers who are making that shift. Hopefully, this discussion can help crystallize our collective understanding of managing Ajax apps.