This is the follow-up to “Don’t use class names to find HTML elements with JS“, where we take a look at a new test case, with results proving that the negative speed impact of finding elements by data attribute instead of by class name is negligible. The reasons for using this approach are in the original post and still current. If you just don’t like the concept, there’s no way I can persuade you. But if it’s about the numbers, here are the metrics.
Targeting elements by data attribute using jQuery is almost as fast as doing so by class name. Except in IE, but even with the slower speeds it seems to be fast enough for real world situations (IE9 takes 9 milliseconds to find 376 elements in a DOM of 1,364; Chrome takes 1 millisecond).
Creating a real world test
For a while I ignored those who didn’t agree, mostly because a lot of them used arguments I couldn’t compete with (“no Sir, my parents had me tested” would have been the best response to many). The thing kept nagging though. Was I wrong? Was the test case I used indeed insufficient (I didn’t write it myself)? Would that have a massive impact on the numbers? There’s only one way to find out, so I created a life-like test case at jsPerf. Dozens of people ran the tests on a multitude of different devices, with yours truly testing on iPads, iPhones, Android phones & tablets, Windows Phone and BlackBerry. Plus my desktop browsers and a bunch of browsers running on Windows in Parallels.
For the test case I took CNN.com’s HTML source, consisting of 1,364 HTML elements. I added class names and data attributes to all
li‘s (after first removing the ones already in place), totaling 751 HTML elements. The code I inserted looks like this:
class="gender male age age-9" data-gender="male" data-age="9". The class names and values for the
data-gender data attributes (
female) alternate, so there are 376 elements for males and 375 or females. I ended up not using the ages for this test, but feel free to reuse if you want to test finding age ranges for instance. The ages run from 1 to 10 and aren’t evenly distributed.
Because I didn’t want people to run three test cases separately, I implemented 6 tests to satisfy my curiosities. Only two of them I consider to be relevant for this case, so I’ll only discuss
In this case I’m using jQuery to find all people of the male gender. I’m using the combination of two class names, as opposed to just
.male, because I’m trying to mimic the key/value combination that the data attribute brings to the table. That seemed fair to me.
The jsPerf test determines how often per second it can perform both of the above operations. It does so by running the test multiple times, coming up with an average. This is dependent on device, operating system and browser. A faster laptop will yield more operations per second, which is why it’s great that so many people participated, averaging the results.
Without further ado, here are the most significant results (ordered by number of test runs and OS):
|Browser||Test runs||Ops/sec class name||Ops/sec data attribute||Slower by|
|iPhone iOS 5.1.1||6||54||51||5.56%|
|iPad iOS 5.1.1||5||59||55||6.78%|
|IE 9.0.6 (Windows Phone)||4||31||16||48.39%|
These are the most used or exotic browsers. Finding elements by data attribute is slower, but the speed decrease doesn’t worry me. First, it’s a relatively small difference. On the major modern browsers (Chrome, Safari & Firefox) it’s at most 6.9% slower. That doesn’t sound like much by itself, and even less so considering this still handles at least 404 operations per second (double that for Chrome). That’s finding 376 elements in a DOM of 1,364 elements in 2.5 milliseconds in the slowest browser of the three (1 millisecond in Chrome).
Finding elements by data attribute is slower on handheld devices, for obvious reasons. iOS is 6.2% slower on average. Android is 3.9% or 11.1% slower, but I guess this relies heavily on the device used in combination with the OS version. Some of the Android tests were run on the cheapest and slower models out there, all from our Open Test Lab. Still, the slowest Android takes only 40 milliseconds for the operation. Surprisingly, BlackBerry sees hardly any difference in speed between the two approaches. Windows Phone: 63 milliseconds per operation.
Is it slower? Yes. Is it much slower? It depends, but in general: no. Should you avoid using data attributes in favor of class names because it’s slower? No!