Ajax Performance

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