As part of our continuing series on the HTML5 capabilities of new mobile platforms, today we’re taking a look at the new Chrome for Android mobile browser beta. There have been rumors of Chrome for Android for quite some time, and we were encouraged but a little underwhelmed by the stock Android 4 browser. We were hoping that there was more to come.
And we didn’t have to wait long. After testing Chrome for Android, we’re happy to say that it’s a very solid HTML5 browser, and even in its beta form, is a “must-install” for any Android 4 owner. Hopefully Chrome for Android quickly becomes the *only* browser for Android 4.
bq(pullquote right). “If you own an Android 4, there is no question you should download and use Chrome Mobile beta as your primary browser.”
h3. Our First-Look “Methodology”
h3. Acid3 and Modernizr
Chrome for Android scores a perfect 100/100 on the Acid3 test, just like the Android 4 browser. However, the tell tale rendering artifact (a very faint red/pink box in the upper right corner) that has marred a perfect score on other Android browsers, once again rears its head. (Chrome Desktop doesn’t have this artifact, so perhaps this is an OS/graphics stack issue rather than a browser problem). In practice, this won’t impact web browsing or web development much, but it would be nice to fix this for the final release.
Next up, Modernizr! Once again, we used haz.io which is a clean and mobile friendly Modernizr checker. The verdict? High marks on HTML5 support — as one might expect from the folks who brought you Chrome. Once again, the browser does have
@font-face support — Google Fonts display perfectly — but TypeKit does not yet detect Chrome for Android correctly. As with the original Playbook, and Android 4 stock browser support, Typekit has a lag between first ship and support, but I’m sure the Typekit folks are on top of this.
Compared to the stock Android 4 browser, there is a substantial number of additional HTML5 features: Web Workers, Web Sockets, HTML5 Input Types, overflow: scroll, requestAnimationFrame and more. That’s not to say that Chrome for Android has absolutely everything. As detected by the other handy testing site for HTML5, many newer features are absent, notably Shared Workers and WebGL. The video codec cold war also continues: Ogg Theora and Ogg Vorbis support is still not there — which is not a surprise.
For performance benchmarking, we use SunSpider. In the last 9 months, all the mobile browsers have converged at basically the same SunSpider performance levels. This also holds true for Chrome for Android. Although it’s slightly faster on one or two tests vs. Android 4 browser, it’s in the same general ballpark, which is not too surprising since they’re both using the V8 engine on the same hardware. Since Chrome for Android is visually much faster and smoother than the Android stock browser, this is probably a good time to consider putting SunSpider on the shelf as a good predictor of user-perceived performance.
h3. Real World Tests
As we’ve said many times previously, many mobile browsers do well on the checkbox tests like Modernizr, but fall short when it comes to real world applications and content. (In some cases, mobile browsers have even reported support when none exists.) So for real world testing, we use a collection of our own favorite HTML5 sites and demos.
First up, the new CSS properties for mobile content. On our HTML5 wish list for 2011 we asked for high performance position: fixed. And Chrome for Android delivers. For simple pages, Chrome for Android does a top notch job of glueing fixed position content to the screen. Fixed headers and footers for simple mobile optimized pages are now easily implemented without having to use a framework. However, the browser struggled when trying to maintain fixed positioning on more complex pages, particularly when combined with pinch/zoom. We saw poor frame rates and occasionally content disappeared or was misplaced. Happily, the *very new* @-webkit-overflow-scrolling: [email protected] property, which debuted in iOS 5, is also now available in Chrome for Android. It’s smooth and fast. (Nice job Chrome team!)
On to SVG. On Chrome mobile, basic SVG worked very nicely. Our Raphael vector demos were very smooth, and many other SVG effects like text on a path, and animated gradients worked smoothly at a good frame rate. For more advanced effects (demos at David Dailey’s page), there’s still work to be done: SVG effects like complex filtering were either not supported or ran at low frame rates. Since there is little popular content that relies on these advanced effects yet, this is not such a big deal. However, when CSS Filters start to percolate into general usage, getting these right will become more important.
We next tried Canvas and here Chrome for Android has a good implementation. Basic Canvas drawing is unproblematic, and our favorite Canvas stressor — Canvas Color Cycling was smooth and high performance even under pinch/zoom. The most complex demos we could find (that can cause even desktops to pause), such as the demos at Mr. Doob did cause some problems — with long wait times and occasional complete display failures.
Our testing of embedded HTML5 audio and video went well. Plain inline HTML5 video works, (although don’t try to combine it with other effects or Canvas). This is an area where Chrome Beta has the advantage over iOS 5 which still lacks inline video playback.
Finally, we took a look at CSS3 Animations & Transforms. This is an area that we’ve invested in here at Sencha with Sencha Animator. Poor Android performance on 3D transforms has been a limitation on the complexity of CSS animations that can deploy cross platform. Our most complex animation — our Sencha Animator KickFu game — was playable, but the frame rate was too low for a smooth experience — I’d estimate a 5-10 frames per second performance. More basic CSS3 animations — even 3D ones — worked well, although we did uncover our first official bug for the Chrome team which we will be filing — transformed elements seem to drop border-radius. In addition, there are a few layout quirks that are present in desktop Chrome for transformed elements that also show up in Mobile Chrome.
h3. Sencha Touch 1.0 Kitchen Sink
Although we’re in late beta with Sencha Touch 2, we decided to test Sencha Touch 1.1 instead. Compared to Android 4, the Chrome for Android experience is vastly improved. Full-screen flashes and screen flicker are absent. Other things that we take for granted such as smooth border radii, masking etc. are also well implemented. But it’s also true that some of the browser properties that we rely on for layout in Android are now different in Chrome Beta and these result in minor artifacts in layout and list scrolling that we’ll need to be address.
h3. Chrome for Android beta: tips for the HTML5 developer
Chrome for Android is a big leap forward for web browsing on Android devices — even in its beta form. We suspect that many of the browser limitations are limitations more of the device processors than the browser itself. There is still work to be done before general release, but in all we’re very happy to have a top notch browser for Android. If you own an Android 4, there is no question you should download and use Chrome for Android as your primary browser as soon as you are able.
Sven Tore Iversen says
To bad it’s US only for now :(
Ron Waldon says
Google Chrome is available on the Android Market in Australia too. It is limited to Android 4.0+, so perhaps that is the block Sven has encountered.
@Sven Take a look at androidpolice.com. I’m pretty sure I’ve seen an entry there about getting & installing the apk if you are not living in an English speaking country.
Paulo Cesar Ferreira says
Cool, now when somebody complains about our web app performance and correctness on Android, I just can say: Install Chrome for Android!
I hope ICS adoption will be fast, and they replace official browser with Chrome soon..
You can get the apk here:
“If you own an Android 4, there is no question you should download and use Chrome Mobile beta as your primary browser”
Where’s the benchmarking against other browsers, not just stock? Bad conclusion from bad article. Go back to Google HQ and learn how to astroturf properly.
does it really matters when 99% of all android mobile can’t use it ?
Did you notice the obvious lag on http://maps.google.com in Mobile Chrome in Nexus Prime when compared to the native Google Maps and (more significantly) http://maps.google.com on Mobile Safari. (http://maps.bing.com demonstrates the same behavior.)
I observed the same symptom on the Android Browser, but I was really hoping Chrome would resolve this.
What is the cause of this? Is it lack of GPU offloading for specific CSS 2D transforms?
Cian Clarke says
Thanks for a great review – it’s exciting to see Android finally take a step in the right direction, and focusing where the platform has always been so lacking – a browser comparable in performance to Google’s desktop offering, Chrome!
Chelsea Preet says
Have a brilliant tutorial! I like this conception really inspirational so long. Thanks for HTML5 Scorecard relevant input. Thanks!
Chrome is a great browser, and Android is an OS with a lot of potential, so YES i too think that they make a great combo.
Guillaume Carre says
Links to haz.io and html5test.org are broken in the article
Is HTML5 filesystem support coming in extjs?
Maybe the HTML 5 can support more, I think.