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 adv