Performance of browsers is a hot topic nowadays, and Ajax Toolkits are always busy squeezing out those last milliseconds. Internally at Backbase we also have a performance testing framework which tests every release for possible performance degradation. Normally we only compare different versions of Backbase, but what if we compare different browsers? And what if we compare it to IE8 beta 1 (released today), Firefox nightly, and Safari nightly builds?
Test setup
The tests are run on the same machine being a Pentium 4 (2.4Ghz) with Windows XP SP2. Every test is run multiple times to get a decent performance result.
There are different kind tests, I have separated them in 2 sections: JavaScript performance and Render performance (DOM).
JavaScript Performance
The first section is the Javascript Engine of Backbase and testing various scenarios, for instance:
- TDL Compiling / parsing
- Javascript XPath 2.0 Engine
- XEL execution / event propagation
Render Performance (DOM)
The second part is rendering widgets, for example:
- Rendering 1 accordion
- Rendering 5 accordions
- Rendering a listGrid
- etc..
JavaScript Performance (Engine)
The following diagram is a summary of the time it takes to execute the different engine performance tests
We can see impressive results for Firefox 3 nightly, being almost 3x faster than Firefox 2. Also the Webkit nightly is running fast, and that when you thought that Safari 3 was already blazingly fast!
IE8 beta1 was only released today, so we haven't been able to test it as thoroughly as the other browsers. However, it's clear that JavaScript performance has improved.
The last place ends Opera 9.5 beta (huh, what's up?) but the main reason for this is the test for the event propagation being 5x slower in Opera than Firefox. If we do not accumulate those tests in the result Opera 9.5b is at the same speed as Firefox 3 beta 3
Render Performance (DOM)
The following diagram is a summary of the time it takes to render different controls, both hidden and visible on the screen. It's mainly showing the DOM-operation speed of dynamically creating elements and the actual rendering when the element is attached to the main document.
There is no doubt here, the Webkit engine is the fastest renderer. The nightly being 5x times faster than Internet Explorer 6/7/8. So in theory you could visit and see 5 websites with Safari in the same time it takes Internet Explorer to render it's default MSN.com website.
IE 8 beta 1 - only briefly tested - seems to have the slowest DOM rendering, but of course it's only a beta 1. We've tested in IE7 mode.
We can also see some real effort put in the Gecko engine with the Firefox 3 rendering almost 2x times faster than Firefox 2.
Full test data
I have put the full specification ( and the milliseconds ;-) ) online in Google Docs you can check it out here.
The first sections show the JavaScript performance (from 'Core Renderer' to 'XPath 2.0 Engine'). The sections after that show the Render performance (from 'Accordion' to 'window').
Conclusion
A lot of respect and thanks to all the browser teams pushing the boundary of performance. I think it's an awesome result that the current nightlies of both Webkit and Gecko are 2x / 3x faster than the current production versions. Can't wait until Firefox 3 is released to the public!
It seems the IE team still needs to do a lot of optimization in the render engine, but still we have to consider that it's a beta 1. So let's hope they either improve some more or everybody switches to Firefox / Safari.

Comments
benchmark test case source
10 March, 2008 - 04:14 — jhrvatinHi,
I work on the IE team and I'm interested in learning more about the tests you run. We're always looking for additional tests to broaden our performance coverage so we're not focused on a narrow area. And test cases built off real-world usage are even better.
Please contact me at john.hrvatin[at]microsoft.com.
Thanks!
John [MSFT]
Full test specifications
10 March, 2008 - 12:45 — kevinvandijkHi Sjoerd,
I'm interested in learning how the exact test was set up.
Did you use a predefined test suite that is available somewhere or did you construct your own test?
Greetings,
Kevin
Performance is Everything: more insight
13 March, 2008 - 20:45 — SergeyHi,
There have been several questions on the web regarding the performance tests and results revealed in Sjoerd's article. I will try to give some more insight and answer some of these questions.
1) Performance Testing at Backbase: The Approach
Performance tests are units of work that are expected to take some fraction of second to execute. The performance framework runs such tests as many times as it can within 2 seconds giving the browser a brief pause between runs. Then an average time between runs is calculated and the result is returned.
A test normally does not target a specific feature of a browser directly; it rather emphasizes certain aspect of the browser functionality. Thus there is always some “noise” as a part of results, however it is low and mostly consistent across tests.
2) "JavaScript Performance (Engine)" vs. "Render Performance (DOM)"
There are two graphs in the Sjoerd's article: "JavaScript Performance (Engine)" and "Render Performance (DOM)". The later should rather be read as "Render Performance (Bindings or Controls)".
The two sets contain tests that measure certain aspect of Backbase applications.
The "JavaScript Performance (Engine)" test suite targets mainly performance aspects not related to the browser rendering functionality: JavaScript performance, DOM HTML (with no CSS) / DOM XML etc.
The "Render Performance (Bindings)" test suite targets mainly performance of the browser rendering: DOM HTML in combination with CSS
3) The vertical Bar in graphs
This is a sum of tests' averages. Summing averages is of course not fair since different aspects being tested have different impact on the end sum.
Still it makes up the overall picture of two major performance aspects of a browser: execution and rendering.
At Backbase, as part of our quality assurance process, we run nightly performance tests on all supported browsers as well as beta and nightly builds. We do this to keep an eye on the potential impact that is made to the product performance when introducing new features, refactoring implementations and in order to monitor browser performance improvements over time.
Tech Lead,
Sergey Ilinsky