Ajax Performance

Happy Sprite Day!

Good thing I’m sitting on a train to New York, enjoying WWAN connectivity, because Ajaxian seems to think it’s sprite day, posting links to no fewer than 3 articles on the optimization technique.

First, the self-described Big Dumb Developer analyzed the performance of the new .Mac Gallery, found it lacking, and suggested some improvements: in this case, image concatenation a la CSS sprites. However, I’m not totally sold that spriting is the appropriate optimization for this scenario. The numbers he provides for his technique, while gaudy, appear a bit soft — the timing mechanism only covers the client side performance of swapping in different images, as far as I can tell. Also, as one commenter on the blog rightly points out, this approach does not fill the cache with the individual images, so it’s quite possible you’ll need to redownload them in other parts of the application.

Finally, CSS sprites are more appropriate in cases where the size of the images being downloaded is very small; in that case, the latency of sending a request significantly outweighs the download time for each object, so we are looking to hide latency by combining objects into one (still small) image. In the .Mac case, each image is fairly large, so combining them into one even larger image isn’t a huge win, and we would need to wait for the whole thing to load before displaying anything.

A more appropriate optimization in this case, in my opinion, is to exploit connection parallelism using the CNAME hack. Given that there are hundreds of images, using 6 (IE max) or 8 (Firefox/Safari max) persistent connections in parallel is much better than the 2 allowed by default. With this approach, we are cutting latency by a factor of 3 or 4, the images will live happily in the cache (as long as we are careful to use the same hostname for an image every time it is called), and we don’t have to wait for all content to load before being able to display something.

The next article is from Glen Lipka, another of the great people I had the pleasure to meet at TAE last month, who hopes to improve the manageability and reliability of CSS sprites. After wrestling with the verbose CSS syntax necessary to make this approach work in current implementations, Glen provides several alternative approaches, with examples. His approaches also have the benefit of degrading gracefully in the absence of JS support.

Finally, sprites get a brief mention over at snook.ca, with a few links to articles explaining the approach.

Upcoming Presentation: The Rich Web Experience, September 6-8

I will be presenting at the Rich Web Experience in San Jose in less than a month, and I’m really looking forward to this show. I had to drop a number of slides from my TAE presentation as I was running long in my practice sessions — that shouldn’t be a problem here as I’ll have 90 minutes to work with. Also, every attendee gets a Wii or an iPod Video. That’s just nuts.

If you are interested, and you definitely should be, use the code rwe2007speaker200 to get yourself a $200 discount. It’s on me.

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.

iPhone developers are cranking

Greetings from Denver, where I’ll be until tomorrow evening for a wedding. With the trip, I haven’t had as much time to post, but I have enjoyed showing off my iPhone to my wife’s family. It definitely shows well.

I have been able to keep up with my reading, and as always there are a slew of iPhone development news items. First and foremost, Apple released their development documentation, a good sized collection of articles on device specific design and development information.

Building on top of personal experience and the help of this documentation, the development community continues to push ahead. And Joe Hewitt is among the leaders as always, recently releasing a native iPhone skin that puts web apps on a similar visual footing with native apps. This is achieved in part by using the WebKit CSS extension -webkit-border-image to lay out horizontally scalable buttons composed from a single image. This technique is covered in great detail in an article by Matthew Krivanek, where the performance benefit of the approach (fewer network round trips, our First Principle of Performance Optimization) is discussed.

Matthew’s example demonstrates 3 different buttons of different colors, but each is backed by a separate image. I wonder if you could expand on this image concatenation trick to place all 3 buttons in the same image (as discussed here) for even more EDGE round-trip avoidance.

A few thoughts on the iPhone, plus a news round-up

So I spent most of my first weekend with the iPhone enjoying the experience, just playing with the new toy. I was having so much fun that I almost forgot the 20 painful hours I spent waiting for the thing to activate. I’m not sure who is most to blame, but from following the thread on Macrumors it seems like people porting from Verizon were the most afflicted. AT&T certainly deserves a stern scolding for the extent to which their procedures fell down over the weekend (hour long waits on customer service lines, crashing activation servers which made their call center staff even more clueless, etc).

