Ajax Performance

Making Ajax Applications Scream on the Client

From Ajaxian, a nice presentation by Cyra Richardson of the IE team at MIX 2007 last year. The presentation covers both network and client side performance, and it should come as no surprise that the client side suggestions are more focused on IE.

Here’s hoping that some of these discussions of IE inefficiencies are finding their way into the design of IE 8.

Worst. Santa. Ever.

At my parents’ house in Charleston for Christmas, and someone broke into our garage and pilfered our cars. The only thing they stole was my iPod, but I need to get a replacement before making the 16 hour drive back to Boston.

Despite that annoyance, Merry Christmas to all! I have a number of updates I’ve queued up to post, and my New Years resolution is to clear that buffer.

Jash: An alternative to Firebug Lite

I hadn’t heard of Jash until today, but it’s a nice alternative to Firebug Lite for cross browser console debugging. What I like:

• Jash can be added to a page via bookmarklet, so you can use it on pages you don’t own. This is a fun technique for analyzing the architecture of other sites, and Jash makes it easy to do this in multiple browsers. It’s possible to tweak Firebug Lite to do something similar, but I appreciate that bookmarklet support works out of the box for Jash.
• The bookmarklet approach can also be used to inject libraries into any site, allowing you to explore each page with the benefit of JQuery, Dojo, or Yui, for example.

I use Firebug Lite a lot, but it’s hard to escape the feeling that it’s an afterthought, at least next to the brilliance of Firebug proper. A tool like Jash demonstrates that there’s more room for innovation in the cross browser debug space.

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.

Perceived performance work in GMail

From Ajaxian comes news of some really cool work by the GMail team. In a new release, which is trickling out to users in the coming days and weeks, they’ve refactored the app to increase code reuse with other Google properties and (more interesting for our purposes) aggressively optimize performance. I’ll let one of the Google devs, Dan Pupuis, explain:

We have also been fanatical about speed. Even on a fast Internet connection, it can take a second to request and render a new web page, and when you read a lot of mail, these seconds can accumulate to hours waiting for email to load. We’ve spent a lot of time profiling all parts of the application, shaving milliseconds off wherever we can, and figuring out workarounds for some pretty deep-rooted issues with the current browser implementations. Some of the most common actions should be faster now. For instance, we prefetch messages in the current view, so when you open an email your browser doesn’t have to talk to Google’s server; it just displays the message. These techniques really shine on newer browsers and computers. Using an alpha version of Safari 3 on a MacBook, we’re seeing sub-200ms times when opening messages—pretty quick.

Cool stuff. One of the most important (and often overlooked) areas of performance optimization does not involve real optimizations at all: it involves hiding latency from the end user. When I talk about performance strategies, I focus on a 3 step process: reduce network latency as much as possible, reduce client side latency as much as possible, and hide whatever is left. At a certain point, the marginal returns on true optimization dwindle to nothing, so we need to think about what the user sees and do what we can to reduce the amount of latency perceived by the user to only that which is absolutely necessary.

This is exactly what Dan is describing with the anticipatory message prefetching. While the user is looking at the message list, for example, pull down each individual thread and queue it for display. All of this will be invisible to the user, but when the user clicks a message to display, network latency (and much of the parse phase) will already be completed.

Google Maps does something similar with perceived performance — an extra band of image tiles is loaded for the area immediately surrounding the visible area. Since users very frequently drag the map in the same immediate area, Google exploits this spatial locality to anticipate and prefetch so that local panning is instantaneous.

The Ajax Experience wrap-up, and October is over!

As I mentioned previously, the Ajax Experience Boston ‘06 was the first conference at which I ever presented, so it was nice to celebrate that anniversary last week. As always, it was a great show with excellent presentations from the Ajax community’s best and brightest. Also a nice opportunity to catch up with Kris, John, Brent, and the other Ajax rock stars I’ve had the pleasure to meet in the past year. I gave my normal performance overview presentation (slides) on the first day to a refreshingly inquisitive crowd who hit me with a number of great questions at the end, a few of which I could answer.

On another note, TAE and the Gomez offsite that took up the rest of the week were the end of my hellish October (which included flying this itinerary in 9 days), so I can rededicate myself to nerdly pursuits. Hopefully that means more posts here at the ‘Perf.

Finally, it wasn’t all crazy travel this month. I found time to write an article for AJAXWorld Magazine which should be available online this week and in print probably 01/08. It serves as a companion piece to my TAE deck.

Busy October

I’ve been traveling more than usual this month, having just returned to Boston after visiting London and Portland, Oregon in the past 4 days. So I’m very excited that one of my favorite conferences, the Ajax Experience, is coming to my home town next week. A great show, no travel. Also, my first conference presentation ever was at the Ajax Experience in Boston last year, so this is a big anniversary for me. I hope to see you all there!

But before I can enjoy Ajax@Home, I have one more trip to make, this one to San Antonio for the Rackspace Customer Conference where I’ll be participating in a panel discussion on SaaS.

Ajaxian talks to Steve Souders about YSlow, Firebug, and performance

Dion over at Ajaxian spent some time with Mr. Souders, Chief Performance Yahoo!, covering a range of topics:

• Most interestingly, the new version of YSlow, 0.8, optionally patches some misleading behavior in Firebug’s net panel regarding cached entries. This is Steve, so there’s one heck of a write up for the bug. The man is thorough.
  This is a good fix for Firebug, but my biggest pet peeve with the network panel is the incorrect start times for object requests. The start times reflect the point at which the DOM parser queues up a network resource to be requested, not the point at which the request is sent over the wire. The latter number is far more useful for optimization, but knowing Steve, YSlow 0.9 will fix that one too.
• Dion also sat down with Steve for a 6 minute chat and dropped it on Youtube. Hit the Ajaxian article to watch the video. It’s a great introduction to YSlow and the work Steve has been doing for the past 3 years.
• Finally, Dion has a great write up of Steve’s presentation from the Future of Web Apps.

Low Level JS Performance Analysis

Bob Buffone, of Nexaweb, Apache XAP, jsLex, and RockStarApps.com (he’s busy), spoke on “Performance Tuning Your Ajax Application” last week at AjaxWorld. Fortunately for those of us who regrettably missed the show, Bob has written a companion piece to the presentation, covering many of his findings. He also posted a page with the client side performance code, so you can collect the metrics on your own browsers and dig in for yourself.

Bob compares different low level techniques for accomplishing common actions in JavaScript, such as using ‘for in’ versus C-style for loops, and he ranks this performance across browsers. In the process, he stumbled over a number of different performance anomalies and performance cliffs in his testing, and he has kindly summarized those as well. This is really cool data, fresh from the trenches, and great analysis for any developer who is focused on client side performance.

Also, Bob takes a moment at the end of the article to agree with my criticisms of Joel. Lesson to my readers: if you post an article agreeing with me about something, there’s a good chance I will link back to you