JQuery Performance Tips Cheat Sheet | Hacker News Reader

JQuery Performance Tips Cheat Sheet

dumitruglavan.com

108 pointsdoomhz22 comments

Man... this is full of crazy talk:

For better performance you can use direct functions like $.ajax() than $.get(), $.getJSON(), $.post() because the last ones are shortcuts that call the $.ajax() function.

I've never written an app where the overhead of $.getJSON has been any kind of bottleneck.

Don’t forget about using .data() function to store stuff for your elements

How is this a performance tip?

Sometimes it’s faster to use $(window).load() than $(document).ready() because the last one occurs before all the DOM elements are downloaded

Say what?

If you want to save some bits on compressing your js plugin – replace the $(document).onready() event

Saving bits! The favorite optimization bikeshed of the JavaScript glitterati.

The best way to test a Javascript code is the human way :D But, you still can use some automated tools like Selenium, Funcunit, QUnit and QMock to test your code

I hope this is a joke.

The new HTML 5 standard comes with a lighter DOM structure in mind

What?

When styling a few elements it is best to simply use jQuery’s css() method, however when styling 15 or more elements it is more efficient to append a style tag to the DOM.

Or, if you're worried about performance and reusability, you could use classes and use addClass and removeClass.

You forgot my personnal favorite :

"Lazy load content for speed and SEO benefits"

This guy either works at Google or doesn't have a clue of what he's saying. SEO is already black magic. That kind of claim requires heavy evidence which are simply not there.

Hardly black magic. But there has been a lot of theories tossed around about page load speed influencing rankings. So it's understandable why he things that -- and google's addition of page speed to analytics hasn't helped stop the myth. Unfortunately, there's not a lot of solid evidence about it (yet).

I'm glad I'm not the only one. Basically, this article should be retitled, "jQuery Good Practices", and only then after most points are either removed or revised. Is it worth an itemized address? It's nice to have a list of good things to do, but only when they're actually good... and can be explained as to WHY they're good. Having "cheat sheets" attached to it also lends credence where there should be none.

Some of these exemplify "premature optimization" and will clutter code with no discernible benefit. I remember some days ago, in the days of PHP, there were heated debates about whether or not using single or double quotes for strings makes code faster.

As with most development, use good practices. But then at the end of the day, profile your application to find the actual bottlenecks.

yeah, lots of misinformation in the article :(

This is nice:

15. Add a JS class to your HTML attribute Firstly, as soon as jQuery has loaded you use it to add a “JS” class to your HTML tag.

1 $('HTML').addClass('JS'); Because that only happens when javascript is enabled, you can use it to add CSS styles which only work if the user has JavaScript switched on, like this…

1 /* In your css */ 2 .JS #myDiv{display:none;} So, what this means is that we can hide content when JavaScript is switched on and then use jQuery to show it when necessary (e.g. by collapsing some panels and expanding them when the user clicks on them), while those with JavaScript off (and search engine spiders) see all of the content, as it’s not hidden. I’ll be using this one a lot in the future.

http://www.learningjquery.com/2008/10/1-way-to-avoid-the-fla...

It is good advice, but not optimal. If you want to go for ultra-fast page loads then you're putting the jQuery JS file at the bottom of your page. If you do that, the user will see an ugly flicker when content appears and disappears.

The solution is to just not use jQuery for that. It's such a simple operation anyway. I do something like:

    <body>
    <script type="text/javascript">
        document.body.setAttribute("class","hasJs");
    </script>

No flicker or jQuery load delay.

    <script>document.getElementsByTagName('html')[0].className += ' js'</script>

here, in <head>. Can co-exist with conditional IE classes a là HTML5 Boilerplate.

The bits about queries by ID being faster haven't been true for the past couple years. getElementsByClassName and most uses of querySelectorAll are just as fast. Very few DOM queries end up using Sizzle at all.

    5. Use find() rather than context

This is not really true. The "context" argument uses find under the covers anyway; the performance benefit is literally the overhead of a function calling another function (which is, compared to DOM operations, miniscule).

The jQuery source code comments say as much:

    // HANDLE: $(expr, context)
    // (which is just equivalent to: $(context).find(expr)

Generally very good advice. One thing I notice a lot is people using .live() instead of just relying on event delegation. Using .live() can be terribly inefficient as it binds to the root node, use .delegate() or .on() (in jQuery 1.7) instead.

I understand in principle this is true, but in reality what kind of performance hit are you looking at?

I've never seen any real stats.

Plus .live() is now deprecated as of 1.7.

The #id selector performance tip is definitely true, but in single-page interface you never know which DOM elements may be floating around on a page, which would go against the one id per page principle.

You can't have two elements with the same id. Well, you can, but it's not valid.

It would be nice to see measurements on how much less time and memory the more performant techniques take compared to their less performant counterparts in realistic scenarios. Doing so might indicate a better ranking of the tips given. For example, the DOM insertion tip -- which drastically improves performance over the naive implementation -- is tip 9, and is probably far more useful than tips 4 (Optimize selectors for Sizzle’s ‘right to left’ model) and 5 (Use find() rather than context).

You could always set up some tests using jsperf.com. I don't believe it does memory usage though.

Seems like people are testing the sort of things measured in this article at the moment too eg.:

http://jsperf.com/jquery-multiple-id-perf

As for the recommendation to use his custom testing/benchmarking library: don't! It's based off an old version of jQuery, it duplicates functionality of better-maintained libraries, and it opens up a new vector for arbitrary code evaluation/execution ($.bm);

I would discount any performance/benchmarking discussions unless it uses jsperf, benchmarkjs or a similar suite.

The article proposes to use inline style tags for 15 or more properties to be changed. I always thought online style tags are like demons?

is it just me or are half of these 'tips' about caching the selector results?

Reply on news.ycombinator.com