Comparing Browser JavaScript Performance

Thwomp writes "Over at Coding Horror Jeff Atwood has an interesting writeup on JavaScript performance in the big four browsers. He used WebKit's newly announced SunSpider to produce the results. If a probable anomaly in the IE7 results is overlooked, Firefox 2 is the slowest of the bunch. Atwood has also benchmarked the latest Firefox Beta, and its performance seems to be improved significantly."

Opera

[QuietLagoon]

Looks like they are finally getting their javascript act together. After being a sore point for so many years, a working javascript in Opera will be welcome.

client side javascript will become our enemy

[icepick72]

Because of the incompatibilities and different bugs between browser JavaScript implementations for God's sake let's not have a world where client-side JavaScript is so fast we use it for everything. Development time will increase one more fold for each browser you want to support, and sometimes additionally for each minor version It will be hell on earth I predict.
My basic rule of thumb has also been that client scripting should enhance and application but not be required for the application. In other words with JavaScript disabled the application might act rudimentary but will still produce results.

Re:Ooh ooh let me guess

[greg1104]

Yeah, what's far more important to me than "how fast does this browser run Javascript?" is "how easily does the browser non run Javascript?"

Re:client side javascript will become our enemy

[SirJorgelOfBorgel]

Oh really? JavaScript is not that hard to get to work correctly cross browser. I spent a LOT more time changing CSS things to work nicely than I do on JavaScript and I do use a lot of JavaScript. If you use a decent JavaScript toolkit, like for example jQuery, it's even faster and you hardly have to worry about it at all. For any nice advanced stuff you simply have to use JavaScript, and that's what it's there for. You want to disable JavaScript? That's fine by me, but you WILL be missing out. Really, what's next, catering to people who don't have CSS? Sure there are a lot of people who think sites should still work and look readable without CSS, but really, that depends on the market segment of the website. You can't make rich websites without CSS and JavaScript. Simple. Not every site can get away with looking like Google.com, it depends on the target audience and the content.

better idea

[ILuvRamen]

Why don't people just stop making ridiculously complicated pages? Have you seen the yahoo hompage? Aol's is even worse. And Ebay's is a ridiculous nightmare. I don't who thought that looked good or thought people will look at or read that much but they should be fired. No browsers in the world could render those pages in under a second the way they're supposed to look. Plus remember that like 99% of page load slowness is from ad servers failing to load the ads fast enough

Re:Hmmm

[chrb]

He says: "What surprised me here is that Firefox is substantially slower than IE, once you factor out that wildly anomalous string result."

To paraphrase: "What surprised me here is that Firefox is substantially slower than IE, once you manipulate the experimental data by removing something that IE is particularly slow at."

And guess what? If you remove string ops, bit ops, and date ops, then Firefox is probably faster than IE. ;-)

Re:Hmmm

[gazbo]

Exactly because it's an order of magnitude slower. In all other tests it is a similar speed to all other browsers, then in one particular test it is ridiculously slower. There are no other tests or browsers that exhibit this behaviour, else I expect he'd have discounted them as anomolous also.

There could be a good reason for the test showing poor performance - say IE is shit at string concatenation - and then the result reflects badly on IE. Or, it could be that for whatever reason the benchmark hits some strange edge case that virtually never crops up in normal usage, in which case the benchmark should be thrown out. But without further information you have to just treat the result as null. It's an unknown.

Re:A grain of salt

[Mini-Geek]

Take note of the tests for the latest Firefox beta though, notice that he's using a different system with .2Ghz more and he's on a 64 bit system versus a 32 bit. Although it's not a huge leap, it IS a difference. Different system different benchmark.

Yes, it's a different system, so you shouldn't compare that FF3 number to the IE/Opera/Safari numbers, but you can still compare it to the FF2 number there (BTW that FF2 number is even a little slower than the one that all tests were run), which obviously shows that it's faster.

Re:Hmmm

[morgan_greywolf]

IE wouldn't be faster than that much faster than Firefox 2, and no faster than Firefox if we 'filtered out' this anomalous reading. Assuming the string operations took 1.5 seconds (a nice round number in between Firefox's and Opera's times), we could subtract 12.9 seconds from IE's overall time of 21.2 seconds and arrivate at 8.4 seconds, putting it neck-and-neck with FF3 and still less than 25% faster than FF2's performance. FF2 is slow, but he makes it sound like FF2 sucks badly and it's just not that bad.

