This chapter takes the same approach to performance as Chapter 8 does for security. As with security, Ajax doesn't fundamentally change the principles of web application performanceit just adds some new factors to the equation.
Ajax can be a double-edged sword with regard to application performance. On one hand, the main promise of Ajax from a user-experience perspective is that it will speed up interaction. Think about the typical "live search" functionalitybefore Ajax, you'd type a search query, submit the form, and wait for the results page to be returned. With live search, every new keystroke fires off an Ajax request in the background, so that by the time you've finished typing your query, the results are already in front of your eyes.
Well, that's the idea anyway. The reality is often not so simple. Search is generally a computationally expensive operationespecially if you're doing a full-text search over a large data set. The Ajaxified search dramatically increases the load on the search operationinstead of one search for "Ruby on Rails," it would need to perform as many as 13 separate searches, one for each keystrokeand most of those queries will be ignored anyway. Unless your search infrastructure is prepared for the load, adding Ajax to improve performance might actually backfire, multiplying the number of expensive requests and causing the average response time to fall.
The point is that while Ajax is often a performance boon, it isn't a silver bullet. In this chapter, we'll consider the impact of Ajax on performance, and identify a number of "pain points" where performance problems often surface, and how they can be dealt with.