1

just wondering what selector performance is like for [data="what"] pseudo performance if anyone has a good article/benchmark for this or any personal experience?

Basically I've peppered my HTML with data-eid, data-mid, data-sid with HTML5 elements like:

<section data-mid="1">
    <article data-eid="1">
        <a data-sid="1"></a>
        <a data-sid="2"></a>
        <a data-sid="3"></a>
    </article>
    <article data-eid="2">
        <a data-sid="4"></a>
        <a data-sid="5"></a>
        <a data-sid="6"></a>
    </article>
</section>
<section data-mid="2">
    <article data-eid="3">
        <a data-sid="7"></a>
        <a data-sid="8"></a>
        <a data-sid="9"></a>
    </article>
    <article data-eid="4">
        <a data-sid="10"></a>
        <a data-sid="11"></a>
        <a data-sid="12"></a>
    </article>
</section>

Pretty much wanted to use it in jQuery for selecting particular m e and s things on my page. I know atm that an m is a section, that an e is an article and an s is an anchor.

I would usually select in jQuery using something like $('.m[mid="1"]') but is it much quicker than: $('section[mid="1"]')... I guess not?

I just don't want to make the user download a load of extra class="m" in my code. I know currently I'm tying my front-end with my JS-end code by forcing the elements to be a certain type where class="m" would decouple it to be anything in the future.

What do you think?

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
creamcheese
  • 2,524
  • 3
  • 29
  • 55
  • Personally I use a class in such situations, but it is a worthy question. – Pointy Dec 10 '11 at 15:36
  • I heard CSS profilers are coming: http://bricss.net/post/13884376788/the-css-profilers-are-coming – Cyrille Dec 10 '11 at 15:36
  • @Cyrille: This could just be tested on http://jsperf.com/ since it's actually JavaScript. – pimvdb Dec 10 '11 at 15:41
  • [Here is a jsperf test](http://jsperf.com/classes-and-data-elements) between find-by-class and find-by-attribute. – Pointy Dec 10 '11 at 15:47

5 Answers5

1

Your question title doesn't seem to match the question text. If you're specifically asking which of a[data="what"], a.what, and a#what, then you've listed them in increasing order of performance. You should also be able to simplify a#what to #what since IDs only apply to a single element anyway.

Michael Mior
  • 28,107
  • 9
  • 89
  • 113
  • Felt I had to add this since the [css-selectors] tag was (still is) in the original question: an ID selector in a stylesheet is expected to apply to *all* elements with that ID, no matter what the HTML spec says. This is different from `document.getElementById()` which always returns one element at a time if there's such an element. – BoltClock Dec 10 '11 at 15:51
  • Just because you CAN have multiple elements with the same ID doesn't mean you SHOULD. While you certainly can use an ID in a jQuery selector to retrieve multiple elements, having multiple elements with the same ID is a bad idea to begin with. – Michael Mior Dec 10 '11 at 18:30
1

When I write HTML that's intended to communicate something to unobtrusive JavaScript that's going to control behavior, I do this:

<div class='some-behavior' data-param-for-behavior='whatever' data-another-param='12'>

Then the code can apply itself based on class name, which is (in modern browsers) pretty fast, and get the parameters with ".data()".

Fetching by class name:

var elementsToControl = $('.some-behavior');

in modern browsers is way faster than

var elementsToControl = $('[data-param-for-behavior]');

edit — wow mind blown - the by-attribute method, with a tag name, is faster than by-class in Chrome. I'll try by-class with a tag name too ... edit again nope. Boy, sometimes I just wonder :-)

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • I like to see attribute selectors and class selectors as rivals, performance-wise. – BoltClock Dec 10 '11 at 15:55
  • @BoltClock well while Firefox performed as I expected, I was very surprised at Chrome. I think I'll fool with the test and mix up the HTML some more; currently the elements are all `
    ` elements, so a mix with many different tags might be interesting too. I didn't even bother to try IE but of course that'd be interesting too.
     – Pointy Dec 10 '11 at 16:53
0

In this stack question they are also talking about JQuery selectors performance, in which one answer specifically talks about IDs and that in general those are faster than anything else...

Community
  • 1
  • 1
Leon
  • 4,532
  • 1
  • 19
  • 24
0

This is an interesting question, but I think you are optimizing something that doesn't need to be optimized. I would check two things:

  • How many of these mid/sid/eid elements are there? Less than 10,000? OK.
  • Does your web server have gzip compression enabled? Yes? OK.

You can take a look at your page with Chrome or Firefox's built-in debug tools to get a sense of how long things are actually taking to download and run.

Not trying to be mean or condescending, but just speaking from experience. Also, others have already posted good links! :)

Good luck!

Jeff Meatball Yang
  • 37,839
  • 27
  • 91
  • 125
0

You should only use class selector in your example, here is why:

[attr] selector is slow and not backwards compatible (well, custom attributes are not backwards compatible, too) ( @Pointy, [attr] can be made faster than ., by using named buckets, but this is not yet the case with most browsers )

# selector is super-fast, but id's must be unique, element can have only one id, and all id's within document are automatically becoming properties of window object in javascript (in all browsers).

. selector is fast, backwards compatible and has no limitations, described above.

c69
  • 19,951
  • 7
  • 52
  • 82