Ajax Performance

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.

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.

Catching up on a few pending posts

I’m a borderline deranged user of tabs. I tend to start the week with somewhere between 20 and 30 tabs open and end with over 100, leading to a lengthy pruning session on the weekend or on flights. I almost never get below 10 as I frequently have a solid base of articles I want to blog about at some point but which I haven’t found the right time to cover yet. Right now, dear reader, I’m at 10, so join me as we discuss several months old stories on my voyage to coveted single digit territory:

• First up, an article from July 2nd (yes, we’re going way, way back) from vitamin on 5 tips for Rails optimization. The article explores the optimization of an Ajax based webmail application, and they were trying to optimize the main message list page, where clicks on items in the conversation list load and render the message body via Ajax. Although 3 of the entries deal exclusively with the backend, two of the entries involve strategies we’ve covered here from time to time.
  
  First, they realized that sending the full message down was a waste of bandwidth when much of the code was boilerplate HTML. One of the biggest culprits here was the tag cloud dialog, so they moved most of its code, now templated, into a hidden DIV. Ajax calls for new messages would return only the names of the relevant tags which would be applied to the template via regex and moved into the DOM wherever appropriate. This is a nice trick, but it’s purely focused on bandwidth savings and the incremental latency advantage.
  
  As I discuss incessantly, decreasing the number of requests made, especially those that fall directly in the line of user perception, is the best way to increase the responsiveness of your application. Using a technique similar to what we discussed with the JS LRU cache a while back, they created a mechanism for preloading messages behind the scenes as the application loads. When the user selects a message that happens to be cached, the load will be instantaneous. Since this cache is just a JS Array, one potential enhancement would be to use Gears or Dojo Offline to keep messages around from run to run.
• At TAE, Steve Souders used object-level performance data taken from IBM Page Detailer to explain why optimizing “front-end” performance (that is, the network and client side performance as experienced in a web browser) should be the first target for optimization. He makes the point over at the Yahoo! Developer Network, ending with his golden rule: “optimize front-end performance first, that’s where 80% or more of the end-user response time is spent.”

  Steve is also behind the YSlow project, and he participated in a demonstration webcast last week.

And, just like that, I have fewer than 10 tabs to contend with for the first time all year. Hooray for cleanliness!

TAE Wrapup

It’s been a week since returning from The Ajax Experience West, so I’m overdue to write up some thoughts. First: it was a blast. The first conference I ever attended or presented at was TAE East last year, and the several shows I’ve been to since have showed me just how lucky I was to start with the best. This was no different — a great collection of people, excellent presentations, and feisty panel discussions (Crockford. Eich. Fight!).

My presentation was the first day, and I was quite surprised to see that I was scheduled for the Plaza Ballroom, the big venue at the show. At my first TAE, my performance presentation was on the last day in one of the smaller rooms, and I’m certain that the upgraded slot I received this year is indicative of the increasing focus on performance and optimization in the community. Hell, there was a full track about performance this year, and Dylan’s wrapup went so far as to say “I believe this year’s theme was all about performance.” That’s great to hear, and that’s how it felt to me.

Patrick’s Selenium throwdown was right before mine on the same stage. Even though he completely failed to promo my session, it was really cool for little Gomez to have such strong representation on testing and optimization.

The nice thing about getting your presentation out of the way is that you get to spend the rest of the time enjoying the show and meeting people. It was great to see Brad again, and his presentation on Dojo Offline was awesome. Brent Ashley and Doug Crockford came to my presentation and both said they didn’t hate it. I also met Kris Zyp who, despite being alphabetically cursed to be called last in pretty much any situation, gave a very interesting talk on continuations and cooperative multi-threading in JS.

I also had a nice chat with John Resig about performance testing, and he explained the ins and outs of the CSS selector benchmark rat race. John was on stage almost constantly, and in his down time he was busy working, but he still made time to talk about his performance approach and his grudging involvement in the somewhat masturbatory (my words) micro-benchmark wars.

The last session of the week was Steve Souders, who I’ve mentioned before, introducing YSlow, an interesting Firebug integration that analyzes and grades your application performance. It’s a cool approach, and a nice way to make optimization strategies measurable and actionable.

OK, so this reads very much like a hyper kid writing in his diary after returning from summer camp, but to hell with it. It was a great week, performance was in the air, and the Ajax community is as vibrant as ever. Many, many thanks to Ben and Dion for allowing me to be involved. Can’t wait for Boston!

At TAE San Francsico

Just completed my presentation, and I’m having a great time meeting with everyone here. As always, Ben and Dion put on a great show.

Ajax developers rush to support the iPhone

Just a quick post in follow-up to my previous iPhone-Ajax lovefest: a couple of links from Ajaxian about already released Ajax SDK’s from Aptana and Morfik. Morfik even has an app ready for consumption: iChess.

With any luck I’ll be playing some iChess by 7PM tomorrow.