After that rough patch, it’s been an almost completely enjoyable time playing with the device. It’s a fantastic iPod, a better-than-expected phone (call quality has been great, but maybe my old Verizon phone just sucked that much more), and an amazing little computing device with a better-than-expected typing experience. Mobile web and mail are great, but it’s clear that we are in the very early days of the software:

• Safari has not been updated to 3.0 yet. I was hoping to repeat my Dojo Chart benchmark, but the lack of SVG support makes this impossible.
• SMS support is really nice, and it looks a lot like iChat for iPhone should look. Here’s hoping rumors of iChat in a forthcoming update are true (and let’s make sure it’s multi-protocol while we’re at it).
• JS performance looks pretty bad, according to numbers collected by fellow New Englander John Murch. The purely client-side JS numbers seem to be about two orders of magnitude worse than numbers pulled from Safari on a MacBook Pro. Assuming these numbers hold up, they put the 5 second limit on JS execution in a new light. Anecdotally, JS heavy apps like Google Mail feel slower (but not painfully so) than when running on a laptop, even when loaded over wifi.
• The inimitable Joe Hewitt has built the first beta of Firebug for the iPhone. It proxies console.log() calls over the network to be viewed in a Firebug console on another system. I would imagine that whatever SDK Apple releases will use a similar mechanism for debugging code running on the device, though I hope they also provide an iPhone emulator.

The big lesson here is to profile that Ajax code. Hopefully there are some performance tweaks coming in Safari 3, but the nature of this device means that some of the comfortable assumptions we tend to make in Ajax development are no longer true. The combination of a slow network (when not on Wifi) and a slower JS engine means that we need to be especially careful of how much code and data we send over the network as well as how much executes on the device. Attention to performance may well prove the difference between a usable iPhone app and an annoying one.

I got it!

Activating my iPhone now. I will post some observations once I make them. Some of them may even be performance related.

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.

In defense of Ajax for the iPhone

I suppose I have a more Ajax-centric view of the world than most, but I’ve been somewhat surprised over the past few weeks by the overwhelmingly negative reception to the iPhone development model I’ve seen around the blogosphere and from sites I love. The call for a ‘Real SDK’ is galling, and I think it reflects a prejudice against web applications and a lack of understanding of the progress achieved by the Ajax community in recent years.

I believe that Ajax on the iPhone represents nothing less than the future of mobile development, and we’ll look back on Apple’s decision to forsake a ‘Real SDK’ as an articulation of a bold and correct vision that perfectly fits where the market is heading. This isn’t the Newton; Apple is not ahead of its time.

To see why, let’s dive into the recent news and analysis, first catching up with our good friends at Ajaxian who continue to cover the Ajax angle as we near the iPhone release. Saturday they posted a roundup of articles by Joe Hewitt of Firebug fame and Robert X. Cringely.

I was happy to see Cringely’s article cover Safari on Windows as a move to improve developer support. Most of the discussion I’ve read elsewhere has focused on Apple’s slim chance of picking up significant market share. Coupled with the iPhone development environment, it’s clear that the real goal is to provide access to the WebKit platform to all developers to encourage first class support of Safari. The new Inspector released a few days ago is another (again, I’ll say it: sexy) part of that strategy.

Where I depart from Cringley is with his conclusion that, due to the difficulty of building applications that work consistently across browsers, Apple needs GWT as it is the easiest way for a developer of an existing web application to support Safari. This strikes me as almost silly as it assumes that everyone building Ajax applications is more comfortable with server side Java development. It’s far more likely that the easiest way to support a new browser is to test for it and make sure whatever framework you are using provides proper support. Chances are it does, and now you can do your Safari testing on Windows if you don’t have a Mac.