That being said, one can't be sure that IE7's string reading was 'anomalous' without significantly more data.

Also, I wouldn't make that much of the difference between Vista 32 and Vista 64 or between a 3.0 Ghz and a 3.2 ghz Core 2 Duo. Browser performance is likely extremely similar on both systems for all browsers, with the possible exception of IE7's (I have a sneaking feeling the 'anomalous' reading is an issue particular to 32-bit Vista)

Good one

[glwtta]

You know, it's cute to refer to "the big four" browsers, but you could've at least listed what you think those are - we are not mind readers.

Had it been "the big one and the one that just edged into relevance", then most people would know what you meant.

Re:client side javascript will become our enemy

[s4m7]

Really, what's next, catering to people who don't have CSS?

That's exactly why CSS exists... to separate content from layout/display characteristics. You can make an entirely graphical-button image-chopped page with all kinds of rollover goodness, and as long as you write your (x)html and CSS properly, it will break down fine in a text or mobile browser. Using techniques like image replacement is critical if you want your flashy website to be accessible to people using screen-readers or mobile browsers.

This of course assumes that your site has some kind of content, other than just pure uncategorized imagery.

Otherwise you could just put all your images in a table, put no alt attributes in and who cares? Oh, only the 40 million blind people in the world, and anyone who would want to use your site from a mobile device. Ahh, but those people probably aren't in your "target market" are they?

Just a note: it wasn't "supposed"

[ESqVIP]

AFAIK, Tamarin was since the beginning scheduled for Gecko 2 (i.e., Firefox 4). So, don't worry, it's not like it didn't make for Fx3, it wasn't supposed to be on this week's beta at all.

IE JScript string perf

[browneye]

Posted in the comments to TFA:

There was an article about IE's string performance in the Jscript team blog on MSDN a while back : http://blogs.msdn.com/jscript/archive/2007/10/17/performance-issues-with-string-concatenation-in-jscript.aspx [msdn.com]
Aaargh! on December 20, 2007 11:34 AM

Re:Bah humbug!

[Phroggy]

First off IE6 is not tested, while it is still the most used browser.

The WebKit team released a test suite, they didn't release test results. If you want to test IE6, then test IE6!

Yes in pure JavaScript like this, IE might be faster than Firefox. But in real world situations it clearly isn't. There is no test done on layout manipulation (and such) using JavaScript. Internet Explorer is notoriously horrible at this, especially if you use it combination with PNG's with alphachannel or complex CSS.

This is intentional. This is specifically a JS speed test, not a DOM speed test. If IE's DOM handling is horribly slow, that's a different issue - not an unimportant one, but a different one. This test is really deigned for browser developers, not users, and that's important: while users don't usually care about specific implementation details and just want an overall faster experience, developers can only focus on specific implementation details. Thus, developers interested in improving JavaScript performance need to be able to look at JavaScript performance without being thrown off track by DOM problems, which are probably the responsibility of a completely different team of developers. JavaScript developers probably can't fix DOM problems, just as DOM developers can't fix JavaScript problems.

Re:A grain of salt

[philwx]

Try a heads up between Firefox and IE after the average-joe user has had a few weeks to accumulate spyware.

I'd like to see those results.

Re:A grain of salt

[Jeffrey Baker]

I think this "benchmark" is deeply weird. It only exercises the pure execution paths, while pretty much ignoring all of the data structures that make a web page work. Every web app I've written or tried to optimize is limited not by time spent in javascript, but rather time spent manipulating the dom and drawing.

I guess there's value in such a benchmark, but it goes against the conventional wisdom of Amdahl's Law. If JS execution accounts for only 10% of the runtime of your application, it will be of little value to make JS 20% faster. You must concentrate on the other 90%.

What I learned.

[Vexorian]

Once you need a benchmark to prove something is faster than something else, then it doesn't really matter which one you uses.

Re:A grain of salt

[Jeffrey Baker]

I just profiled your page with Venkman and it seems that > 96% of the CPU time is spent in document.getElementsByName. Were you trying to prove my point?