Disclaimer – I use the Flash Platform to develop applications. I’m also excited by recent developments HTML5, CSS3 and JS. This is purely an attempt at balancing out the argument that Flash and not the types of content it drives is responsible for additional battery usage on devices. The problem is implementation.

In its review of the Macbook Air recently Ars Technica stated that using Flash resulted in a 33% reduction in battery life, a figure that has since been used by a number of anti-Flash campaigners and others to justify its demise in favour of a combination of HTML5, CSS3 and Javascript.

I thought I’d take a sample of some HTML5/CSS3/JS demos and measure the effects they place on my CPU. I was doing these tests on a Intel Core i5 iMac using Safari 5 – on a mobile device CPU usage is only part of the battery life equation but the harder you work the CPU, the less battery life you can expect.

A few points to begin with:

• I’m not trying to make some sweeping statement about the real-world effects these results would have on battery life, nor am I going to pretend this was in any way scientific, it’s merely to demonstrate that rich content doesn’t come for free, regardless of the technology driving it
• I’m not attempting to create a Flash vs HTML5 post either – I’ve seen real-world tests where HTML5 outperforms Flash, and vice-versa. Both have benefits and disadvantages
• Similarly, I’m making no judgements or comments on the quality or efficiency of the demos shown below, they were all done by very talented people and the demos themselves are prime examples of what’s possible with HTML5, CSS3 and Javascript
• For all these tests the methodology was the same – open Safari 5, then run the demo and take a screenshot during the demo
• Finally, apologies for the lack of a LightBox view for the grabs, must fix my WordPress

Starting off, here’s Apple’s home page – it’s running a simple CSS transition in the Store div, but only taking 0.4%CPU -

Next, one of Apple’s own demos of another simple CSS3 transition, I didn’t quite catch the transition happening in the screenshot but the CPU is at 15.5% just after the transition completes;

Next, Apple’s VR demo – as I scroll the content, CPU averages about 20%;

Over to Andrew Hoyer’s blog now, with his demo of CSS3 animation, maxing out at an impressive 4% CPU;

Moving onto the <canvas> tag now. This draws directly into the browser using Javascript.

Firstly, the Voronoi demo from www.chromeexperiments.com. This demo takes up nearly 100% of my quad-core CPU;

Another <canvas> demo,  Deep Sea Stress – I added 5 ‘creatures’ here and ran the demo, 97.8% CPU;

A simple <canvas> gradient effect, 53.3% CPU;

A <canvas> particle effect, 27% CPU;

Ball pool by Mr. Doob, 27.7% CPU;

Finally, I tried a HTML5 game, Infiltration at Dusk, to see what the real-world effect was on CPU. It ran at around  41.5% CPU;

Conclusions

I like to see and experience rich content on the web. If I didn’t, I’d go read a book and save battery power that way. I expect that content to take CPU and memory and in return provide me with better experiences, and I understand this has implications for battery life. Here’s Apple’s own information on battery life for iPhone:

iPhone 4 can get 10 hours of video playback, or 40 hours of audio playback on a full charge at original capacity. In addition, iPhone 4 features up to 300 hours of standby time.

Why? Because decoding audio requires more CPU than standby, and video uses more CPU than audio. Even with dedicated decoding chips the device has to work much harder to display the rich media over static content.

A large part of the problem is that the Flash Platform is over-used by advertisers and this has a significant effect on CPU load. I hate Flash adverts as much as anyone, not least because they have given Flash a good degree of its bad reputation on the web. Multiple instances within a page, multiple tabs and windows compound the problem further. The reality is that if Flash is replaced by another technology like HTML5/CSS3/JS, the tests above demonstrate that any rich-media technology will require more processing power to render that content, versus plain text. It has the same potential for abuse too; it’s equally possible to write bad Javascript as it is to write bad Actionscript. There are so many factors involved that measuring the actual effects accurately will be difficult – some of these demos ran much faster in Safari than they did in Chrome, and vice-versa. Similarly I realise that Flash runs less optimally on OSX than Windows, but that debate is out of scope here.

Finally, a note about mobile devices – all of the above tests were carried out a desktop machine with a fast processor and 8GB of memory. On a mobile device the demos would be subject to much higher constraints/limitations. Some of the demos ran at well over 50% of CPU, and would either not run at all on a mobile device, or be very taxing on CPU and battery life. That’s the trade-off though – again I can accept that I can’t expect to run all rich content on my smart-phone, but I should be able to run some of it while knowing I will be using more battery when I do.

It’s the same as the difference between standby and talk-time to me.

Update 1: On the subject of HTML5 adverts, here’s a link to a HTML5 ad page, deliberately non-optimised and typical of the kinds of Flash advert used everywhere. On my machine this page took over 90% CPU. Thanks to John Auger for the link. See how your system performs.

Update 2: I tried the excellent HTML5/Flash Pong demo, and here are the results. As I stated before it’s not my intention to try and compare the two technologies, but as some people seem to think that guesswork is a good enough reason to assume HTML5 is less taxing on CPU, real-world results might be more credible. The developer says there’s a known performance issue on Safari, so I’ve posted the results for Chrome and Safari, but in my testing Flash outperforms <canvas> for CPU load here by a factor of around 4. Chrome actually seemed to be slightly worse than Safari in my tests.

Safari:

Chrome: