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.
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.
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.
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:
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.
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.
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.
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).
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);
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.