JavaScript Performance On Mobile Devices

While working up a blog post today on creating a simple game with HTML5 , I tested the app on my iPhone and found something quite interesting.  It was ridiculously slow.

You can check out the application here and see it’s performance on your mobile device.  It appears to have trouble with drawing to the canvas on iOS.  The premise of the game was to have multiple images floating up on the screen at the same time.  Lots of drawing to the canvas taking place.  In an attempt to reduce the drawing, I used two canvas laid on top of each.  One for the background and one for the beach balls.  This meant I only had to draw the background once and could leave the other canvas for the repeated draw at the browser frame rate.

<canvas id="background" width="640" height="480"
 style="position: absolute; left: 0; top: 0; z-index: 0;"></canvas>
<canvas id="balls" width="640" height="480"
 style="position: absolute; left: 0; top: 0; z-index: 0;"></canvas>

This did not help at all.

It’s Not A Canvas Problem.  It’s a JavaScript Problem.

As it turns out, iOS JavaScript performance is pretty shoddy when compared with modern desktop browsers.  Below is a performance test I did according to the SunSpider speed test from WebKit .  The measurement is the total number of milliseconds that it took the test to run in each browser.

What’s shocking aside from the fact that IE 9 was the fastest browser, is how bad the performance is on iOS WebKit.  It’s 18 times slower than the slowest desktop browser. 

Now I know this is an “Apples To Oranges” comparison.

The desktop browsers are running on a MacBook Pro with a 2.2 Ghz i7 processor an 8 gigs of ram.  My iPhone has the Apple A 4 chip which clocks in at 1 Ghz on the iPad but is probably under-clocked on the iPhone to preserve battery life. I wouldn’t expect the performance to be nearly as good as a desktop.  IE On Mango fairs much worse than iOS at a whopping 35 times slower than Firefox on a Dell Venue Pro with a 1 Ghz chip. 

However

Given those test results, it’s clear that we cannot write HTML5 apps for the mobile platform without taking this into account.  If HTML5 apps and games are the way of the future on mobile devices, how do we make this work?

CSS 3 Transitions

CSS 3 is the new CSS specification for HTML5.  Transitions allow you to animate elements of the DOM with pure CSS.  No JavaScript required.  You basically specify what property you want to animate, how long the animation should take to run, and an easing function.  Then whenever the CSS property changes (ala jQuery), the change is animated.

The built-in easing functions are Linear, Ease, Easein, EaseOut, EaseInOut.  If these don’t suit you, you can specify your own via a custom easing function. The Ceaser CSS Easing Animation Tool will create your custom easing for you.

The are also some sites like http://css3generator.com/ which will generate your CSS 3 for you.

The reason why CSS 3 transitions are so powerful, is that they are optimized for the GPU on the device.  The browser doesn’t have to parse arbitrary JavaScript to try and figure out what you are trying to do.  The browser essentially doesn’t know that you are trying to achieve a smooth animation when you are doing it via JavaScript.  When you use CSS transitions, the GPU magic happens under the covers and your animations are smooth.

That being said, my implementation used requestAnimationFrame which is recommended by Paul Irish and I still noticed poor performance on iOS.  The canvas is additionally optimized to use accelerated graphics when it can, but clearly that is not sufficient when drawing so many objects to the screen.

Browser Support

Like many things, CSS 3 is not yet fully supported or standardized across all browsers, so we have a different prefix for each of the current major players.  Whenever there is a feature that the browser makers want to implement, but no concrete w3c standard to back it up, they all implement it with some prefix that is specific to their browser so that when the standard is adopted their conventions won’t collide with whatever is decided on by the standards body.

That means in order to properly target your transitions at all browsers, you would need something like this.

-webkit-transition: all 500ms linear;
-moz-transition: all 500ms linear;
-ms-transition: all 500ms linear;
-o-transition: all 500ms linear;
transition: all 500ms linear;

That’s a bit messy, but you can always use things like LESS or SASS to clean it up.

As Todd mentioned, it’s always something with IE .  Currently, IE does not support CSS 3 transitions.  Not even in version 9.  That means you better have a fallback plan if you are going to rely on CSS 3 transitions as last month’s browser usage statistics still show IE with 22.9% of the market.  That’s way too big of a chunk to completely ignore.

Source: http://www.w3schools.com/browsers/browsers_stats.asp

Notice though that there is a –ms-transition.  That’s there for the emerging IE 10 browser which does support CSS 3 transitions.  IE is catching up slowly but surely.

Kendo UI And CSS 3

CSS 3 performance on iOS is top notch.  It’s clear that you have to consider all platforms when choosing the best  animation in your application, either through CSS or JavaScript.  Kendo UI makes use of CSS 3 for transitions whenever possible and degrades to jQuery / JavaScript transitions for weaker browsers (* cough *  IE  * cough *).

These are the unseen things to consider when picking an HTML5 framework.  Will your framework provide a solid experience on mobile devices?  Will your UI translate from the desktop to the tablet?  It’s important that we leave no browser left behind as we create new applications on a standard that is still in a bit of flux.  Kendo UI allows you to concentrate on building your UI and less on having to worry about whether or not it’s going to work when the next tablet ships (i.e. Kindle Fire ).