HTML5 Scorecard: Amazon Kindle Fire

As part of our continuing series, we ran the new Amazon Kindle Fire through our tests to see how it stacks up as an HTML5 app platform.

As part of our continuing series on the HTML5 capabilities of new mobile platforms, we’re taking the measure of the new “Amazon Kindle Fire”: When the Kindle Fire was announced, we were excited about getting our hands on it. As the first mass market tablet at the $200 price point, we knew it had a good shot at selling millions of units. But at the same time, we were apprehensive that Amazon might have skimped on hardware capabilities to reach that price. We were also concerned about the browser platform. The Fire runs a customized version of Android 2.3.4 (Gingerbread) and in the past, we’ve been disappointed with the quality and completeness of that browser. We were hoping that Amazon would improve the stock Gingerbread browser significantly.

The Kindle Fire is a competent but minimal HTML5 platform that reflects its $200 price and Android 2.x lineage.”

After putting the Kindle Fire through our test wringer, we can say that while it’s a solid browser for normal page browsing, it lags the best of the competition in HTML5 capabilities. Constrained by its Gingerbread foundation, it’s a competent but minimal HTML5 platform that reflects its $200 price point. At this stage in the tablet game, we would expect better.

h3. Our First Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

h3. Acid3 and Modernizr

The Fire scores a less than perfect 95/100 on the Acid3 test. Like other Android tablets, it lacks SVG support and incorrectly displays the Acid3 visual test compared to the reference implementation. With both the iPad2 and the BlackBerry PlayBook now scoring 100/100, this puts the Fire behind the pack. In addition. the Fire failed test 46 (media queries) and came in slower than required on three other tests including the self-described “challenging” test 26 for garbage collection speed.

We then turned to Modernizr, one of our favorite tools to look under the hood of a browser. Since the Fire hardware lacks a camera, an accelerometer and a GPS, some of the results (geolocation failure!) are predictable. What Modernizr did find was support for CSS 2D transforms and Canvas as well as other Android 2.x capabilities. Notably absent: 3D transforms, web sockets, web workers and many HTML form input types. Again, not that surprising considering the Android 2.x heritage.

Happily, web fonts seem to be well supported. Both Google Fonts and Typekit dynamic fonts render correctly. But Typekit font loading and page scrolling on the Google Fonts page (with tens of different onscreen web fonts) was noticeably slow.

h3. Performance Testing

When checking the user agent received, web servers report that our Fire was using WebKit version 533.1, which is much older than the WebKit found on the Xoom and PlayBook. On other hand, when the Kindle is put in “desktop browsing mode”, it advertises itself as Safari 5/Mac OS X/Webkit 533.16. Under the hood, according to the iFixit teardown, the Fire contains a dual-core ARM processor, specifically the TI OMAP 4430, which is the same processor as the BlackBerry PlayBook. We therefore expected SunSpider scores in the same range as other tablets. As we’ve mentioned before, this current generation of tablets all ship with dual-core processors and all have roughly the same JavaScript optimizations. So the results are again fairly predictable.

Amazon Kindle Fire SunSpider results

For the most part, the Amazon Kindle Fire has similar SunSpider results compared to Apple iPad 2 and BlackBerry PlayBook.

The SunSpider tests are synthetic tests that push the JavaScript engine to its limit. So, next we turned our attention to some more real world tests, looking at CSS3 performance using our own Sencha Animator demos as well as a few other tests.

We threw caution to the wind and started off on our most challenging CSS3 animation test, the Kick Fu game that was developed for the launch of Sencha Animator. While the game did play, the frame rate was poor and touch responsiveness while animations were running was also substandard. The Fire lacks a separate GPU, but the CPU has a competent GPU core – and even so, it looks like it wasn’t leveraged for hardware acceleration. The Playbook, for example, does a far better job leveraging the same GPU core.

Next we tried simpler animations. The Fire performed more smoothly, but had a notably bad implementation of timing. In the video below, the wave movements are controlled by CSS3 animations and are declared at constant speed. Instead, the animation speeds of each element diverge and lag noticeably and visibly from each other. We’ve never seen artifacts of this magnitude before. This got us wondering about the Kindle’s general timer quality, so we ran John Resig’s classic JavaScript timer test and found that the quality of the timer is similar to other Androids: with setInterval triggered every 10ms +5/-3s, with some noticeable latency spikes. (This compares to iOS 5’s best-in-class implementation of 10ms +/-1ms.) This isn’t supposed to matter as much once people get used to using requestAnimationFrame for JavaScript animations, but the Fire doesn’t have that either.

CSS3 Animations on the Amazon Kindle Fire

We also tested a few other real world areas for performance and correctness. We tried a Canvas based GitHub network graph. Rendering performance was fine and the result was accurate. Pinch/zoom happily also works although Android’s tendency to toggle into low-quality mode when moving content reared its head once again. We also tried out Canvas Cycle and it worked reasonably well. The frame rate was solid and we were able to change the scene without issue. However, like all webkit implementations, all bets were off when we zoomed and panned the page. Animation stuttered, froze and occasionally the accompanying audio cut out. We also looked at other Canvas animations and they worked at reasonable frame-rates.

Finally we tested embedded HTML5 audio and video. HTML5 audio playback seemed to work well, although the default playback controls were tiny, hard to touch and didn’t seem to work very well. HTML5 video is “supported’ but tapping play simply launches the video in the native player. Complete HTML5 video support with embedded playback and effects is not there. There also appears to be no Ogg Theora codec on the device as we couldn’t get any Ogg Theora demo to play.

The Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal.”

h3. Sencha Touch Kitchen Sink

