Mikko Pervilä has released a thesis for his MSci at the University of Helsinki titled Performance of Ajax Applications on Mobile Devices:

This thesis evaluates the presentational capability and measures the performance of five mobile browsers on the Apple iPhone and Nokia models N95 and N800. Performance is benchmarked through user-experienced response times as measured with a stopwatch. 12 Ajax toolkit examples and 8 production-quality applications are targeted, all except one in their real environments. In total, over 1750 observations are analyzed and included in the appendix. Communication delays are not considered; the network connection type is WLAN.

Results indicate that the initial loading time of an Ajax application can often exceed 20 seconds. Content reordering may be used to partially overcome this limitation. Proper testing is the key for success: the selected browsers are capable of presenting Ajax applications if their differing implementations are overcome, perhaps using a suitable toolkit.

There is a large amount of detailed information here across several vectors.

Mobile device / platform differences

Mikko has gone into detailed testing on the Nokia 800, N95, and the iPhone. Within the N800 he tests Opera, Mozilla, and WebCore. On the N95 he tests Opera Mobile and the mini map interface.

Ajax libraries and their support

Here Mikko compared a large number of libraries:

• Prototype
• Script.aculo.us
• jQuery
• Yahoo! UI
• Dojo
• Ext JS
• Gears
• DWR
• MooTools
• moo.fx
• ASP.NET Ajax
• Frost Ajax library

Comparing large websites on mobile phones

Here Mikko runs up against properties such as:

• Gmail
• Google Maps
• Yahoo! Mail
• Flickr
• myAOL

You can look through the study to see the details, but what about conclusions?

One can not yet assume that applications sup-
ported by the desktop browsers would be consequently supported by the mobile
browsers. Browser fragmentation seems to flow over to the mobile devices
with the shared code bases of the mobile and desktop user agents.

If we take a look at the grouping of grades for the various tests, you see that the browsers in question are across the map. All of them have issues, across the board.

Mikko does have this to say about the browsers:

By far, the fastest browser is Opera Mobile on the N95. This seems to be well in line with the overall worst capability in the capability evaluations. This combination seems to be indicative of ignored program directives, meaning that the browser gains speed by not executing some parts of the application code. Safari’s high number (14) of slow results is caused by the browser’s distinctive performance variation, specifically of pairwise high and low values. This phenomena has not yet been satisfactorily explained.

The two things that strike me are:

• Mobile browsers are very different, and I hope they get closer (feels like a few years back with desktop browsers)
• There is room for a mobile specific toolkit (or a mobile piece of a current toolkit) to help out like they did in desktop land. Frost is an early library here.

As you go through the thesis you will see a great set of graphs that show you the performance characteristics of micro elements of the Ajax experience on the phone. Thanks for the work Mikko!

Wayne Shea and Tenni Theurer have continued their performance series by delving into the iPhone and its poor little cache.

I always wonder why the cache is so small. It is typical Apple to not allow an expert mode where you can tweak it. I would rather have a few less songs and have a large cache. But, Steve knows best

The end result of the article is that you should follow this ideal rule:

Reduce the size of each component to 25 Kbytes or less for optimal caching behavior

Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world. To reduce the number of HTTP requests, Safari on iPhone supports image map, CSS sprites, inline images and inline CSS images. Take advantage of the browser cache whenever possible. If an external component can be shared across multiple pages in the site, remember that each individual component has to be smaller than 25 KB to be cacheable. Also, the maximum cache limit of all components is 475 - 500 KB. Minify all the JavaScript, CSS and HTML. For components that aren’t shared across multiple pages, consider making them inline.

This of course is quite painful if you like to package JavaScript in One Large File for other performance reasons, or if you use a library that is larger than 25KB!

The iPhone can tell us a bunch of things about a site. If I go to TechCrunch for example, it drives me batty as it does a bunch of JavaScript to load in the CrunchBase widgets, and the iPhone keeps thinking it is loading. The blue bar keeps going, and the browser isn’t as responsive. I hate those Crunchbase widgets