Ajax Performance

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.