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.