Ajax Performance

Avoiding unnecessary Ajax traffic with session state?

Last week, IBM developerWorks posted an article suggesting the use of client cookies to communicate some information about the freshness of the data requested so the server can optionally return a 304 if no new data should be sent. There may be some edge cases where this approach is appropriate, but it’s probably not justifiable for the majority of apps.

If the response expected from the XHR is smaller than 10kB, the cost of retrieving the 304 is indistinguishable from loading the entire object, at least as far as network latency is concerned. The bandwidth consumed by the round trip request is also a meaningful, but small, chunk of the total object size, and you still bear the server cost of handling the inbound connection and request.

For cases where you are requesting large chunks of data frequently, this approach makes more sense, but it still feels like it’s just obscuring a problem with the application design. If you find yourself needing something like this, the easiest strategy to lessen the bandwidth impact on your servers is to tune down the client side polling interval. You could perhaps do this dynamically based on how recently you have received fresh data.

AjaxWorld article

Back in October, I mentioned writing an article for AjaxWorld magazine. It will be coming out in print form in early 2008 (I think), but you can read it now thanks to the magic of the webs. This is essentially the first half of my standard Ajax performance presentation, introducing the available tools.