Ajax Performance

Ajax for the iPhone

While I’ve never really talked about platform preferences here, I should in the interest of full disclosure mention that I’m an Apple fan. Like many, I’m a relatively recent convert, and I came to Apple by way of Linux. OS X seemed like a perfect fit — everything Just Works, but you can drop down to a terminal and geek out if you so desire. So naturally I was following along closely with the Macworld keynote to see what Steve Jobs would sell me next. And since we have about 5 months until I can buy it, let’s consider briefly the implications of a few key design decisions, specifically as they relate to Ajax.

The demos of Safari were what impressed me most, and I agree in principle with the Safari developers when they talk about the impending end of the ‘mobile web.’ At least, I agree that Safari on the iPhone represents the end of an era where it was necessary to apologize for the mobile web. However, immediately after the keynote, potential early adopters started getting some bad news as word spread that 3rd party apps would not be welcome on the iPhone. Today, this was confirmed by Jobs.

The silver lining for those of us in the Ajax space is that we will have a captive audience of users hungry for innovative 3rd party software, and there’s no other way to deliver it than through Safari. We have the opportunity to create powerful new browsing experiences for mobile users, potentially using techniques such as Brad Neuberg’s incredibly cool work on the Dojo Offline Toolkit to provide seamless operation when a connection is unavailable.

So, while I agree with the Safari developers that the mobile web will hopefully no longer be the ugly stepchild, I don’t think the mobile web as a separate concept is necessarily going away. There will still be specialization of mobile apps, but instead of specialization to work around the inherent limitations of the platform, it will be specialization to build applications with all the richness and vitality of native applications. Ajax will play a huge role there.

Real world caching numbers from the YUI blog

A month ago, I linked to the first article in a ‘Performance Research’ series by the YUI folks in which they explored how the number of HTTP requests impacts application performance. The second part of the series looks at caching.

They start by providing the delta between cached and uncached performance for yahoo.com. Uncached comes in at 2.4 seconds on average while cached takes .9. Sounds good so far. Then they do some analysis of end user traffic patterns and turn up some fairly shocking numbers — between 40 and 60% of visitors and 20% of total page views had an empty cache. That’s a large chunk of humanity having an almost 3x slower experience.

Unlike the HTTP requests discussion, where the developer has control to address these issues directly, caching happens on the client side. There’s nothing we as developers can do except build applications that perhaps don’t rely so heavily on caching to save our bacon. Frequently, we assume that caching will turn our 300kB of client side code into a forgivable one-time hit for everyone. This post throws some cold water on that theory and suggests that we do more ongoing analysis to understand the caching experience of our actual end users.