Widgets can be described as mini-applications, running code that binds itself to a web browser and/or the resident operating system to display information. Just like regular applications, widgets consume system resources such as processor cycles, memory, and network bandwidth, possibly slowing down other functions on your computer or across the network. In this post I will take a look at the resource utilization of desktop and web-based widget platforms across a few common widget applications.
Background
I bought a PowerBook in the summer of 2004 and moved into the world of OS X. Expose and Dashboard were completely new user interfaces compared to my Windows world, and I added many widgets of marginal interest to my Dashboard. I soon noticed my system slowing down as each widget carved out its own block of memory, from 4 MB or as high as 12 MB each. The problem was further compounded by widgets not utilizing the Apple-specific hooks for widget initiation, show/hide, and more. I scaled back my use of widgets and reclaimed a few more megabytes of memory for my other applications. I was now well aware of the consequences of a desktop Chia pet and dancing hula girl.
Today our always-on Internet connections and web browsers run always-on widgets. Can widget platforms differentiate based on resource consumption? I decided to benchmark a few major desktop widget and personal homepage products displaying an analog clock, my latest 5 photos from Flickr, my latest 5 webmail messages, and the weather forecast from San Francisco. These four widgets were benchmarked on my MacBook Pro containing a 2 GHz Intel Core Duo processor and 2 GB of 667 MHz DDR SDRAM and running Mac OS X 10.4.8 and Firefox 2.0. The tests were conducted around Thanksgiving weekend 2006 and represent the latest software versions and libraries available at the time.
Desktop test
Yahoo! Widget Engine used twice the memory of Dashboard, with 89 MB utilized compared to Dashboard’s 42.5 MB.
Picture Frame, the official Flickr widget bundled with Yahoo! Widget Engine, topped the scales at close to 39 MB of memory, 1.8x as much as the Dashboard widget. Dashboard delivered better mail functionality, showing the most recent message subjects as well as read/unread state compared to Yahoo’s unread count display.
Dashboard widget platforms can extract some functions to the GPU, rendering widget frames, photographs, and possibly the vectors of a clock on this specialized hardware. The version of Dashboard shipping in Apple’s next OS, codenamed Leopard, features process grouping, creating an even smaller memory footprint for widgets sharing common resources.
Personal homepage test
I tested Google Personalized Homepage, Microsoft’s Live.com, Netvibes, Pageflakes, and Goowy’s YourMinis as personal start pages which may persist throughout a user’s entire browsing session. Statistics shown factor out a resource utilization baseline of Firefox 2 displaying a XHTML 1.0 Strict “hello world” page. All tests were conducted while logged-in to the respective sites.
Google used the least memory, followed by Pageflakes, Netvibes, Live.com, and YourMinis. YourMinis is powered by Flash (version 9 on my machine) but is a good comparison against pure JavaScript as well as mixed JavaScript and Flash homepages.
The analog clock module was the most varied between sites. The most popular analog clock on Netvibes displays an ad on mouseover. The most popular Pageflakes clock spiked CPU utilization from 3% all the way to 16.4%. I expect the built-in analog clocks on Google and Live.com make better use of vectors but I did not look deeply into the cause of the resource spikes.
Each site uses their own JavaScript libraries, such as the Prototype framework in Netvibes or ASP.net Ajax in Live.com or Pageflakes. It’s possible for developers to write against these already loaded libraries instead of writing separate code of similar function. Hopefully each widget homepage will release browser usage statistics to help developers plan widget compatibility.
Summary
I took a brief look at mail, weather, time, and photo functionality across multiple widget platforms. The features were not uniformly implemented but provided a good cross-section of end-user expectations and interactions across multiple environments.
I expect more widget platforms will keep an eye on their most popular third-party widgets and either work with those developers to produce more optimal code or bundle the functionality into their own widgets. Widgets authored by the platform company are expected to perform well and protect user data better than a third-party and will likely receive better promotion in the sites’ widget directories.
We’re definitely at an early stage in widget development and I expect the introduction of Leopard and Vista early next year, and their associated IDEs will launch a new generation of widget development and optimization. I believe it will always be optimal to write against each platform individually, taking advantage of unique features, hooks, and user interface to deliver the best user experience in a small visual and system resources footprint.
My tests were by no means scientific, but instead were meant to replicate the experience of a user discovering and configuring widgets of interest for the first time. The “most popular” lists of each service remain the best way of discovering content of interest, and leverage a wisdom of the crowds mentality in an environment of multiple widgets for similar services such as time and weather. I’m guessing most users will select from the widget platform’s provided shortlist or the gallery’s most popular for each piece of functionality they desire. Keeping resource consumption low will help a widget keep its place in their desktop or homepage since no one likes a slow computer or their fans kicking in when they open a particular website.