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) | |
|---|---|---|---|
| Acid 3* | 100 | 100 | 100 |
| HTML5 Test* | 468 | 468 | 394 |
| SunSpider | 371.5ms | 388.6ms | 311.9ms |
| Octane* | 9304 | 9054 | 7154 |
| Peacekeeper* | 4,381 | 4,210 | 1,484 |
| 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.
"Remember Me When You Raise Your Hand For Dua"
Raheel Ahmed Khan
System Engineer
send2raheel@yahoo.com
send2raheel@engineer.com
sirraheel@gmail.com
send2raheel (skype id)
My Blog Spot
http://raheel-mydreamz.blogspot.com/
No comments:
Post a Comment