When you look at the momentum and commercial adoption of Ajax, it’s clear that the market for development frameworks is determined to overcome these challenges, and that says something profound about the advantages of the Ajax approach. That is, if developers are willing to deal with the annoyance of building complex apps on something as brittle as cross-browser JavaScript, there must be a damn good reason for it. And there is.

Flipping Cringely’s argument on its head, Ajax is successful because, despite the headaches of supporting applications across multiple browsers, it’s still a hell of a lot easier than writing and deploying applications natively on multiple platforms. The on demand software delivery model is compelling for reasons both economic and technical, and you need only look at the difficulty Microsoft had releasing a monolithic software package like Vista as opposed to the agility with which Google has pumped out release after release of Mail, Maps, and others. Ajax allows more applications which would traditionally have been only possible as thick client software to be moved to the on demand model, treating the browser as a VM for software delivery and execution.

The next logical stage of that evolution is offline access and syncing of code and data. Offline is necessary to solve the ‘What do I do when I’m flying cross-country and want to use my apps’ problem which has this far constrained Ajax to use cases that imply consistent connectivity. Offline support will also address one of the concerns Dion mention in the Ajaxian coverage — the latency of connections. Offline support is essentially a more robust and tunable caching model, so offline-enabled iPhone Ajax applications would be able to make connections across the network only as often as strictly necessary (and fundamentally, that’s the point of the Ajax model to begin with).

So, what Apple really needs from Google is Gears. With Gears, Google is very well positioned to address the offline question, and they have the partnership with Apple to deliver the native component necessary for proper offline support.

As I see it, the only other technical component necessary to make the iPhone SDK successful is access to unique iPhone functionality. As Joe Hewitt discussed on his blog, Apple will almost certainly provide access to iPhone specific features in the scripting engine of WebKit, and those features will allow developers to take full advantage of the rich interaction model provided by the platform.

Related is the concern that non-native iPhone apps will not have the look and feel of native code. However, Safari has long provided CSS3 features and enhancements to provide fine control of the presentation layer. This functionality was long overlooked in mainstream development because there was little reason to expend effort optimizing for Safari, but expect to see that change as developers target the iPhone.

This brings us back around to the criticism leveled by Cringley and others: developing for the iPhone, and the web in general, is difficult due to browser variation. Some worry about a return to the browser wars where the market fragments into competing, incompatible browsers and developers are forced to pick sides. This is not a compelling argument: at worst, a fragmented mobile browser market is only as bad as the fragmented market for mobile development we have currently. Also, these inconsistencies are precisely the niche that Ajax frameworks have rushed to fill, and there’s no reason to believe that analogues to YUI and Scriptaculuous will evolve to make interface design between mobile browsers as seamless as possible.

The web space is also very different than it was in those days — control is far more in the hands of the users and the web developers than the browser or device manufacturers. In fact, we are at the exact inverse of that situation; instead of web developers struggling to ensure that their application works well in whatever dominant browser they choose to support, browser developers now worry that Youtube, Google Maps, or any of the myriad other must have applications will work in their software.

But perhaps the most important factor behind the inevitability of Ajax for the iPhone is the way it opens development to such a broad community. Traditional mobile application development, with its ‘Real SDKs,’ is restricted to the few with the time or inclination to develop for a specific device. The iPhone’s model means that anyone with the time and inclination to build a web application is an iPhone developer. Certainly there will be a spectrum of applications, from web applications you happen to use on an iPhone to those that have been tuned for the interaction model and presentational features of the iPhone, but again, frameworks should make it easy for all developers to move towards the end of the spectrum that approximates native applications.

The iPhone is one of the first mobile devices, and definitely the first with a cell phone form factor, to provide a true browsing experience. But in a few years I expect all mobile devices to provide the same browsing experience. With that, the line between traditional and mobile web development will further blur, with Ajax frameworks helping developers deliver consistent and appropriate experiences on each.