jQuery Performance Rules

1768 6

Once upon a time, all we needed to worry about was reducing Bytes and Requests and playing around with load order to make things faster. Nowadays, we are increasingly impacting one more major component in performance – CPU utilization. Using jQuery and other frameworks that make selecting nodes and DOM manipulation easy can have adverse affects if you’re not careful and follow some simple practices for reducing the work the browser has to do.

  1. Always Descend From an #id
  2. Use Tags Before Classes
  3. Cache jQuery Objects
  4. Harness the Power of Chaining
  5. Use Sub-queries
  6. Limit Direct DOM Manipulation
  7. Leverage Event Delegation (a.k.a. Bubbling)
  8. Eliminate Query Waste
  9. Defer to $(window).load
  10. Compress Your JS
  11. Learn the Library

1. Always Descend From an #id

The fastest selector in jQuery is the ID selector ($(‘#someid’)). This is because it maps directly to a native JavaScript method, getElementById().

Selecting Single Elements

<div id="content">
 <form method="post" action="/">
 <h2>Traffic Light</h2>
 <ul id="traffic_light">
 <li><input type="radio" class="on" name="light" value="red" /> Red</li>
 <li><input type="radio" class="off" name="light" value="yellow" /> Yellow</li>
 <li><input type="radio" class="off" name="light" value="green" /> Green</li>
 </ul>
 <input class="button" id="traffic_button" type="submit" value="Go" />
 </form>
</div>

Selecting the button like this is slower: var traffic_button = $(‘#content .button’);
Instead, select the button directly: var traffic_button = $(‘#traffic_button’);

2) Selecting Multiple Elements

The second fastest selector in jQuery is the Tag selector ($(‘head’)). Again, this is because it maps to a native JavaScript method, getElementsByTagName()

<div id="content">
 <form method="post" action="/">
 <h2>Traffic Light</h2>
 <ul id="traffic_light">
 <li><input type="radio" class="on" name="light" value="red" /> Red</li>
 <li><input type="radio" class="off" name="light" value="yellow" /> Yellow</li>
 <li><input type="radio" class="off" name="light" value="green" /> Green</li>
 </ul>
 <input class="button" id="traffic_button" type="submit" value="Go" />
 </form>
</div>

Always prefix a class with a tag name (and remember to descend from an ID):

var active_light = $(‘#traffic_light input.on’);
Note: The class selector is among the slowest selectors in jQuery; in IE it loops through the entire DOM. Avoid using it whenever possible. Never prefix an ID with a tag name. For example, this is slow because it will loop through all <div> elements looking for the ‘content’ ID:

var content = $(‘div#content’);
Along the same lines, it is redundant to descend from multiple IDs:

var traffic_light = $(‘#content #traffic_light’);

3. Cache jQuery Objects

Get in the habit of saving your jQuery objects to a variable (much like our examples above). For example, never (eeeehhhhver) do this:

$('#traffic_light input.on).bind('click', function(){...});
$('#traffic_light input.on).css('border', '3px dashed yellow');
$('#traffic_light input.on).css('background-color', 'orange');
$('#traffic_light input.on).fadeIn('slow');

Instead, first save the object to a local variable, and continue your operations:

var $active_light = $('#traffic_light input.on');
$active_light.bind('click', function(){...});
$active_light.css('border', '3px dashed yellow');
$active_light.css('background-color', 'orange');
$active_light.fadeIn('slow');

Tip: Since we want to remember that our local variable is a jQuery wrapped set, we are using $ as a prefix. Remember, never repeat a jQuery selection operation more than once in your application.

Bonus Tip – Storing jQuery results for later

If you intend to use the jQuery result object(s) in another part of your program, or should your function execute more than once, cache it in an object with a global scope. By defining a global container with jQuery results, we can reference them from within other functions:

// Define an object in the global scope (i.e. the window object)
window.$my =
{
 // Initialize all the queries you want to use more than once
 head : $('head'),
 traffic_light : $('#traffic_light'),
 traffic_button : $('#traffic_button')
};

function do_something()
{
 // Now you can reference the stored results and manipulate them
 var script = document.createElement('script');
 $my.head.append(script);

// When working inside functions, continue to save jQuery results
 // to your global container.
 $my.cool_results = $('#some_ul li');
 $my.other_results = $('#some_table td');

// Use the global functions as you would a normal jQuery result
 $my.other_results.css('border-color', 'red');
 $my.traffic_light.css('border-color', 'green');
}

4. Harness the Power of Chaining

The previous example can also be accomplished like this:

var $active_light = $('#traffic_light input.on');$active_light.bind('click', function(){...})
 .css('border', '3px dashed yellow')
 .css('background-color', 'orange')
 .fadeIn('slow');

This allows us to write less code, making our JavaScript more lightweight.

5. Use Sub-queries

jQuery allows us to run additional selector operations on a wrapped set. This reduces performance overhead on subsequent selections since we already grabbed and stored the parent object in a local variable.

<div id="content">
 <form method="post" action="/">
 <h2>Traffic Light</h2>
 <ul id="traffic_light">
 <li><input type="radio" class="on" name="light" value="red" /> Red</li>
 <li><input type="radio" class="off" name="light" value="yellow" /> Yellow</li>
 <li><input type="radio" class="off" name="light" value="green" /> Green</li>
 </ul>
 <input class="button" id="traffic_button" type="submit" value="Go" />
 </form>
</div>

For example, we can leverage sub-queries to grab the active and inactive lights and cache them for later manipulation.

var $traffic_light = $('#traffic_light'),
 $active_light = $traffic_light.find('input.on'),
 $inactive_lights = $traffic_light.find('input.off');

Tip: You can declare multiple local variables by separating them with commas – save those bytes!

6. Limit Direct DOM Manipulation

The basic idea here is to create exactly what you need in memory, and then update the DOM. This is not a jQuery best practice, but a must for efficient JavaScript. Direct DOM manipulation is slow. For example, if you need to dynamically create a list of elements, do not do this:

var top_100_list = [...], // assume this has 100 unique strings
 $mylist = $('#mylist'); // jQuery selects our <ul> element

for (var i=0, l=top_100_list.length; i<l; i++)
{
 $mylist.append('<li>' + top_100_list[i] + '</li>');
}

Instead, we want to create the entire set of elements in a string before inserting into the DOM:

var top_100_list = [...], // assume this has 100 unique strings
 $mylist = $('#mylist'), // jQuery selects our <ul> element
 top_100_li = ""; // This will store our list items

for (var i=0, l=top_100_list.length; i<l; i++)
{
 top_100_li += '<li>' + top_100_list[i] + '</li>';
}
$mylist.html(top_100_li);

Even faster, we should always wrap many elements in a single parent node before insertion:

var top_100_list = [...], // assume this has 100 unique strings
 $mylist = $('#mylist'), // jQuery selects our <ul> element
 top_100_ul = '<ul id="#mylist">'; // This will store our entire unordered list

for (var i=0, l=top_100_list.length; i<l; i++)
{
 top_100_ul += '<li>' + top_100_list[i] + '</li>';
}
top_100_ul += '</ul>'; // Close our unordered list

$mylist.replaceWith(top_100_ul);

If you do the above and are still concerned about performance:

Give jQuery’s clone() method a try. This creates a copy of the node tree, which you can manipulate “off-line” and then insert back in when you are ready.
Use DOM DocumentFragments. As the creator of jQuery points out, they perform much better than direct DOM manipulation. The idea would be to create what you need (similar to what we did above with a string), and use the jQuery insert or replace methods.

7. Leverage Event Delegation (a.k.a. Bubbling)

Unless told otherwise, every event (e.g. click, mouseover, etc.) in JavaScript “bubbles” up the DOM tree to parent elements. This is incredibly useful when we want many elements (nodes) to call the same function. Instead of binding an event listener function to many nodes—very inefficient—you can bind it once to their parent, and have it figure out which node triggered the event. For example, say we are developing a large form with many inputs, and want to toggle a class name when selected. A binding like this is inefficient:

$('#myList li).bind('click', function(){
 $(this).addClass('clicked');
 // do stuff
});
Instead, we should listen for the click event at the parent level:

$('#myList).bind('click', function(e){
 var target = e.target, // e.target grabs the node that triggered the event.
 $target = $(target); // wraps the node in a jQuery object
 if (target.nodeName === 'LI') {
 $target.addClass('clicked');
 // do stuff
 }
});

The parent node acts as a dispatcher and can then do work based on what target element triggered the event. If you find yourself binding one event listener to many elements, you are doing something wrong (and slow).

8. Eliminate Query Waste

Although jQuery fails nicely if it does not find any matching elements, it still takes time to look for them. If you have one global JavaScript for your entire site, it may be tempting to throw every one of your jQuery functions into $(document).ready(function(){ // all my glorious code }). Don’t you dare. Only run functions that are applicable to the page. The most efficient way to do this is to use inline initialization functions so your template has full control over when and where JavaScript executes. For example, in your “article” page template, you would include the following code before the body close:

<script type=”text/javascript>
mylib.article.init();
</script>
</body>
If your page template includes any variety of modules that may or may not be on the page, or for visual reasons you need them to initialize sooner, you could place the initialization function immediately after the module.

<ul id="traffic_light">
 <li><input type="radio" class="on" name="light" value="red" /> Red</li>
 <li><input type="radio" class="off" name="light" value="yellow" /> Yellow</li>
 <li><input type="radio" class="off" name="light" value="green" /> Green</li>
</ul>
<script type="text/javascript>
mylib.traffic_light.init();
</script>
Your Global JS library would look something like this:

var mylib =
{
 article_page :
 {
 init : function()
 {
 // Article page specific jQuery functions.
 }
 },
 traffic_light :
 {
 init : function()
 {
 // Traffic light specific jQuery functions.
 }
 }
}

9. Defer to $(window).load

There is a temptation among jQuery developers to hook everything into the $(document).ready pseudo event. After all, it is used in most examples you will find. Although $(document).ready is incredibly useful, it occurs during page render while objects are still downloading. If you notice your page stalling while loading, all those $(document).ready functions could be the reason why. You can reduce CPU utilization during the page load by binding your jQuery functions to the $(window).load event, which occurs after all objects called by the HTML (including <iframe> content) have downloaded.

$(window).load(function(){
 // jQuery functions to initialize after the page has loaded.
});

Superfluous functionality such as drag and drop, binding visual effects and animations, pre-fetching hidden images, etc., are all good candidates for this technique.

10. Compress Your JS

Okay, this isn’t jQuery related, but I had to include it. There is a tendency to make JavaScript functions and variables overly descriptive, which is essential for developers but irrelevant to users. No more excuses, it’s time to build JS compression into our workflows. Comment the heck out of your code, and run it through a compression tool before launching to production. Use YUICompressor to squeeze out wasteful bytes from your code. In our experience, it safely compresses JavaScript as small as it can possibly get without a CPU penalty (such as Base62 encoding with Packer). Tip: For maximum compression in YUICompressor, always declare your variables (e.g. var my_long_variable_name;).

11. Learn the Library

Print out this jQuery 1.3 cheat sheet, and make it a goal to eventually understand what each function does. If you find yourself repeating yourself repeating, there is probably an easier (and more efficient) way. jquery cheat sheet

In this article

Join the Conversation

6 comments

  1. steve Reply

    If you want to go EVEN faster in #6, you should do a reverse while loop, i.e., while(i–>0) where i is set to the length of the array.

    For #9, do you feel any better about this approach for DOMContentLoaded in IE? I’ve used this approach quite a lot without even the slightest touch of guilt.

    /*@cc_on @*/
    /*@if (@_win32)
    document.write(“”);
    var script = document.getElementById(“__ie_onload”);
    script.onreadystatechange = function() {
    if (this.readyState == “complete”) {
    init(); // call the onload handler
    }
    };
    /*@end @*/

  2. Porter Reply

    Class selector performance has improved in 1.3.x with Sizzle, but #1 and #2 are still good general tips when you have a choice.

    In #4 I’m assuming you’re indicating that you intend to reuse $active_light elsewhere in the code, otherwise you can just collapse that all down into a single chained statement. However, I don’t believe you want the semi-colons on the ends of lines 2 and 3 in your code sample. Also, you can combine the two .css() calls into a single one using a property structure instead of name/value pairs:

    var $active_light = $(‘#traffic_light input.on’);
    $active_light.click(function(){…}).css({‘border’: ’3px dashed yellow’, ‘background-color’: ‘orange’}).fadeIn(‘slow’);

    In #7, how wasteful of you to define the toggle function twice in both examples. 😉

    As for #9: That’s only going to make people want to use it more. “You mean I can melt the processor of visitors who are using IE6? Sign me up!”

  3. Jeremy Reply

    Note: Using innerHTML instead of html() can save you a lot. I love jQuery, but I was surprised and disappointed to find out just how much of an increase in performance I got out of simply using $(“#mydiv”)[0].innerHTML=”[contents]“; vs $(“#mydiv”).html(“[contents]“). Also, beware, I think there is a memory leak or some other bug in the latest version of 1.3.2 for using .html(“”) to clear a body. I found that each time i ran the same util which gathered data and repopulated into a table, using html(“”) to clear the tbody was gradually degrading performance of the rest of the function. Replacing with innerHTML=”” showed no degradation. It is hard to believe, I know, but I have tested it many times. This testing was done in FF 3.0.1.0.

  4. Dan Reply

    thanks for the article. these all make really good sense from a performance standpoint. one question I have is in regards to event delegation, specifically a common function like highlighting the row of a table you are currently mousing over. Almost all the scripts I have seen are selecting each row on Domready and attaching the hover() event. What would it look like if instead you used the main table as the delegator. e.g.: before is:
    $(document).ready(function(){
    var $dataTable = $(“table.datatable”);
    $(‘tr’,$dataTable).each( function() {
    var row = $(this);
    row.hover(
    function() {
    row.addClass(‘over’);
    },
    function() {
    row.removeClass(‘over’);
    }
    )
    });

  5. Dan Wellman Reply

    I’m not sure number 8 will give that much of a performance boost.

    I did some experimenting using a page with 10 random jQuery methods on it (mostly animations and simple add/remove functions), then another page with 5 of these on it, and another page with the other 5 on it.

    In the page with all 10 functions I then tested using $(function() {}) as a benchmark, as well as the method you describe in section 8, as well as a similar method to section 8 but adding the functions to the jQuery namespace with .extend() instead of a custom namespace.

    I then repeated exactly the same code on the other pages (with 5 each of the 10 overall functions), so that on the other pages there were at least 5 functions that were redundant.

    I was unable to find any difference between all three methods.

    Being slightly surprised by this, I had a discussion with a member of the jQuery UI dev team and explained what I was doing and asked their opinion.

    Their response was that Sizzle/jQuery is super, ultra, uber optimised and wastes almost nothing when looking for selectors that don’t exist.

    Namespacing is good for super-separation and protection of your code (preventing funcs from being overwritten, not protecting them from view of course), but probably won’t give you and performance increase

  6. Cory McHugh Reply

    Great article and I appreciate the tips. I love pages like this! When someone takes the time to clearly delineate concepts like this, and then takes the extra step of providing testable examples, it really buoys the whole community of developers! So two thumbs wayyyy up! Educating and providing valuable discussion is priceless.

    One suggestion that I would like to see, is if you left the “Do This because it is good” examples in green like they currently are, but then your examples of “Don’t do this because it is bad” type examples, you could set the background color to those code blocks to be pink or red. http://www.javascripttoolbox.com/bestpractices/ has a page similar to this for general javascript (not jquery specific), and it is a great way to contrast good ideas vs. bad ideas. Or, for accessibility for color blind users, maybe you could have one with a border of dashes, and then the other with a border of dots or something.

    Another thing that I am looking forward to is a web service that allows you to speed test javascript code in a variety of js engines (chrome vs firefox vs internet explorer for example). I think Adobe is working on something like this, and hopefully some other smart people are as well. These tips probably apply generally well for most engines, but it might be interesting to see how much of a difference it makes in the various flavors. I love to optimize, but sometimes I also find it useful to brute-force ham-fist duct-tape code if the performance change is very slight, and it is far easier to do it in a less-optimized manner. (for small prototypes and pages that are probably going to go away, for example.)