If you're looking for some in-your-face changes once Chrome moves to Blink, you'll be sorely disappointed. In fact, unless you watched the recent Q&A with some of the Chrome team, you wouldn't even know the Canary build had already made the change. The about page still lists the rendering engine as WebKit, but rest assured it is the first implementation of Blink outside of Google's own laboratories.
In the blog post announcing Blink, Adam Barth said that, at least initially, there would be little change for web developers. Early work would primarily be about improving the internal architecture and pruning the code base to make it more efficient and stable. And from what we can tell, that seems to be a spot on assessment. We loaded up several sites in the stable and Canary versions of Chrome and couldn't spot a single difference. There were no strange glitches or visual bugs. Not a single pixel was shifted out of place in the layout -- at least on pages. Favicons and text in the tabs themselves was shifted down slightly, bleeding into the address bar. Subjectively, pages behaved exactly the same as well and were every bit as responsive using Blink as they were under traditional WebKit. That's not a bad thing, either. While Google may feel the path to true innovation is one it must blaze itself, WebKit has been serving millions -- nay, billions -- faithfully for years. Both developers and users want speed and versatility in a browser for sure, but more importantly they want predictability.
| || Chrome 28 Canary (Blink) || |
Chrome 26 Stable (WebKit)
| Firefox 20 (Gecko) |
| Acid 3* || 100 || 100 || 100 |
| HTML5 Test* || 468 || 468 || 394 |
| SunSpider || 371.5ms || 388.6ms || 311.9ms |
| 9304 || 9054 || |
| Peacekeeper* || 4,381 || 4,210 || |
| Cold start || 3.07s || 4.16s || 4.4s |
| Avg site load time Test || 3.24s || 3.6s || 2.97s |
| RAM usage (6 tabs) || 806MB || 822MB || 298MB |
*Higher is better
The similarities become even more apparent when you start firing up benchmarks and standards tests. The Blink-powered Canary build of Chrome scored 100 on the Acid 3 test and 468 on the HTML5 test, which is exactly the same set of numbers put up by the stable version of the browser. The experimental browser did edge out its mainstream sibling in the SunSpider, Octane and Peacekeeper benchmarks, but not by much. In fact, considering the fluctuations we saw in the SunSpider scores (from 275ms to 871ms for the Canary build), we'd say the results are within our margin of error. Even average page load times (we loaded three sites multiple times, clearing the cache each time) were very similar.
The two results that gave us hope we the cold start times and the RAM usage. The Canary build of Chrome started up more than a full second faster than the stable version and it trimmed about 20MB off its RAM usage with the same six tabs open in each window. The chances that Chrome will ever get its memory footprint down to the size of Firefox is pretty slim, but any progress on reigning it in is much appreciated. Chrome has its advantages over Mozilla's browser, but resource usage is not one of them.
When Chrome 28 hits the stable channel in 10 weeks, there will be little worth getting excited about. The shift from WebKit to Blink is, for all practical purposes, invisible at the moment. But that's not necessarily a bad thing. Google will continue to work on Blink and, over time, it will diverge from WebKit more and more. Some changes will be for the better, others for the worse. But at least for the immediate future, web developers won't need to panic about building for yet another rendering engine.