Ajax Performance

LRU Cache for JS

Two years ago, I built an Ajax interface for a message board. The design called for all navigation to occur within the context of one page. Message lists updated on a polling interval, and users could open threads, read messages within threads, or search by topic or user within that page. All of the content was loaded via XHR, some user specific formatting was applied, and the results were shown within a DIV.

Following what I have just now decided to call “The First Principle of Performance Optimization” — reduce network requests as much as possible — I put together a simple LRU Cache to store message bodies and other post-formatting replies. Knowing that users frequently come back to a given message or thread, this saved the network round trip as well as the formatting step to provide a snappier end user perceived performance.

The technique worked well, but my caching scheme was pretty unimpressive and unpolished: there were no priority levels and the expiration scheme was spartan. That’s why I was excited this week to see a much more fully realized LRU Cache developed by Monsur Hossain and released under an MIT license. It provides priorities for objects in the cache, two expiration schemes, and a callback function executed on object expiry, all with a sane and clean API.

If you’re in the market for a JS cache, this looks like a great choice.

(Update: somehow I forgot to give this a subject. Looked naked :-))

Performance work on the run-up to Rails 2.0

By way of the Ajaxian coverage of RailsConf 2007, it looks like the next major release of Rails will have two key performance improvements we’ve discussed here.

First up is JavaScript and CSS streamlining where all scripts and stylesheets linked to a document can be combined and gzipped with one command:

<%= javascript_include_tag :all, :cache => true %>
<%= stylesheet_link_tag :all, :cache => true %>

I discussed this technique briefly most recently here, though really that post is just a link to hard work done by someone else. As a refresher, this technique is useful because it reduces both the total bytes downloaded and the number of round trips to the server. As we continue to see, the best way to reduce the load time of a page is to reduce the number of trips back to the server. This is especially true in the case of JavaScript as these server requests are serialized, so we get no benefit from connection parallelism.

Speaking of connections, the second performance trick in Rails 2.0 implements the host renaming technique I discussed in detail here. The config syntax looks like this:

config.action_controller.asset_host = 'assets%d.highrisehq.com'

I have not seen a more detailed transcript of the presentation, but I hope the asset mapping is smart enough to remember what objects were mapped to what connections. That could lead to suboptimal balancing of connections used on a given page, but the alternative (potentially remapping objects to different hosts on each page) would blow caching all to hell.

Upcoming presentation: The Ajax Experience

I just received word that my presentation proposal was accepted for The Ajax Experience in San Francisco on July 25-27. The presentation topic is “Ajax Performance Analysis.”

I presented at The Ajax Experience in Boston last October, and it is easily my favorite conference series. The Ajaxian guys are great, the roster of presenters is awe inspiring (present company excluded), and the attendees tend to be with organizations pushing the bounds of the web experience. It’s a great crowd.

SmugMug beating the drum about performance

In his blog yesterday, SmugMug CEO Don MacAskill used aggregate performance metrics from Alexa to highlight his organization’s performance relative to others in the space. There isn’t a tremendous amount of meat here — Don promises to post a follow-up with more detail on their approach — but it is nice to see the role of performance as a competitive differentiator.

There is some fun in the comments section as CTO Warren Habib of Fotolog stopped by to quibble briefly with Don, but given that these are C-level execs it didn’t turn into the mud slinging competition we all love so much. As an aside for my own entertainment, it was nice to see my little firm mentioned briefly in the discussion.

Another technique for minimizing requests, image concatenation

Here at Ajax Performance, I spend a lot of time (here and here, for example) discussing the network-side implications of design decisions for the simple reason that there’s no better way to improve the perceived performance of an application than to do more with less bandwidth. Sure, increasing connection parallelism is a neat trick to hide some of that download pain, but fewer objects is always the best answer.

I’ve seen a few good articles in the past month that give me yet another excuse to beat this drum. First, Steve Souders, Chief Performance Yahoo! at Yahoo!, goes so far as to make it Rule 1 in his upcoming O’Reilly title, High Performance Web Sites. For reducing the number of image requests, particularly for small images used as icons, Steve recommends combining all images into a map and using CSS to display different slices of the combined image in place of discrete downloads for each icon. This technique is explored in depth by Matthew Batchelder in this excellent howto article. Great stuff.