Ajax Performance

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.

Tab soup

I’m an inveterate RSS consumer, and I use the NetNewsWire+Firefox work-flow. I am also one of those people who can’t stand to have a message (in a news reader, an e-mail client, etc) marked as unread, so I tend to pop open a new tab for every new article, assuming I don’t have time to read it immediately. I almost never have time to read things immediately.

The net result tends to be a cyclical model where the number of open tabs builds over the span of the work week, starting of a low around 10 or 20 and ending somewhere around 100. Anything beyond 100 tends to put me into a danger area where Firefox will slow to a crawl, explode, etc. Over the weekend I go through a purge process, using some of that downtime (and the much lower velocity of incoming news articles) to read my way through most of my backlog.

Right now, I have 154 tabs open. That is a personal record and well outside of tolerances. Firefox may blow at any second. I have no time to get this down to a reasonable level between now and Friday, so I think I have no choice but to ride this thing out.

Dear Diary, I very much enjoyed The Rich Web Experience

I’m back from a whirl-wind west coast trip that involved the first 2 days of The Rich Web Experience and ended with a weekend in Vegas, at the wedding of one of my co-Gomezians. So, while he’s in Hawaii Twittering away, I’m doing both of our work and trying to get caught up on things. That lucky so and so.

Some brief words about the conference. First, Jay Zimmerman puts on a great show, and I was honored to be involved. It was a sweet venue, the presenters were top notch, and the interaction with the attendees was really gratifying. I’m disappointed I wasn’t able to stick around for the Saturday session, especially to see the performance tutorial by the esteemed Steve Souders and Tenni Theurer of Yahoo!

As with the Ajax Experience in July, performance was a hot topic. I was fortunate enough to sit on the opening panel discussion of the show, and I was thrilled to see how much of the discussion was driven by ‘yeah, but how do we manage these applications?’ type questions. That’s a challenge that we in the tools and developer evangelism spaces need to rise to, but it’s great to see the demand for solutions.

The first day of the show, I attended an excellent performance talk by Ron Bodkin, founder of New Aspects and creator of Glassbox. Ron spent a fair bit of time discussion operational management concerns (even giving a shout-out to Gomez, making him my new best friend). That evening, Ron and I chaired a BoF on performance and had a pleasant hour long chat with an interesting group of developers who are tackling Ajax development and management problems every day. It was heaven for a performance geek.

My presentation was the second day of the show, Friday. Another great thing about Jay’s NoFluffJustStuff shows is that he gives presenters plenty of time to work with. An hour is really not enough to cover a lot of ground — I hit 58 minutes during my last hour long show, leaving 120 seconds for Q&A. At RWE, Jay gave us 90 whole minutes of time to work with and rope to hang ourselves. It’s a cool format.

I got some great feedback from the attendees, including one that I want to pass along. Luke of iParadigms, who sat through all 90 minutes of my presentation and claims to be one of my 5 readers, pointed me to this presentation by Joseph Smarr of Plaxo at Yahoo! Again, Yahoo! is doing awesome work in the performance space, and their contributions to developer education and evangelism are legion.

You want more proof? I leave you with Steve’s “High Performance Web Sites: 14 Rules For Faster Pages”.

Quick follow-up: more YUI Compressor work

I recently posted about Julien Lecomte’s YUI Compressor work. He just pushed out a 2.0 build that fixes a number of issues and adds CSS minification.

I find myself posting about YUI work more and more recently. That team, and everyone at Yahoo, really appreciates the role of performance in building compelling Ajax experiences. They continue to push the community forward.

Update: Version 2.1 is already out.

Microsoft’s Ajax View

As I’ve mentioned in previous posts, I think client side instrumentation is critical to understand the performance of code running within the browser. We are all familiar with this approach at its most basic: new Date().getTime() metrics, displayed via alert. I’m also a fan of aggregating these results from end users as a logical extension of development-time instrumentation.

Of course, these approaches require manual instrumentation, and that may not scale adequately since it requires more work for the developer. Sometimes we want to do more broad spectrum analysis, to determine what areas of the application may be performance bottlenecks, what part of the city is on fire. Firebug’s profiler works well for this, but it is only available for Firefox. Sometimes the fire is in a different place from browser to browser, so we need a way to analyze performance across browsers and platforms.

There are a growing number of tools trying to serve that need. A few months ago I discussed jsLex, a tool that uses an ant task to instrument all JS in the source tree, with a server component to aggregate the metrics from your browsers. Microsoft has created something similar with Ajax View, a proxy-based solution that intercepts and instruments, based on policies you define, JS bound for your browser. Where this approach suffers relative to jsLex is that you must configure each browser to treat Ajax View as its upstream proxy, and that’s somewhat onerous if you have a group of developers, or an internal beta test network, hitting the application.