Our Kitchen Sink app is built with Sencha Touch and tests all aspects of our mobile web app framework. The Kitchen Sink gives mobile browsers a good workout as it exercises a huge set of browser features including a wide range of CSS3 effects.

The first thing we noticed were the crispy CSS rounded corners. They’re not anti-aliased properly on the Fire. Webkit masks are also not supported. Then we got our first really big surprise of our run through. We found that the Kindle Fire has problems processing touch events with good responsiveness. Update: and we’re not the only reviewers to notice this . And similar to early HTC phones (since fixed), the OS and browser seem to fight over who gets touch events. Sencha Touch 2 was designed to adapt to this behavior, so the Touch 2 preview kitchen sink works better than the Touch 1 version. And of course, since the Fire is based on Android 2.x, full multi-touch with independently tracked touches is not supported either.

As you’d expect with a device lacking a GPU, graphics effects like transitions were less than smooth, although display artifacts were not as bad as the full screen flashes and repaints that are a problem on honeycomb based tablets.

h3. No to low Impact from “Accelerated Browsing”

Amazon Silk One of the main selling points of the Kindle browser is supposed to be its cloud-caching and pipelined HTTP connection that uses the SPDY protocol. This does seem to speed up normal page browsing a little, but it’s not very noticeable and we didn’t test this rigorously. But for HTML5 web apps, where code is downloaded and executed, there doesn’t seem to be any performance difference when we tested with acceleration on and off. It doesn’t appear as if client JavaScript is executed on the server-side at all, so the Kindle does not seem to have Opera Mini-style server-side execution. And SunSpider scores were essentially the same when accelerated browsing was turned on or off.

Side-by-side comparison of accelerated vs. unaccelerated browsing for some popular web home pages.

h3. Kindle Fire: Suggestions for the HTML5 App Developer

In summary, the Amazon Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal. It does a good job of displaying ordinary web pages and its resolution and rendering capabilities meet that need well. But there are too many sharp edges, performance issues, and missing HTML5 features for us to recommend that any developer create web apps primarily for the Kindle Fire. The iPad 2 running iOS 5 continues to be the tablet to beat, with the PlayBook a respectable runner-up in HTML5 capabilities.

Written by

Michael Mullany is the CEO at Sencha. He has held various product and executive marketing roles at influential Silicon Valley startups -- Netscape, Loudcloud, and VMware. He holds an MBA from Stanford University and a BA in economics from Harvard College.


  1. Corey Shank says

    From the marketing of the Kindle Fire, it seems to me that it’s primary goal is to create and maintain a pipeline to Amazon, with browsing and email a side note…which would explain the lack of rich HTML 5 support, like the iPad.

    It looks to me to be marketed to those who primarily want a Kindle, but are also wanting some app. features (movies, Netflix, Facebook perhaps) also to check email and browse a bit on the Internet.

    And if that is what you want, why not pay $200 for the Fire as opposed to the iPad?

  2. says

    Much of this criticism is due to the underlying Android platform. Google has simultaneously built the best desktop browser (Chrome) and the worst mobile browser (Android).

    I am hopeful that Ice Cream Sandwich features significant improvements to the browser (and I hear it does), however Amazon are on their own path with the Kindle Fire, so it remains to be seen if upstream improvements will ever trickle down.

  3. says

    @Corey I don’t think that this article is meant to deter people from buying a kindle (which is primarily, after all, a book reader). Since this website is targeted for web-developers it makes sense to focus on that functionality of the device.

    I know that I still want one. But I’ll have to take the above into consideration for my web applications if I plan to support it in any significant way.

  4. says


    I don’t think Corey was accusing the article of talking people out of the Kindle, just pointing out that it’s marketed to a different kind of audience. I’ve got to agree with him, actually – $200 for that functionality (despite the lack of support) will make sense to a certain group of people.

  5. Don Burnett says

    This just proves that like the last version of HTML, HTML 5 is not the be all end all standard that you guys were claiming it is.. The HTML 5 browser market is as fragmented with what it can and can’t do as the versions of Android fragment creating apps for it.. With things like WebGL, WebSQL (SQLlite) etc not being on every version and compatibility of browsers not strictly enforced what do you expect. At least Flash and Silverlight had a lack of problems with this when you used them..

    I just think it’s witty to see you guys expecting an e-reader to be another platform for you folks to stick Sencha stuff on and expect it to hold up.. The reality is you folks are going to have to do more and more work as time goes forward and innovation does as well to retain compatibility in the HTML 5 realm as did the last four versions of HTML.. That’s why Flash for instance and SIlverlight happened and went ahead of web standards and it will happen again because it’s really doubtful just based on platform that unless in this case there is just one version of Android that all e-reader manufacturers make and one browser that variation will not continue to occur until it all collapses into a mire of muck.. Claiming the iPad the winner is a bit pre-emptory because this product does what it was “Designed” to do (i.e. not be a platform for Sencha web products) very well..

    Get over HTML 5, it’s the best thing you could do as a company..

  6. says

    Surely this article cleared my doubts regarding kindle fire, and it’s obvious kindle cannot provide a high tech brower which could incorporate html 5 into its product (both software and hardware) at its low price. Thanks for the review.

  7. John says

    “The Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal.”

    :) :) :)

    wait, wait.. I got another one:

    “The Toyota Prius doesn’t seem designed to do off road driving as a primary goal”

    Seriously though.. great article and esp. like the video(s) showing actual device performance.

  8. Alan Gruskoff says

    Agree completely with @Don Burnett “Get over HTML 5, it’s the best thing you could do as a company.”

    This review strongly underlines what a inconsistent, immature, Tower of Babel relying on HTML5 as a some sort of “standard” is. Its a mess and will be a mess for years.

Leave a Reply

Your email address will not be published. Required fields are marked *