Each category of testing has four columns: Winner, Strong, Average, and Weak. The Winner is obviously the browser that achieves the highest scores in that category. The Strong column is for browsers exhibiting superior performance, but not achieving a first-place victory. Average is for browsers that perform adequately or in-line with a majority of their competitors. A Weak finish is assigned to browsers that perform poorly, or substantially lower than their competitors.
In order to reflect how each category of testing affects the average end-user Web browsing experience, we need to create brackets (or levels of importance) to place the different categories of testing into.
|Important||Flash, HTML5, Memory Efficiency, Page Load Time, Responsiveness, Security, Startup Time|
|Unimportant||HTML5 Hardware Acceleration, WebGL|
The Essential bracket contains those categories of testing that are indispensable to rendering the vast majority of Web pages online today. The Important bracket is for categories not quite essential to browsing the Web, yet still affect the user experience to a great degree. The Nonessential bracket contains the popular plug-ins Java and Silverlight. While these plug-in technologies are nowhere near as ubiquitous as Flash, certain applications like corporate intranet apps and Netflix simply will not work without them. Finally, the Unimportant bracket is for emerging technologies, such as HTML5 Hardware Acceleration and WebGL, which still don't really exist outside of testing/demo sites.
Now that the brackets are all sorted out, we can apply a numerical point system to the finishes of each bracket.
|Header Cell - Column 0||Winner||Strong||Average||Weak|
As you can see, we decided to apply negative point values to the Weak finishes and start the Average performances at zero for the Unimportant bracket. The Winner has also been de-emphasized over Strong finishes, with just a small tie-breaking bonus going to Winner.
|Header Cell - Column 0||Winner||Strong||Average||Weak|
|CSS||Safari||Chrome||Internet Explorer, Opera||Firefox|
|DOM||Safari||Chrome, Internet Explorer||Firefox, Opera||Row 2 - Cell 4|
|Reliability||Opera||Row 4 - Cell 2||Firefox, Internet Explorer, Safari||Chrome|
|Standards Conformance||Chrome||Firefox, Opera||Row 5 - Cell 3||Internet Explorer, Safari|
|Flash||Safari||Firefox, Internet Explorer, Opera||Chrome||Row 7 - Cell 4|
|HTML5||Internet Explorer||Firefox, Chrome||Opera, Safari||Row 8 - Cell 4|
|Memory Efficiency||Chrome||Internet Explorer, Firefox||Row 9 - Cell 3||Opera, Safari|
|Page Load Time||Internet Explorer||Chrome, Firefox, Safari||Opera||Row 10 - Cell 4|
|Responsiveness||Opera||Firefox||Chrome, Safari||Internet Explorer|
|Security||Chrome||Row 12 - Cell 2||Firefox, Internet Explorer, Safari||Opera|
|Startup Time||Opera||Chrome, Firefox||Internet Explorer||Safari|
|Java||Opera||Chrome, Firefox, Internet Explorer||Row 15 - Cell 3||Safari|
|Silverlight||Opera||Chrome, Firefox, Internet Explorer, Safari||Row 16 - Cell 3||Row 16 - Cell 4|
|HTML5 Hardware Acceleration||Internet Explorer||Firefox||Chrome||Opera, Safari|
|WebGL||Firefox||Chrome||Row 19 - Cell 3||Internet Explorer, Opera, Safari|
And the winner is...
Current page: Test AnalysisPrev Page Standards Conformance Next Page Crowning A Windows 7 WBGP Champion
Stay on the Cutting Edge
Join the experts who read Tom's Hardware for the inside track on enthusiast PC tech news — and have for over 25 years. We'll send breaking news and in-depth reviews of CPUs, GPUs, AI, maker hardware and more straight to your inbox.
1.what the benchmarks dont show is that in Firefox , if a tab has a heavy page with a lot of CPU intensive workload, the complete browser UI starts stuttering. That means the browser UI is on the same thread as the page loading.Reply
2. in the 40 tab test, try working in a tab during the loading of the 40 tabs. you will find lots of difference between browsers. FF hangs, Opera and Chrome remain fluid.
3. how about a test where a browser is using 1GB+ RAM and you are trying to open/close tabs. Then see the UI responsiveness. most browsers can easily handle 800MB RAM. but which browser easily handles 1.2GB+ RAM ?
IE9 does so good on HTML5 HWA accelerated benchmarks because its able to offload more of the processing to the GPU.Reply
i tested this and found that during a HTML5 benchmark, IE9 had the least CPU usage, and most GPU usage amongst all the browsers.
How many firefox users dont use ADblockPlus ? very very less.Also ABP developer is a regular contributor to the Firefox source code.Reply
maybe you should do a few memory benchmarks with ABP installed just to realistically judge what 99.99% of FF users go through.
WTF Chrome is already on 20?? It ninja updated to 19 just a few days ago..Reply
i won't ever use a browser a browser WITHOUT AD BLOCK Plus. (ABP)Reply
ABP works wonderful on Firefox, i RARELY see any ad. While I have used ABP on Chrome BUT its doesn't block half the ads.
I know its Not Google's fault, its just that ABP developers are putting more effort with Firefox.
So for me, Firefox > Chrome.
@mayankleoboy1: 1+2) Interesting, I'll be looking for that next time 3) That would require a different workload for each browser.Reply
IE9 does so good on HTML5 HWA accelerated benchmarks because its able to offload more of the processing to the GPU. i tested this and found that during a HTML5 benchmark, IE9 had the least CPU usage, and most GPU usage amongst all the browsers.Really interesting, what utility do you use for measuring GPU usage?
How many firefox users dont use ADblockPlus ? very very less.Also ABP developer is a regular contributor to the Firefox source code.maybe you should do a few memory benchmarks with ABP installed just to realistically judge what 99.99% of FF users go through.I'd estimate ABP usage on FF at around 5% or less based on ABP and FF usage statistics. Besides, that would give FF an unfair advantage.
Really interesting, what utility do you use for measuring GPU usage?
MSI afterburner for GPU. windows task manager for CPU.
@mayankleoboy1: 1+2) Interesting, I'll be looking for that next time
i sent a mail regarding this to Chris. but maybe i sent it too late for this article...
if you open multiple tabs together in chrome, it can use each CPU core for each tab. so if you have a quad core, and you open 4+ tabs together, the CPU usage will be 100% (using all 4 cores) during the tab loading time.Reply
but if you run 4 instance of dromaeo in 4 tabs, the CPU usage is still 25% (using only 1 core).
so chrome is not completely multiprocessing.
in IE10 beta, if you run 4 instances of dromaeo benchmark in 4 tabs, it uses all the for cores. so we can expect better multiprocessing from IE10 and win8 :)
@mayankleoboy1: I got that email yesterday or the day before, this article was completed a few days before that. Sorry, my inbox usually gets a few pages deep after a doing long benchmark-heavy article.Reply
Is Dromaeo (the DOM portion) working in Chrome for you? I could not get it to finish in Chrome or Safari on any of my Windows machines.
BTW, i run chrome dev version. so that could make a difference.