Things That Matter Most

Things That Matter Most

Selector Caching in jQuery

by

One of the first critiques I find myself writing while I review JavaScript code is “cache your selectors.”

Like me, many JavaScript developers are self taught and worked their way through a basic understanding of scripting through tutorials. Unfortunately, many tutorials sacrifice cleanliness for brevity, leading to functional snippets of code that look absolutely horrible in larger collections of code.

The worst offender is the way developers handle jQuery selectors.  Most commonly, I see things like $( this ) repeated several times within a callback function. Or $( '#selector' ) used throughout a script to both bind and unbind multiple events.

What new developers don’t realize is that every call to $( something } asks jQuery to rescan for the matching element, wrap it in a jQuery object, and create a new instance of something you already have in memory. If your code crashes due to memory cascades, overuse of redundant selectors might be related.

Actually, if you use a more advanced IDE like PhpStorm or WebStorm, the IDE itself will alert you to this issue so you can correct it.

Caching Selectors

In a small application, caching selectors isn’t that difficult. Just declare all of your objects at the top of your closure and use the new variables throughout your script.

var $window = $( window ),
    $document = $( document ),
    $footer = $( '#footer' ),
    $sidebar = $( '#sidebar' ),
    $images = $( 'img' );

Unfortunately, as the length of your application grows, the size of this selector cache grows and becomes difficult to manage. I’ve been experimenting with different forms of in-memory caching for JavaScript applications, and came up with a simple selector cache object that makes it easier to wrangle your references.

function Selector_Cache() {
    var collection = {};

    function get_from_cache( selector ) {
        if ( undefined === collection[ selector ] ) {
            collection[ selector ] = $( selector );
        }

        return collection[ selector ];
    }

    return { get: get_from_cache };
}

var selectors = new Selector_Cache();

// Usage $( '#element' ) becomes
selectors.get( '#element' );

Using selectors.get( something ) in your code from that point forward might be slightly more characters than the redundant selectors we’ve used previously, but it’s far more performant. Once you run code through a minifier, the character count difference will be negligible anyway.

Like what you’re reading?

Consider pitching in to help cover the costs of maintaining this site and keeping my work 100% ad-free.

Comments

  2. Andy Adams says

    Wow, I (almost) always cache my selectors using variables, but a Selector_Cache is a flippin’ awesome idea! Thank you, thank you for opening my mind.

  3. J.D. Grimes says

    This is a great idea. So great, in fact, that it makes me wonder why something like this isn’t a part of jQuery already. I originally assumed that jQuery probably did use some kind of selector caching.

    • Andy Adams says

      The only reason I can think of (and Eric can correct me if I’m wrong) is that jQuery can’t assume that a selector’s results won’t change. For example:

      $images = $( ‘img’ );

      If there was code for dynamically adding images to the page, the selection results would need to be refreshed after those images were added, so you can’t assume that the first ‘grab’ is always going to be complete.

      If you’re doing your JS in a $(document).ready callback, you typically will know that your selectors are going to stay the same, which is why you can cache them.

  4. Nombre23 says

    other posible solution:

    (function($){	
	$.selector_cache = function (selector) {
		if (!$.selector_cache[selector]) {
			$.selector_cache[selector] = $(selector);
		}
		
		return $.selector_cache[selector];
	};
})(jQuery);

