I run three benchmarks (on the same machine, all browsers open, running the benchmark only in one at a time):

• the V8 Benchmark Suite
• a nice SVG & Canvas speed test
• Sebastien Gruhier’s PGF test page (used earlier in a previous test).

The first test is more JavaScript oriented, where the new V8 virtual machine can shine, the other two test graphical abilities.

And the results are…

The V8 Benchmark Suite results are:

• IE 7.0.5730.11: Score: 16 (Richards: 10; DeltaBlue: 8; Crypto: 23**; RayTrace: 20; EarleyBoyer: 31)
• Opera 9.52 (10108): Score: 102 (Richards: 57; DeltaBlue: 73; Crypto: 65; RayTrace: 142; EarleyBoyer: 290)
• Safari 3.1 (525.13): Score: 59 (Richards: 35; DeltaBlue: 45; Crypto: 50; RayTrace: 81; EarleyBoyer: 116)
• Firefox 3.0.1: Score: 77 (Richards: 78; DeltaBlue: 88; Crypto: 56; RayTrace: 65; EarleyBoyer: 111)
• Chrome 0.2.149.27: Score: 676 (Richards: 858; DeltaBlue: 777; Crypto: 650; RayTrace: 345; EarleyBoyer: 946)

There were significant (cca. 10%) fluctuations in each result, but it is obvious that in this (biased) benchmark Chrome is at least 6.7x faster than the next best, and 42x faster than IE.

The SVG & Canvas results:

• IE 7.0.5730.11: does not support SVG & Canvas, so did not complete
• Opera 9.52 (10108): SVG: 1.657s; Canvas: 1.75s (both beautiful)
• Safari 3.1 (525.13): SVG: 4.312s (edges clipped); Canvas: 1.5945s (beautiful)
• Firefox 3.0.1: SVG: 1.46s; Canvas: 1.095s (both beautiful)
• Chrome 0.2.149.27: SVG: 2.877s (line aliasing and clipping problems); Canvas: 0.993s (beautiful)

Again, there were some fluctuations, but we can conclude two things:

• Canvas is king in speed, and in Canvas Chrome seems to have a very slight edge over Firefox
• Canvas rendering quality is consistent and top notch among the browsers; SVG rendering quality is not consistent

The PGF test page results:

• E 7.0.5730.11: VML: 3390ms (both text and image are missing)
• Opera 9.52 (10108): SVG: 1282ms (image is missing on the right); Canvas: 485ms (both text and image are missing)
• Safari 3.1 (525.13): SVG: 625ms; Canvas: 328ms (text is missing)
• Firefox 3.0.1: SVG: 630ms; Canvas: 385ms (text is missing)
• Chrome 0.2.149.27: SVG: 593ms; Canvas: 281ms (text is missing)

Here Chrome seems to edge out the other browsers slightly, and IE is terribly slow (like it used to be). It is also plain that Canvas support is not complete yet in any of the browsers.

More later…

First of all, do read the comic strip by Scott McCloud and the Chrome Team. It is in itself a piece of marketing art and although its primary intended audience may be journalists and less technical people, it is a statement of how serious Google is about Chrome and full of hints for conspiracy theorists among us.

So some of my first thoughts will follow…

OS-within-the-OS

Chrome will be the OS-within-the-OS for Google: most productivity and line-of-business applications can now be successfully turned into web applications. Arguably more and more of them are better in ease of use than the original apps, due to the richness of the platform and due to being re-engineered from scratch (UI wise) with many usability lessons learned since.

The big issue is compatibility. There are at least four major players now: IE, Firefox, Safari, and Opera (plus the mobile editions), and their abilities are spread on a wide spectrum, to say the least. The unquestioned market share leader (IE) is trailing behind in almost all important areas (like performance, usability, standards conformance) and there are subtle but important differences among the others. This makes web application development very costly and time consuming. Even with frameworks like DOJO, Prototype and tools like GWT and Morfik you will encounter compatibility issues and missing functionality (e.g. lack of a consistent graphics layer, like SVG or Canvas).

If we had a browser that

• has #1 market share,
• is consistent among all the major operating systems (Windows, Mac OS X, Linux) and mobile OSes like Android and iPhone OS X (probably Symbian and Windows Mobile, but I would not hold my breath for those),
• is performant, secure and robust,
• and has some additional features like support for off-line operation, a strong graphics layer (for graphs and graphical apps), sandboxed native filesystem access, support for push technology (like COMET), drag & drop desktop integration, and a mature, efficient and familiar development platform (e.g. Eclipse/Java/GWT),

then most applications can be implemented on this platform regardless of the underlying native operating system.

Just think for a second when you used Microsoft Word the last time: I used to be in-and-out all the day, but recently it happens that I don’t open Word for weeks, and then only to edit a “legacy” document that originated from the “old era”. Most of my new documents are emails, Google Docs, or some other on-line properties (god, what that does to privacy, though, so don’t put all your documents on-line!).

Technology tie-ins

There will be technology tie-ins all over the place. Although Google is a huge animal and its projects are only loosely coupled (waving off the monopoly power arguments), saying that the Chrome team accidentally asked the Android team about WebKit love is amusing.