It’s always nice to see new performance instrumentation approaches. It’s an area of Ajax performance measurement that hasn’t been terribly well served yet, but there seems to be a lot of active research in the area now.

Perceived Performance work from YUI — ImageLoader

When I talk about Ajax performance optimization, I typically refer to optimization as a 3 stage process: reducing sources of network latency as far as possible, reducing sources of client side latency as far as possible, and lastly, hiding whatever is left. That last step is based on the assumption that, at a certain point, you will always hit a wall in traditional performance optimization as there is a certain amount of content to transfer and code to run client side. The techniques for hiding whatever is left tend to play in the area of ‘perceived performance,’ juggling the order of events such that the user sees an interactive and available application as quickly as possible.

An experimental new library from the YUI team called ImageLoader (as seen on Ajaxian) provides a perceived performance boost by allowing the developer to defer loading of images that are not visible on initial page load until they are necessary to complete the user experience. These images could either be outside of the viewport (”below the fold” as the cool kids say) or inside of hidden widgets. By deferring these objects until later, we restrict the number of network events, and thus the latency, before the user thinks the page is loaded and interactive.

The devil is in the details, of course, so the trick to making this work is ensuring that the images are loaded without blocking the initial page load but before they are actually needed. ImageLoader provides two techniques for loading these deferred images: triggering the load off of some event or loading after some fixed time interval. I’m not sure I love either approach as they both seem to err more on the side of giving the user a latency event later in the page to avoid slowing the initial load. I think I would rather start loading the content, at least in the above the fold case, as soon as all other networking operations had completed. This would be something more like a priority queue, or a “Mega Defer,” though that requires routing all network operations through some JS layer.

Regardless, it’s exciting to see the YUI team focusing on codifying these advanced performance techniques into libraries. Having well documented solutions opens fancy optimizations to a much broader range of developers.

Back at full strength, playing catch up

I got the joyous call that my laptop was ready for pick-up yesterday, and we’ve spent the last 24 hours getting reacquainted. It’s amazing how much cooler and more stable a system runs with 2 working fans instead of 0. I queued up a few links of interest during my forced hiatus (note: I could, of course, have blogged from another system, but it just didn’t feel right). You know that means: bullet time!

• From Julien Lecomte of the ever active YUI team comes YUI Compressor, a new JS minification tool built on Rhino. Early returns show a significant performance gain over existing tools in the space, though speed limitations make this tool appropriate for ahead-of-time, rather than on-the-fly, compression. Comments on Julien’s blog show a few bugs turned up by early adopters, but that’s to be expected at this stage.
• Let’s stay on Yahoo! for a moment, shifting to YSlow. Jeff over at Coding Horror took a critical look at the new Firebug plugin in an article titled “YSlow: Yahoo’s Problems Are Not Your Problems.” While careful not to discredit Yahoo!’s methodology, Jeff worries that the advice embodied by YSlow can lead developers down the path of unproductive or potentially dangerous optimizations, particularly in cases where the YSlow guidance is more appropriate for very large sites.
• I made a bit of hay pre-iPhone release by playing iPhone Ajax apologist. Two months in, how do I feel? Well, I’m still hopeful that iterative improvements to iPhone Safari will make it the development platform I was expecting, but performance numbers such as those turned up by Craig Hockenberry of Iconfactory worry me. We can’t expect developers to embrace the iPhone fully, despite the heroic efforts of Joe Hewitt, if native code on the iPhone holds such a huge speed advantage.
• I was going to talk about this article, but it really deserves its own post

Finally, I spent a chunk of time this weekend working on an article for IBM developerWorks. Expect more information as it gets closer to publication, assuming it doesn’t totally suck.

Pain and sadness

Today I relinquished my beloved MacBook Pro to the hands of a local Genius. Some hardware needs replacing, and they don’t know how long it will be. I knew that this day would come eventually, but I can’t say I was emotionally prepared.

The important thing is to put one foot in front of the next and just keep living. That’s all I can do.

Lazy Function Definition

From Peter Michaux comes a great article on the Lazy Function Definition pattern for JavaScript, an efficient way to use functional language coolness to avoid potentially expensive conditional checks or global namespace pollution. For example:


var t;
function foo() {
   if (t) {
      return t;
   }
   t = new Date();
   return t;
}

becomes

var foo = function() {
   var t = new Date();
   foo = function() {
      return t;
   };
   return foo();
};


That’s so clean. Of course, this specific example isn’t hugely useful from a performance perspective, but Peter also provides a page scroll implementation that likely would have a tangible speed boost.