// Usage
$.selector_cache('#elements');

    • Eric says

      That would work as well, and merely stores the cache as an attribute of the global jQuery object rather than as an object merely in the global namespace. Both are acceptable, and are doing the exact same thing.

    • Eric says

      Because it’s not always a good idea. You can pass different parameters into jQuery – selectors, DOM objects, arrays, arbitrary HTML. jQuery is meant to do a very specific task, we just happen to use it in such a way that a selector cache makes sense in different situations.

  6. Madhavan Kumar says

    when there is a change in the DOM tree, doesn’t the jquery selector tree still holding stale entries? does the cache needs to be flushed for each & every dom manipulation? it is a great tuts, i must say

    • Eric says

      If you’re making DOM updates that will affect a cached object, then you’ll need to re-cache that object as necessary.

    • Eric says

      Not sure what different approaches you’re referencing. But I can tell you the difference in making a call to a cached selector versus an uncached selector is huge. jQuery does a lot of behind the scenes logic just to figure out what kind of selector you’re querying; by caching your selectors, you skip all of that logic.

      Caching selectors is actually more performant even than converting jQuery( '#selector' ) to jQuery( document.getElementById( 'selector' ) ). There’s more information on that selector performance and the rationale behind the change here: https://davidmichaelross.com/blog/call-jquerydocument-getelementbyidselector/

  8. Conor says

    This is so great because it’s incredibly easy to plug into an existing project. Simple find-and-replace operations on selected areas from ‘$’ to ‘selectors.get’ had me running this solution in my project in under five minutes. The performance boost in my case was drastic. Thanks for the great article!

  9. Ricardo Ferreira says

    Hi guys, excelente idea, but is ti possible to use Selector_Cache with dynamic content? or just with static content?
    Let’s suppose I have a dynamic combobox, does the Selector_Cache() keep track of the changes in the combobox or any other dynamic content?

    Regards,

  13. Caelan Stewart says

    Your comment is awaiting moderation.

    I wrote a script basically identical to this a while back, it’s all well and good, but the code is still just as messy as it was before. Selectors are not always so descriptive of what they are selecting, so using the selector as the key may cause maintainability difficulties later on, I’ve experienced it myself (except that $ was being called every time), and trying to identify what pieces of code like this scattered around are doing is awkward:

    $(‘#anc-82 a[data-prop=”val”]:parent’).toggleClass(‘active’);

    So, to avoid all of this, and increase the readability of your code by a long way, I still do what you originally did. Here is an example of how I typically stricture a new static JS class I write:

    var SomeModule = (function() {
        'use strict';
       
        var elements;
       
        function onHeaderLinkClick(event) {
            event.preventDefault();
           
            console.log('Header link was clicked!');
           
            return false;
        }
       
        function setListeners() {
            var iter = 0,
                headerLinksLen = elements.headerLinksLen;
           
            for(iter = 0; iter < headerLinksLen; ++iter) {
                elements.headerLinks[iter].removeEventListener('click', onHeaderLinkClick);
                elements.headerLinks[iter].addEventListener('click', onHeaderLinkClick);
            }
        }
       
        function cacheElements() {
            elements = { };
           
            elements.header = document.getElementById('wrapper');
            elements.headerLinks = elements.header.querySelectorAll('ul li a');
        }
       
        function someExposedMethod() {
            // Do something that changes DOM structure
           
            cacheElements();
            setListeners();
        }
       
        cacheElements();
        setListeners();
       
        return {
            someExposedMethod: someExposedMethod
        };
    })();

  15. StanGeorge says

    I’ve improved the function a bit in order to be able to clear the cache once an Ajax call is made on page.

    var Html_cache = (function () {
        var collection = {};

        /**
         * @constructor for Html_Cache
         * */
        function _Html_cache() { };

        _Html_cache.prototype.get = function (selector) {
            if (collection[selector] === undefined) {
                collection[selector] = $(selector);
            }
            return collection[selector];
        };

        /**
         * @method cleares cache
         */
        _Html_cache.prototype.clear = function () {
            collection = [];
        };

        return _Html_cache;
    }());

    var memo = new Html_cache();

    var muse = {};

    Here you will use something like :memo.get(selector).

    In case of ajax call or dom manipulation all you need to do is use:
    memo.clear().

    I hope it helps.

  16. Michael Crenshaw says

    Is there a potential memory cost to storing in the collection variable vs. just storing the jQuery object in its own variable? I would think that the latter would be garbage-collected when no references to the variable remain, whereas the former would stick around. Am I too pessimistic about the intelligence of JS engines?

    • Eric says

      It depends on your use case. If you’ve only got a handful of selectors, by all means, store them individually and they’ll be garbage collected when necessary. Note that this article is a little over 3 years old – i.e. before React, Vue, and the like had taken over how we build front-ends. In many use cases at the time, the number of selectors you had to cache grew to be unwieldy, so a collection variable in memory was more useful.

      Not more efficient in terms of memory management, but more efficient in terms of development time and knowing what needed to go where.