Ajax Performance

Catching up on a few pending posts

I’m a borderline deranged user of tabs. I tend to start the week with somewhere between 20 and 30 tabs open and end with over 100, leading to a lengthy pruning session on the weekend or on flights. I almost never get below 10 as I frequently have a solid base of articles I want to blog about at some point but which I haven’t found the right time to cover yet. Right now, dear reader, I’m at 10, so join me as we discuss several months old stories on my voyage to coveted single digit territory:

• First up, an article from July 2nd (yes, we’re going way, way back) from vitamin on 5 tips for Rails optimization. The article explores the optimization of an Ajax based webmail application, and they were trying to optimize the main message list page, where clicks on items in the conversation list load and render the message body via Ajax. Although 3 of the entries deal exclusively with the backend, two of the entries involve strategies we’ve covered here from time to time.
  
  First, they realized that sending the full message down was a waste of bandwidth when much of the code was boilerplate HTML. One of the biggest culprits here was the tag cloud dialog, so they moved most of its code, now templated, into a hidden DIV. Ajax calls for new messages would return only the names of the relevant tags which would be applied to the template via regex and moved into the DOM wherever appropriate. This is a nice trick, but it’s purely focused on bandwidth savings and the incremental latency advantage.
  
  As I discuss incessantly, decreasing the number of requests made, especially those that fall directly in the line of user perception, is the best way to increase the responsiveness of your application. Using a technique similar to what we discussed with the JS LRU cache a while back, they created a mechanism for preloading messages behind the scenes as the application loads. When the user selects a message that happens to be cached, the load will be instantaneous. Since this cache is just a JS Array, one potential enhancement would be to use Gears or Dojo Offline to keep messages around from run to run.
• At TAE, Steve Souders used object-level performance data taken from IBM Page Detailer to explain why optimizing “front-end” performance (that is, the network and client side performance as experienced in a web browser) should be the first target for optimization. He makes the point over at the Yahoo! Developer Network, ending with his golden rule: “optimize front-end performance first, that’s where 80% or more of the end-user response time is spent.”

  Steve is also behind the YSlow project, and he participated in a demonstration webcast last week.

And, just like that, I have fewer than 10 tabs to contend with for the first time all year. Hooray for cleanliness!