[removed] Performance of .className Changes vs. .s

2020-07-23 08:03发布

Back in 2005, Quirksmode.com released this article:

http://www.quirksmode.org/dom/classchange.html

that showed "proof" that changing the style of an element by changing its class (ie. "elem.className = x") was almost twice as fast as changing its style via its style property (ie. "elem.style.someStyle = x"), except in Opera. As a result of that article, we started using a className-based solution to do things like showing/hiding elements on our site.

The problem is, one of our developers would much rather use jQuery's equivalent methods for this kind of thing (ie. "$(something).hide()"), and I'm having a hard time convincing him that our className-based function is worth using, as I can only find a single article written four years ago.

Does anyone know of any more recent or more comprehensive investigations in to this issue?

7条回答
男人必须洒脱
2楼-- · 2020-07-23 08:37

Micro-optimization is evil. I think unless you are hiding a seriously large amount of elements at once or something, the difference in milliseconds is unimportant if by some chance that article is still relevant nowadays.

With that in mind, I would go with jQuery's methods as they are battle tested and more concise.

查看更多
叼着烟拽天下
3楼-- · 2020-07-23 08:38

While I generally agree with the practice of using classes over style attributes for many reasons. Performance is one but consistency is another. I've often seen people do things like:

function toggle(element) {
  element.style.display = element.style.display == 'none' ? 'block' : 'none';
}

(or the jQuery equivalent)

Seems reasonable right? It is until you apply it to table elements that have default display values of, for example, table-cell (not block). The class method:

.hidden { display: none; }
...
function toggle(element) {
  $(element).toggleClass("hidden");
}

is much, much better for this and other reasons.

But the jQuery methods like hide() are an exception to this. They handle display setting correctly and give you the animations.

查看更多
4楼-- · 2020-07-23 08:40

Are you hiding hundreds of elements per second? If not, I'd say there are bigger fish to fry. Worse, a study done in 2005 says nothing about the performance of modern browsers. No IE7 or 8, No Firefox 3 (was 2 even out?), no Chrome.

But if you insist and want your fellow colleagues to follow suit, you should write a jQuery plugin that "hide()"'s using a class instead of a style.

查看更多
Summer. ? 凉城
5楼-- · 2020-07-23 08:43

You are talking about client code, it runs in the user browser so it does not load your server. I ignore the javascript in your client side but I guess is not crunching much CPU.

Your coleague use of jQuery is probably not having a great impact while it results in a more readable code. Therefore I think he does not need to be convinced at all.

查看更多
干净又极端
6楼-- · 2020-07-23 08:48

There is a flaw in the benchmark that article uses.

In my personal experience I've never seen a case where updating a className outperforms inline style setting. I have no concrete proof of this (I do vaguely remember an article I'm going to try to dig up), but I have noticed that large clientside apps (for example gmail, or google maps) prefer setting inline styles to classNames, and it was in the context of analysis of these apps that I first heard of the speed increase in doing so.

Note that I am not promoting one over the other: setting the className dynamically goes a long way in terms of maintainability/readability and separating concerns.

查看更多
Rolldiameter
7楼-- · 2020-07-23 08:54

Test it yourself. There's a tester on the page you linked. Test performance on your target browsers to determine the best method to use, performance-wise.

Personally, I would choose readability over performance. Besides, the tides may turn later (if they haven't already**). If it makes sense to use a class (i.e. you use the style for many elements), you might as well use a class. If the CSS is for an animation on an element, use style. For either, prefer jQuery's functions as they are (1) more consistent and (2) more robust and tested.

**For Opera 10, at least, the speed has definitely improved. The tests are 5/12ms locally for Opera 10, 57/88ms for Firefox 3, 14/36ms for Google Chrome, and 125/118ms (!) for IE7. IE7 (perhaps your target browser) has about the same speed for either, with style changing slightly in the lead!

Premature optimization is the root of all evil.

查看更多
登录 后发表回答