Basically, is
$("#someid")
or
$(".someclass")
faster than
$("[someattr='value']")
I would imagine that it is (that is, selection by id is fastest, then class, then attribute), but does anyone know for sure?
Basically, is
$("#someid")
or
$(".someclass")
faster than
$("[someattr='value']")
I would imagine that it is (that is, selection by id is fastest, then class, then attribute), but does anyone know for sure?
Selecting by ID is the fastest, because it maps directly to getElementByID, the other 2 has to check each element to determine the selected elements.
If you must select using class or attribute, then try enclosing the search in a ID. ex.
Id is fastest, because it is the only element that can have that identifier. Many objects could possibly have the same class name. Someone could verify this, but it would seem like the document would not need to be traversed any further once the id was found. For classes this may not be the case?? HTH
ID is unique and if you only want to select one/first element here the equivalent
Test url: http://jsperf.com/jquery-selector-speed-tests/98
The id will always be fastest as it it unique on the page. The class "may" be faster than an attribute but it depends.
The real kicker here is selection of a class within and ID may NOT be faster than just selection of the class. It will depend on the page and browser. In my testing, selection of a complex page with a limited number of elements with a "class" where the parent of the class element had an id such as:
a selector such as
$('.iamin','#iamout')
was not always as fast as$('.iamin')
Not all browsers support select by classname (natively), but modern/newer ones do and thus it might offer better performance depending upon which browser you have.
If you need to have optimum performance you will need to test your exact page.
ID is absolutely the fastest. Part of the reason is that ID is supposed to be unique, so the API stops searching after the ID is found in the DOM.
If you must use a class or attribute selector, you can improve performance by specifying the optional context parameter.
For example...
Where
somecontainer
is something like a div, surrounding an element with classsomeclass
. This can offer a huge performance benefit in the cases wheresomecontainer
comprises a small fraction of the DOM.UPDATE:
I did some tests a couple years ago around the context parameter. After reading the comments below I was curious if anything has changed. Indeed, it seems the scene has changed somewhat with today's browsers. Maybe it also has to do with improvements in jQuery? I don't know.
Here are my results with 10,000 iterations (code is below):
IE9
$(".someclass")
- 2793 ms$(".someclass", "#somecontainer")
- 1481 msChrome 12
$(".someclass")
- 75 ms$(".someclass", "#somecontainer")
- 104 msFirefox 3.6
$(".someclass")
- 308 ms$(".someclass", "#somecontainer")
- 357 msSo among these big 3 modern browsers, the context parameter only seems to help IE9. Older browsers will also benefit from the context parameter. But considering the prevalence of each of these browsers and averaging everything out, the net gain is somewhat of a wash now.
And here's the code in case anyone wants to try it themselves...
ID and class selectors, at least when used by themselves, tend to be faster, whether for jQuery or for CSS. This is due largely to the fact that browsers have optimized algorithms for IDs and classes in their DOM/CSS engines.
In modern browsers with recent versions of jQuery, any selector strings that are understood as supported CSS selectors by a browser will be handled by
document.querySelectorAll()
, offering maximum performance as long as standard CSS selectors are used. Non-standard selectors or older browsers are taken care of by jQuery and/or the Sizzle library, which do their best to make use of the DOM's get-element(s) methods to traverse the DOM.The most important thing to remember is that performance will vary from browser (version) to browser (version) because of differing DOM implementations. At least, that's how I believe things are.