5 Performance Tuning Tricks for jQuery

In a recent post, I wrote that developers should better optimize their JavaScript. Well, that’s easier said than done, so I’d like to get down to the nitty-gritty and talk specifically about optimizing jQuery. Please note that this is not about performance tuning of the jQuery library, rather it is about better engineering the code we use to interact with it. If you’re not a jQuery programmer, and you have no interest in joining the fad, don’t worry—most of the concepts here apply to JavaScript and general programming as well.

1. Beware of class-only selectors

A great part about using a JavaScript library like jQuery is its selectors. But before you use them all over the place, stop to think: what are the processing costs?

Basically, jQuery defines all the elements on a page as a huge JavaScript object, and then interacts with it. You don’t have to look into the source code to realize that the selector function works by iterating all objects that fit a certain criteria. Therefore, it makes sense to give the selection function a helping hand by defining the selection criteria more specifically.

Let’s do a quick case-study:

Pretend you’re doing site navigation and want to select an LI that has the CSS class ‘active.’ One way to select this element is:

$('.active')

This selector works just fine, but think about what the jQuery DOM traversal has to do here: iterating through hundreds of elements on the page, selecting any with the class ‘active.’ That’s a lot of processing for our little nav bar.

It turns out, according to selector speed tests, that a CSS class alone is just about the worst way to select an object, since jQuery must go through literally every element on the page. Instead, narrow it down a bit using the element that the class is attached to:

$('LI.active')

With only a couple LI’s on the page, this selector performs much better—in half the time on my FF3 and Safari.

2. Select top level by id

That last object selection could be further optimized by using an id in addition to the element and class. As explained in this jQuery performance tip, jQuery’s DOM traversal processes id selection fastest, followed by element and class selection. So it is better to select the list element using:

$('#menu LI.active')

Interestingly, here it is less efficient to use $(‘UL#menu LI.active’), since adding the UL element at the head of the selector causes jQuery to use the worse selection method. Stick with $(‘#menu LI.active’) and remember that the top level node is the most important to select efficiently.

3. Define objects when using selectors

We’ve already established that the selector function is pretty resource heavy, so let’s think of some ways to avoid using it if possible. Mainly, let’s never select the same thing more than once through the jQuery DOM traversal. In our example, we can define an object:

$active = $('#menu LI.active');

Now we are free to use this element as much as we want without worrying about traversal processing.

4. Avoid doing anything you don’t have to¹

It may seem like common sense, but it is important to avoid executing extraneous functions.

Suppose that in parts of a site we want to collapse side navigation elements on page load:

$(document).ready(function() {
    $('#sideNav LI:not(#current)').hide();
});

Even though some pages don’t have the side nav, this won’t throw an error in any browser, but let’s still make sure that the hide function only executes when it’s needed:

$(document).ready(function() {
    var sideNavPages = ['catalog', 'order', 'contact'];
    
    if ( jQuery.inArray(thisPage, sideNavPages) != -1 ) {
        $('#sideNav LI:not(#current)').hide();
    }
});

I think there is a real tendency with jQuery to execute way more code than is neccessary for a page, since jQuery won’t error the way JavaScript will if you are trying to select an object that does not exist. But we have to be responsible as developers: even if the client can’t see a blatant error warning, you’ll still know you wrote horrible code.

5. Learn the library completely

Some developers who got into jQuery early are missing out on a lot of the functions released with later versions. Sure they use the latest version when they build a new site, but they interface with it in an old way. After reading an old tutorial, I was using:

a.hasClass('b') ? a.removeClass('b') : a.addClass('b');

instead of:

a.toggleClass('b');

Presumably the developers engineering the jQuery library spent more time on optimization than you have on any individual front-end. So read the docs and use the native jQuery functions since they’ll run faster than any self-written function. At the very least, they’ll contribute to the conciseness and readability of the code.

¹This rule applies to jQuery, JavaScript, computer programming, and life in general

• Retweet
• Share

---

---

Tags: javascript, jQuery, object oriented, performance, webdev

This entry was posted on Thursday, July 10th, 2008 at 10:20 am in the category webdev.

---

You Might Also Like:

• 10 Javascript Performance Boosting Tips from Nicholas Zakas
• 10 Advanced jQuery Performance Tuning Tips from Paul Irish
• QuickFlip 2: The jQuery Flipping Plugin Made Faster and Simpler
• Scrolling Parallax: A jQuery Plugin
• Flipbook Movies with jQuery
• Too much Javascript? Here comes WebKit and the new Safari
• TranslateThis – A Javascript Translation Widget for Noobs and Nerds Alike

---