I’ve been researching browser architectures for a European operator and started looking at JavaScript performance issues. For the technically minded who enjoy getting into browser architectures, the latest developments in the webkit Javascript interpreter - SquirrelFish - make interesting reading, as posted on the Surfin’ Safari blog. SquirrelFish actually uses the very latest in interpreter and virtual machine techniques, much of it inspired by the Lua programming language. There are lots of useful references from the SquirrelFish blog post.

Whilst faster interpreters are great, we shouldn’t overlook the basic realities of working in the mobile domain, which are often slow connection speeds and slower processors. It is remarkable how often this still gets overlooked and some sites will attempt to push huge amounts of unnecessary JS code down the pipe, much of it never accessed by the site (but part of a library).

The basic principles of real-time processing still apply, which include the consideration of the entire delay budget - each step in the entire chain of events needed to complete a task. Not much point in speeding up the part of the process that accounts for the smallest amount of delay in the first place, as it won’t have a great impact overall. This is often why 3G handsets, especially low-cost ones, can still present poor browsing experiences, not much better than their 2.5G cousins. Fetching the page might be three times as fast, say, but the fetch time doesn’t account for the majority of the budget and the browser itself might render very slowly.

[This blog has moved to here]