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!

Hmm, what if you could run a server on your mobile? Jetty, the lightweight Java HTTP server has been ported to Android as i-jetty.

You can use Jetty to run server logic and Servlets right on the phone itself.

For example, you could take a Web based application and deploy it on the phone, and have the phone’s browser talk locally. Jetty also supports Comet style Web development, so your little Web browser based application could get some PUSH.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="org.mortbay.ijetty">
    <application android:icon="@drawable/icon">
        <activity class=".IJetty" android:label="@string/app_name">
            <intent-filter>
                <action android:value="android.intent.action.MAIN" />
                <category android:value="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

When Ars Technica first took a look at the Android SDK they had a few complaints.

Luckily, they came back, and took a look at the most recent release and were able to see improvements:

One very noticeable change in the Android user interface is the addition of transition animations. The animations show up in many places throughout the system, generally when windows, dialogs, and menus appear. They are very subtle and add some additional elegance without becoming a distraction.

I tested several of the applications that come with the SDK, including the mapping program, the contact book, and the web browser. I also tested the experimental Google Talk chat integration feature. I was able to connect to Google Talk and receive messages, which are displayed as items on the notification panel. The performance and usability of the bundled applications is pretty decent.

We have heard that Flash is coming to the iPhone even since before the iPhone launched. Gear Live say that it is definitely coming.

Why isn’t it on the iPhone now? They make out that it is due to business decisions, but my guess is that this isn’t the case. The iPhone came out swinging that “the browsing experience is full.” The browser is a desktop-esque browser. No WAP here please.

This means that you would expect to see true Flash instead of Flash Lite, which you often see on a mobile phone. However, Flash does eat up a lot of memory, CPU, and thus battery, so I think that the Apple folks have been playing with Flash and making it fast and economical enough to run on the device.

At certain times it has been frustrating not to have Flash. You feel crippled. On the other hand, it has also often been nice. No silly Flash ads etc.

If it finally does make it on the phone, it will open up the world of iPhone development to Flash developers which will be a big thing.

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

Opera has given a teaser announcement on Opera Mobile 9.5 where they have told us what to expect, but we don’t get to play with it yet:

• Uses the new Presto engine, so it should be faster
• Zoom around a la iPhone
• Flash support (Flash Lite only)

You can see a video tour.

What is most interesting is that it supports Opera Widgets, so you can develop one form factor and have it work as a widget for the desktop and the mobile phone.