Word that Google had decided to fork WebKit and build its own rendering engine is still echoing through the spidery halls of the internet. The true ramifications aren't entirely clear yet, but Opera has pledged to embrace Blink and WebKit is already talking about removing Chrome-specific code from its repositories. This doesn't necessarily indicate a seismic shift in the industry, but it certainly suggests that we won't be looking at a world so thoroughly dominated by the direct descendant of KHTML. At least at first, the new entrant won't actually deviate much from WebKit. Primarily the focus will be on stripping away unnecessary code and files to streamline the rendering engine specifically for Chrome. Obviously, this won't prevent other developers from using Blink, since the project is open source. But Google has been pretty up front about the rationale behind the fork -- the multi-process architecture favored by Chromium-based projects is quite different than that used in other WebKit browsers. This has, to put it in the plainest terms possible, kinda gummed up the works.
Blink is about 10 weeks away from landing in the stable version of Chrome (it's expected to be turned on by default in version 28), but it's already available as part of the Canary build. We downloaded the experimental browser and spent some time with it in an effort to identify what, if anything, was different. Keep reading after the break to find out just what Google has bought by shedding some of WebKit's baggage.
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)|
|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.