Gears integration is only for starters. I expect that GWT and Chrome will be “optimized together” pretty soon. Google Docs, Maps, etc. will gain in performance, stability and functionality if run on Chrome.

Then the primary business of Google is ads: now it will be able to collect even more information about us (although since gMail and Desktop Search they already have some data on you ;-).

BTW I wonder when Desktop Search will be integrated into Chrome…

Head start

Chrome may have a head start over all other browsers.

Current generation Firefox, Safari and Opera are pretty level on performance (relative to lackluster IE) and at least Firefox and Safari are engaged in further speeding up JavaScript with adding virtual machines similar to Chrome’s V8 (on paper); they are also keen to match each other in standards compliance and usability, but while Chrome addresses all these issues, it also brings a new architecture to the table with the promise of marked enhancement in security, memory performance and robustness, plus the native integration of Gears.

The others will have to play catch-up. And Google has the resources to compete — it is single-handedly financing Firefox at the moment.

Market share

In order to be successful, Chrome will have to establish market share.

In the consumer space all the good virtues (speed, stability, security) will play well, together with the hippie word of mouth marketing of comic strips and oh-so-accidentally-released-a-bit-ahead-of-time trickery.

The much harder nut is the corporate market. It takes years for corporate IS departments to certify products for use. Here being OSS will help (the corporate world is getting into love with OSS), but the primary message can be security: if Google can deliver on its promise of security (both process separation and malware filters), it will be salvation to IS departments fighting with the dilemma of supporting more and more intranet/extranet web applications and weak security of the very same applications.

Being a consistent web application platform on all important OSes will also come handy – it makes corporate web app development much simpler.

Google will definitely push Chrome with subliminal tactics (e.g. “off-line mode and advanced features of our web apps working best with Chrome” splashes).

Still, it will be a hard sell — they’ll need some killer apps to get rolling.

Missing bits

I’m also missing a few things, the most prominent being additional web application security.

Chrome is a rich client platform, and rich clients run most of their code on, well, the client. This used to be the case with traditional apps, but those were compiled to binary, so poking around required some skills. Now Web 2.0 rich clients are generally made of JavaScript, which is quite readable and even can be changed on the run, making attacks against the code much easier than before.

Of course tools like GWT or Morfik will scramble and optimize the client code making it not a pleasure to read, but it is still the source code of the app that is downloaded and run in the browser. So it would be fine if some kind of run-time protection would be in place to prevent code morphing and allow code verification. The fact that each tab runs in its own process is promising, though.

Phew! So here are my first impressions — what if I stared thinking about this :-) Now it’s your turn!

So the browsers are:

• Internet Explorer 6.0.2900.2180.xpsp_sp2_qfe.070227-2300 :-)
• Firefox 2.0.0.4
• Safari for Windows 3.0.2 (522.13.1)
• Opera 9.21 (Build 8776)

I run the page several times in SVG, VML, and Canvas mode on each browser (of course, when it was possible) with the following results:

• Internet Explorer: only VML is available
  • VML: originally around 4300ms, and with each re-rendering the time increasing by cca. 1800 ms (!) so it went like 4300, 6xxx, 8xxx, 9xxx, and finally jumped to 13109 ms
• Firefox:
  • SVG: generally around 1900 ms, sometimes dropping to 1500ish or peaking at 2300ish ms
  • Canvas: odd runs: ~1100 ms, even runs: ~750 m, alternating :-)
• Safari for Windows:
  • SVG: dead steady on 1070-1030 ms
  • Canvas: pretty steady around 600-468 ms, mostly in the 490-468 ms range
• Opera:
  • SVG: pretty stable at 2360-2078 ms
  • Canvas: pretty stable at 1030-860 ms

Again, the runs were performed on the same machine (2GHz P4, 2GB RAM, WinXP Pro, Commit charge ~1369MB), all browsers running at the same time, but the test performed sequentially.

My informal results:

• SVG: Safari is the king, at least 50% better, but typically 90-100% better performance than the competitors
• Canvas: again Safari is #1, at least 25% speed advantage, but as good as 100% better — with quite stable performance in both cases.
• VML: well, let’s read between the lines ;-) (please note: I did not run IE 7, but IE 6, for technical reasons) – if we consider its best result in VML and compare to Safari’s average SVG result (VML and SVG are closer relatives than VML and Canvas), then Safari is 400% faster.
• Canvas is the overall spead king, SVG is #2, and VML is distant #3.
• Safari is king in graphics — and this is still the first beta release from Apple…

BTW I got into all this because I’m looking into how to best implement some of my stuff on the iPhone with Morfik, and also for some graphical stuff I plan to do (charts, Gantt, diagrams, hint-hint:-).

Again, this is not science here: I only tested one rendering task, the environment was quite loaded, did not test IE 7 (although the rest of the browsers were their latest), did not check rendering quality in depth (things looked pretty OK in all cases), etc. Still I consider the results quite relevant — I’d like to see what other pepole can say about their experience…