Ajax Performance

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

CSS sprites made easier

Ed Eliot and Stuart Colville, in preparation for the release of their forthcoming (early ‘08) book titled “High Performance Web Site Techniques,” are planning to release a set of utilities through their companion site, website-performance.org. The first is a CSS sprite generator, a web app which takes an uploaded .zip of images and generates both a spritemap and the CSS rules for each sprite.

At the Rich Web Experience, someone in my session asked whether there are tools to help out with the tedium of building CSS sprites, and I didn’t have a great answer. This is a great tool, and I’m looking forward to whatever is next from Ed and Stuart.

Questioning Joel’s latest Strategy Letter

Last Tuesday, Joel Spolsky offered up his latest Strategy Letter, arguing by analogy to an earlier era that software optimization in the Ajax world is wasted time:

The developers who put a lot of effort into optimizing things and making them tight and fast will wake up to discover that effort was, more or less, wasted, or, at the very least, you could say that it “conferred no long term competitive advantage,” if you’re the kind of person who talks like an economist.

The analogy that Joel makes compares finely tuned Ajax applications to a bygone version of Lotus 1-2-3, which took ages to ship and lacked critical features due to laborious optimizations in assembler world to compensate for inadequacies in the target platform. The developers failed because, in the time it took to develop the app, hardware costs dropped and made more featureful, resource intensive apps tenable. Joel posits that someone will build a new, resource intensive meta-library which compiles to JavaScript in a way that sounds very GWT like. Though performance will suck at first, these issues will be rendered irrelevant as “new versions of the browsers come out that support cached, compiled JavaScript.”

Since I can safely rely on Joel never reading this entry, I’ll say with confidence that this is a deeply flawed analogy. I think it misses by overstating or improperly characterizing two separate forces which serve to pull the current trends in very different directions than Joel expects.

First, the release cycles for new applications and libraries are much, much shorter in the hosted model. While Microsoft could afford to release a few incredibly slow versions of Excel before the hardware caught up, that would be a lifetime for a startup trying to hawk a new library in the Ajax world. For something to perform as poorly as Joel suggests, it would need to boast unfathomably amazing features to justify getting market share, and enough of our libraries are useful enough that it’s hard to imagine anything so unspeakably better.

Second, and far more importantly, Joel’s comparison hinges on updates to the development environment, such as improvements in processor speeds, that occur on roughly the same timescale as new releases of the software. As I just said, hosted software is released much, much more quickly than client apps, for a range of reasons. At the same time, the rate of change in the browser world is at least an order of magnitude slower than system performance improvements. IE6 to IE7 in 7 years versus Moore’s Law? There really is no comparison.

In fact, I would argue that we are in the exact opposite of the scenario he envisions. We are in a world where browser development occurs at an absolutely glacial pace, at least as far as the bulk of the installed base goes, compared to hosted application development.

If Joel wants to posit a gnarly new SDK to end all SDKs, how about one that allows novice developers to build applications that perform incredibly well on the crappy browsers we’ll have to support for the next 5-10 years? That is a vision more in line with our present reality.