Monday, September 8, 2008

Browser Shoot-Out

With all the recent hoopla of which browser is faster/better/more convenient/etc, I updated my html/javascript benchmark script and set out to see for myself what all the excitement is about.

The following tests measure the amount of time it takes the browser to create, parse and render a chunk of html, specifically a 300x30 table with and without any content in the cells. Each test runs 3 times, and the slowest result is discarded. The method for running tests and taking measurements is as follows:

  prepare for test (pre-generate html, clear target, etc)
  setTimeout with delay=0  // let all pending events clear up
    get the start time
    run the test
    setTimeout with delay=0 // let the test finish
        get the end time and store the delta
I ran all tests on a 2Ghz Core Duo laptop with Radeon x1400 video card, 1 GB of memory, Windows XP sp3, running on battery power (too lazy to get up and plug it into the wall). All results are in milliseconds.

The contenders

Here are the contenders, with their identification strings
  • IE 7. Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
  • Opera 9.52 Opera/9.52 (Windows NT 5.1; U; en)
  • Safari 3.1 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1.2 Safari/525.21
  • Chrome 0.2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/ Safari/525.13
  • Firefox 3.01 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008070208 Firefox/3.0.1
  • Firefox 3.1 nightly, pre-beta 1, TraceMonkey jit enabled Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080905031348 Minefield/3.1b1pre
I did not install IE 8 beta because I did not want to pollute my wife's computer, and I didn't know how to get Webkit nightly. Both of these are supposed to be faster than the previous versions, though IE 8 is said to still be much slower than the rest of the field.

Rendering Tests

These tests measured the amount of time it takes a browser to parse and render a pre-generated 300x30 html table into an on-screen element via innerHTML, into an off-screen element (a div that is not attached to the document) via innerHTML, and a combination of both, where the table is rendered into an off-screen div, then moved to the on-screen one.

These tests were ran using both the default style and a pre-defined style (fixed cell height/width, font, border, etc), and with empty and non-empty tables (cells were filled with non-breaking spaces for empty, and strings in the form of "row, column" for non-empty)

browser style render on-screen render off-screen combo
non-empty empty non-empty empty non-empty empty
IE 7 default 849 531 105 105 912 609
fixed 1385 1036 104 109 1506 1156
Opera default 349 312 42 42 313 318
fixed 474 484 73 67 412 485
Safari default 302 213 41 41 281 209
fixed 396 333 41 42 354 333
Chrome default 246 164 51 49 196 130
fixed 338 295 58 52 273 245
Firefox 3 default 562 471 72 93 501 392
fixed 519 554 71 85 456 482
Firefox 3.1 default 601 497 71 96 524 417
fixed 532 577 73 92 465 496

DOM tests

In these tests, the tables were constructed into an off-screen buffer using DOM operations. Cloning was used as much as possible, and the contents of the cells were set using textContent or innerText where available, and using createTextNode otherwise.

browser non-empty empty
IE7 911 385
Opera 417 11
Safari 172 21
Chrome 314 12
Firefox 3 247 26
Firefox 3.1 193 22

String and Array performance tests

The last test consists of building a string containing a 300x30 html table, by pushing substrings into an array and joining them in the end. This is a pure JavaScript benchmark.

browser non-empty empty
IE7 167 104
Opera 193 89
Safari 84 42
Chrome 24 20
Firefox 3 28 19
Firefox 3.1 22 11


  1. You're OK as long as you are not using the Internet Explorer. Unfortunately, it looks like most of the power users have already switched away from it. Maybe Google can find a way to switch some of the non-power base, though as long as it is bundled with Windows it'll have a large user base. I hear people still use AOL
  2. Chrome is good. Looks like Google developers managed to speed up Safari's Webkit even further, so Chrome in the lead and Safari won't be far behind
  3. Firefox's new TraceMonkey javascript engine kicks ass. Safari's new engine is also rumored to be a lot faster than the current one, so Google's V8 is not yet living up to the hype
  4. Mozilla people better start worrying about rendering. The current results are disappointing
  5. I expected Opera to be faster
I am sticking with Firefox. For one thing, I am not allowed to use Opera, Safari or Chrome at work, and at home I run Linux, where Safari and Chrome are not yet available. For another thing, I need the extensions.

No comments: