Slashdot Mirror
The More Popular the Browser, the Slower It Is
demishade writes "Peacekeeper, the browser benchmark from the makers of 3DMark, comes out of beta and shows an interesting (though perhaps not surprising) tidbit — the more popular a browser, the worse its performance. While it should not be surprising to anyone that IE slugs at the last place, the gap between Firefox and Chrome, is. Once IE's market share goes the way of the Dodo will web developers start cursing Firefox? How long until Google comes out with a JavaScript intensive application that will practically require Chrome to function?"
Chrome was designed with JavaScript performance as a top goal. So why are we surprised it performs well?
"No matter where you go, there you are." -- Buckaroo Banzai
If you look at it from a popular/performance perspective, you are going to find that, generally, the newer software is better performing, because that is a selling point above the competition. It will also be the least popular because it is newer.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
this really is a case of correlation not implying causation. Otherwise firefox's market share would have decreased from v2 to 3, and will decrease again when 3.5 is released.
Sure, it's a "fact", but I'll bet that in 5 years time this won't be the case. This "tidbit" does not allow us to make sensible predictions about the future of browsers.
I keep seeing reviews of how fast a browser is/isn't. Am I the only one that really doesn't care? All Browsers render faster than I can read the page anyway. I care about the way the browser looks/feels/renders/features. Am I missing something?
Javascript performance still doesn't matter for most users, and power users largely have Javascript disabled or blocked. Maybe Google needs to release a killer app that relies on Javascript and has borderline performance on anything slower than Chrome.
When we're just talking about loading web pages, no one is yet within shouting distance of FF with a good Adblock filter list.
JS benchmarks seem somewhat pointless for now. 99% of what we do on the web happens instantly (if you have a low latency connection) on all browsers if we stop the ads from loading.
"I zero-index my hamsters" - Willtor (147206)
It's so unfortunate that researchers these days don't realize that correlation can easily be a coincidence, and not a real relationship between two variables. It is especially unsuited in this case given the tiny number of data points and, oh, the convolution of these results with other factors like OS bundling (Windows/IE) and time on market (All 3, most significantly Chrome).
A more interesting (and likely actually related) set of data would be browser performance vs. market growth rate. Where are those numbers?
Also, web developers don't curse IE because it's slow. In fact, many pages are still static and don't feature nifty DHTML tricks, so the slowness of IE has no effect on the page at all. We web developers curse IE because it's not standards compliant and because making both the CSS and those nifty DHTML tricks WORK in IE is like eating barbed wire. Firefox has acceptable Javascript performance and is mostly standards compliant, and the existence of the Firebug plugin makes it invaluable as a web developer's test browser. I don't think web developers will curse a browser like Firefox for slow Javascript performance like we curse IE for violating all the standards.
"How long until Google comes out with a JavaScript intensive application that will practically require Chrome to function?"
Ans: never
because 80-90% of the market will choose not to
bother with that application because they don't
know how to DAU-EN-LODE and install a different
browser.
because 80-90% of the market will choose not to bother with that application because they don't know how to DAU-EN-LODE and install a different browser.
In that case, Google will just email their browser install file to them, because 80-90% of those people will be more than happy to click on anything in an email.
If I have been able to see further than others, it is because I bought a pair of binoculars.
This just in: People don't choose their browser based on Javascript performance alone.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
You just described IE.
But you lost me here.
Game! - Where the stick is mightier than the sword!
I've heard a lot of talk about Javascript performance as intensive Dynamic HTML applications become mainstream.
Most of the apps I seen really don't have that much Javascript when you compare it to the amount of code that is in your typical desktop app or server side application. And ultimately many of the functions are small.
What I've noticed is instead their is a difference in the rendering engine itself. Javascript might be a single line to change the CSS of an element or change the visibility attribute, but then the browser takes forever to collapse the item...or the CPU spikes when some huge element of a big page disappears and the whole page has to move over/up/down.
Are we really talking about how fast the DHTML engine responds or is Javascript really that stinky slow that changing the element underlying take a while. I'm not sure I care if calculating primes in JS could made faster. Isn't most of Javascript just mapping down to a C++ library below it?
(Speaking of which, isn't it a bit disingenous to compare Safari 4 BETA to the current version of Firefox? Why not compare the Firefox beta then? Smells of yeller-bellied journalism to me.)
It could be that most of their Safari visitors are using the beta, while most of their Firefox visitors are using a release version. Since they're trying to correlate a browser's market share with its performance, it would make some sense to choose the most common version of each contender.
Disclaimer: I am not saying this is the case, just offering it as a possible explanation.
The linked article seems to be quite devoid of propercontent ... after a test of some browsers on just one computer (and, I guess, just one OS) they deem that there is an inverse correlation between popularity among the people visiting their site and performance.
Not quite what I would call an accurate and scientific approach!
This being said, there might be a grain of truth in the very fact that the more popular the browser the more "corner cases" are exercised (and thus have to be implemented). By corner cases, I do not mean what the standard dictates, but what you find (ab)used on way too many pages.
No, those are the ones that are popular. What people don't like are browsers that adhere strictly to the standard when the web is full of pages that don't.
Rethinking email
Also, popularity tends to impede progress. The more people are using a software or hardware product, the more you have to lose by breaking compatibility with old version or doing something zany. Meanwhile, more obscure products have a greater need to do something a little zany in order to carve out their niche.
That doesn't explain why Firefox is so slow compared to Camino, Chrome, Safari, Opera, etc. If you were Microsoft and had a browser, you'd try to ship it with your OS too. Last I checked all popular linux distros ship with a browser (generally Firefox being the default) and OS X ships with Safari.
The problem historically hasn't been that Microsoft ships IE, but that its very difficult, if not nearly impossible to separate it from the OS completely.
Additionally, this isn't the 'problem' that the article talks about, its talking about it being slow. Tighter integration with the OS should make it faster, not slower. You're mixing up the real problems at hand here.
Tibbon
tibbon.com
I'd use a desktop application.
Bullshit. These are experimental options. They're NOT turned on for a reason. Specially, HTTP pipelines really fraks with some of the less sophisticated web servers on the market. They get confused and don't deliver the right set of responses. Firefox has the feature for testing and developer evaluation, but it's not ready yet.
That being said, the vast majority of the sites you visit won't have problems. But you have to know enough to understand what those are and whether it is worth it to you to enable this feature.
For those interested in the technical side, HTTP pipelining is a feature that makes use of the asynchronous nature of TCP/IP sockets. Rather than doing the usual HTTP/1.1 request/response, request/response cycle of HTTP/1.1, pipelining batch-sends all the requests, then batch receives all the responses. In effect, it looks like request/request/request/request, response/response/response/response. Very effective at reducing delays from network latency, but potentially very confusing for the server.
Javascript + Nintendo DSi = DSiCade
Bo-o-o-o-gus.
This "study" didn't measure browser speed at all. It compared only the speeds of the javascripts that the browsers use. TFA says so fairly clearly.
If you're making heavy use of sites that are mostly javascript, this is a useful study. For the rest of us, it's yet another case of measuring a tiny corner of what is claimed, and then asserting that this measures the whole thing.
Using similar reasoning, we can imagine an oceanographer measuring the parts of the ocean along the beaches where most people are found, and concluding that the oceans average about 2 meters deep. (There's gotta be a good auto analogy here, too.)
As someone else has pointed out, most "power users" of browsers mostly disable java and javascript (and Active-X and any other misfeature that lets strangers run code on their machines). They may use NoScript with FF and enable JS for selected sites. Or they may simply copy the links to another browser such as opera or safari when they want to use JS. So to them, firefox and mozilla may well be the fastest browsers, since they permit easy selective disabling of all scripting features.
And we should also note that the time to render most web pages is mostly the download time. If due to network delays it takes 23 seconds to download a page, and browser X renders it in .001 sec while browser Y renders it in .01 sec, there's no practical meaning to a claim that Y renders 10 times faster than X. If the page takes 23.001 sec to render in X, and 23.01 sec in Y, few people will be able to reliably tell you which is faster.
If this were announced as a comparison of various JS interpret speeds, I'd take it seriously. But claiming that it's about browser speed pretty well discredits the authors (and the editor who wrote the summary).
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Right.
1. How do you explain that IE8 is the youngest of the non-beta's and the slowest.
2. Why is it then that IE has more problems with standards? Does it check so much for broken html/css/javascript it can't even deal with standard compliant code? Oh and then explain how a trailing , in javascript FAILS under IE but not firefox.
3. So, IE8 has more features then firefox...
Something tells me you don't know what the hell you are talking about. Did you ever actually use any other browser then the one that came with your Dell?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Why does everyone think that Javascript is the only measure of speed? If your Javascript engine is ridiculously fast, but your browser UI architecture is too heavy-weight and stuff can't fly around as fast as the Javascript can request it to, then speeding up you JS engine isn't the thing you need to do.
XUL is why Firefox sucks. I thought it was mostly just shitty on Linux because nobody at Mozilla cares about Linux anymore, but I've been using it on Win32 some and it's unstable and slowish (but mostly just unstable) there too.
Chrome is crazy fast, but I think the JS engine is not the only reason.