Why is jQuery selector function so slow compared to native DOM methods

I know this topic has been debated in general several times already, but I am looking for a more technical and detailed insight to understand what is really going on.

I devised a series of tests to compare speed of jQuery's most basic selectors '#id' and '.class' to various native DOM methods.

What I wish is to find out exactly why the results are what they are.

Here are the tests : http://jsperf.com/jqueryspeed

The main thing noticeable, is that getElementById is clearely the fastest of all. To compare, I added both jQuery('#id') and jQuery.fn.init('#id') as tests, the difference between the two is that the first one does instanciate a whole new jQuery object, while the second one only runs the prototype function, and is thus faster. So, the difference between those two is understandable.

The main difference that I do NOT understand however, is the huge gap between the speed of getElementById and the speed of jQuery.fn.init, which has a simple test to handle a simple ('#id') request in a specific way, falling back to a call to getElementById itself.

So, why for example on Chrome, is this method about 8 times slower than the native one, even though it basicly is just a wrapper for it ?

It is also about 3-4 times slower than the wrapped getElementById $(document.getElementById('#id'))...

Any ideas please ?

This is the amount of code jquery goes through when we use a simple $('selector')


As you can see,there are plenty of validation done,regex matches,cross browser tricks etc.

Its important to realise that jquery is a library built on javascript.Javascript executes directly on the browser.Where as jquery processes quite a lot of javascript code before being executed by the browser.

I personally prefer jquery.I am really not bothered about saving those nano seconds.The level of simplicity that jquery provides is phenomenal and an artpiece in itself.

There is nothing that jQuery can do as fast as native javascript and that is for a reason: it works hard to make your code cross-browser compliant and easy-to-use. It builds a jQuery object out of most method calls. In that matter, jQuery will be a lot slower than the smallest datapath required because it wants to offer features that are ready to use.

Let's compare these two "similar" calls:

document.getElementById("box"): Native method that does a simple lookup operation at a lower level than JavaScript. It then returns the DOM element that is already loaded in memory. This is one of the fastest methods.

$('#box'): Here, jQuery will begin with some parsing over what you ask it to do. For example, it will validate that it is a well-formed selector, then try to recognize what type of selector it is. Once it's done with the validation, it will try to get the element with ID "box". After then, he will create a new jQuery object, filling it with every expected attribute and making sure that all the browsers (and older browsers too) are getting the same results. This includes a lot of fallbacks and compliance tests. When the object is ready-to-use, you get the element with ID "box". Not as straightforward as getElementById(). When jQuery features aren't required on the targeted element, many would prefer to use getElementById('box') instead of $('#box').

UPDATE - 15/02/17:

With jQuery >= 2.0 having no more support for the infamous IE 6/7/8, some compatibility tests aren't needed anymore, making jQuery lighter and faster. Overall performance can be improved by using jQuery >= 2.0 instead of 1.x if you don't need to support older browsers.

I've added another test case for jQuery.fn.init(document.getElementById('id')) which was faster than most other methods because it does neither parse string nor create new jQuery object (it was about 50% behind getElementById, jsperf), and when I see the source of jquery code that executes during jQuery.fn.init call:

function (selector, context, rootjQuery){
  if (selector.nodeType) {
          this.context = this[0] = selector;
          this.length = 1;
          return this;

I can only conclude that Chrome and Firefox engineers did very good job at optimizing native DOM operations.