Performance of Jquery Selectors Vs CSS3 Selectors

Performance of jquery selectors vs css3 selectors

jQuery's selector engine shares most of the same syntax as CSS, effectively extending the selector standard. This means you can pass most valid CSS selectors (with some exceptions) to jQuery and it'll handle them just fine.

jQuery optimizes valid CSS selectors for modern browsers that support the selectors API by passing them directly to document.querySelectorAll(). This means your jQuery selector will have almost equal performance with the equivalent CSS selector, with the only overhead being the $().css() and the selectors API calls.

For browsers that don't support the selectors API, well, it's pretty obvious that jQuery will be really slow as it has to do all the heavy lifting on its own. More importantly, it will simply fail on the exceptions that I link to above as well as any other CSS selectors a browser doesn't support.

However, with all that said, jQuery will invariably be slower, as the browser has to run through a script and evaluate it before getting a chance to apply and compute your styles.

And after all this, honestly, it's not much even if you had hundreds of items — chances are the browser is going to take longer to fetch the markup than to render the styles. If you need to do styling, and CSS supports it, why not use CSS? That's why the language was created in the first place.

How do the performance characteristics of jQuery selectors differ from those of CSS selectors?

$("#foo") is better than $("div#foo")

Since id is unique in the document you don't have to prefix it with a tag name.

Here is a nice link

jQuery Performance Rules

Performance: Pure CSS vs jQuery

  • CSS doesn't have to be evaluated by the browser

    No. CSS is a language that you write your stylesheets in, which then have to be loaded, parsed and evaluated by the browser; see below.

  • jQuery has to be evaluated by the browser

    Yes, because...

  • jQuery goes through a scripting language

    Yes. jQuery is written in JavaScript which, like CSS, is a language which has to be parsed and evaluated by the browser; again, see below.

Doesn't CSS have to be evaluated by the browser and also goes through a scripting language?

It has to be evaluated by the browser, but as a language in its own right, it's implemented in native code similarly to the other core language features of a layout engine, like an HTML parser and a JavaScript engine. CSS implementation does not happen through a scripting language (unless, of course, the layout engine itself is written in one).

CSS styles are exposed to scripting languages via the CSSOM, which is not the CSS implementation itself, just a scripting API which you could consider as sort of a CSS equivalent to the DOM for HTML.

jQuery is written in JavaScript, which is then run by the browser's JavaScript implementation. If you use jQuery to apply CSS, then jQuery has to access the DOM and CSSOM, which are again implemented in JavaScript, which the browser has to run.

This is similar to using jQuery selectors versus the native Selectors API. jQuery selectors are implemented in Sizzle, a JavaScript selector library, while document.querySelector() is a DOM method that allows you to use a browser's natively-implemented selector engine directly from a script.

Selector for best performance in jQuery?

If all you want is all instances of DOM elements that match .my-class, then I see no reason why you should use anything other than:

$('.my-class')

The others are all more specific selectors and can be used if you want to narrow the selector to more than just $('.my-class').

If you're really trying to fully optimize performance, than using jQuery in the first place is likely not the desired choice as the overhead of jQuery initialization and jQuery objects tends to slow things down. You use jQuery because it's quick to code and offers great cross-browser support and a bunch of useful methods. You don't use jQuery to optimize performance.

If you really want to compare the performance of your four jQuery options, then you will have to design up a representative set of HTML (which has to include lots of other things to be truly representative of a real world situation) and then test each of your selectors in some benchmarking tool like jsperf and run that test in all browsers that you care about and with the versions of jQuery that you will be using and then see if you can come to some particular conclusion.

This smells like an attempt at premature optimization. Write your code first as simply as possible and only spend time optimizing performance when you've actually measured that you have a performance issue and that this is the place in your code where the performance bottleneck is. 99.99% of the time, the performance of a particular selector is not going to make one iota of difference in your code. Code simply and without complication first. In the 0.01% of the time that you actually want to optimize your code, you will probably care so much about performance that you will either pre-cache the list of elements or you will not code it in jQuery in order to avoid the jQuery object setup and overhead.

Here's a jsPerf: http://jsperf.com/jquery-selector-comparison-specificity/4. This shows relatively little difference between the options when tested in the latest versions of Chrome, Firefox and IE. There is a slight bias in favor of the $('.my-class') option.

And for reference, you will find that:

document.getElementsByClassName("my-class")

is as much as 50x faster than any of the jQuery options.

Here's a screenshot of the jsperf results in Chrome:

Sample Image

Conclusions

  1. For normal coding where you haven't proven you actually have a performance issue that you need to spend time optimizing, use the simplest selector that meets your selection objective.

  2. If it's really performance critical, use plain Javascript, not jQuery.

Selector Performance - 'E#id' vs '#id' - in CSS and jQuery

Browsers read the selectors right to left so there is little to be gained by prefixing anything before the id; it is redundant at that point. Source:
Writing Efficient CSS from Mozilla

Here's a real world example to test it for yourself. TL:DR; it doesn't seem to matter enough to make a difference.

Relevant further reading from a previous Stack Overflow question

CSS/jQuery performance - Is it better to provide higher resolution selector

Considering these jQuery statements

Method 1. $("#name")
Method 2. $("input#name")
Method 3. $("div input#name")

all the three statements are equally good since id always need to be an unique value. So $("#name") is same as $("div input#name") unless dom have multiple field with same id

Now considering the css lines, it depends on the specificity.

#name { color: red; }input#name { color: yellow; }div input#name { color: green; }
<div>  <input id='name'></div>

Performance differences between using :not and .not() selectors?

As you can see from the jsperf test, :not is on average about twice as fast. Overall though this performance will likely be a very small part of your overall execution time.

The jquery docs state:

The .not() method will end up providing you with more readable
selections than pushing complex selectors or variables into a :not()
selector filter. In most cases, it is a better choice.

So really it's up to you to decide if the fractions of a second you gain outweigh the readability.

CSS and jQuery Selector Speed

I'd say that it's extremely unlikely that it makes any real-world difference. In theory, yes, there's one fewer check required (because div#foo really does need to be a div to match the selector, according to the spec). But the odds of it making any real difference in a real-world browser app? Near zero.

That said, I always cringe when I see things like div#foo in HTML applications. HTML has only one ID-type attribute (id), so there's no need for the further qualification. You make the CSS selector engine (either the browser's or jQuery's) work harder to figure out what you mean, you make the selector fragile (if the div becomes a footer, for instance), etc., and of course you do leave yourself open to a stoopid selector implementation that fails to recognize that it can look something up by ID and then check to see if it's a div and so goes looking through all the divs. (Does such an implementation exist? Possibly, you never know.) Barring some edge cases, it always makes me think someone doesn't quite know what they're doing.

So for me, speed isn't the main argument. Pointlessness is. ;-)

Performance of jQuery selectors vs local variables

Reusing the selector reference, your first case, is definitely faster. Here's a test I made as proof:

http://jsperf.com/caching-jquery-selectors

The latter case, redefining your selectors, is reported as ~35% slower.

Performance of jQuery Selectors with ID

A direct ID selector will always be the fastest.

I've created a simple test case based on your question...

http://jsperf.com/selector-test-id-id-id-id-class

Selecting nested ID's is just wrong, because if an ID is unique (which it should be), then it doesn't matter if it's nested or not.



Related Topics



Leave a reply



Submit