Thursday, April 29th, 2010

jQuery Micro Optimizations

Category: jQuery

<>p>Corey Hart has a fun post on jQuery micro optimization tips by walking through the jQuery codebase to see what is running.

Right away he notes that these are true micro optimizations, and to “use with caution and balance elegance with performance correctly.” Chances are you are a lucky chap if these are the biggest issues for performance on your application!

The post is still interesting as it shows a lot of jQuery core itself. I would think that Mr. “inline it” Dalton would approve of some of these tips :)

  1. jQuery.root: Internally, all selectors that don’t provide a context use jQuery( document ).find( selector ). Save yourself some ms, store the document root onto jQuery itself, and then run all global selectors off of that element.
  2. Context sucks, use find: Don’t get me wrong, you should always run selections based on a context if possible. But passing in a context to the jQuery constructor creates an extra unneeded function call. Internally jQuery runs context.find( selector ) anyway, so skip that step
  3. Live is terrible, delegate is awesome: The best part: delegate is live with a context. So why is live a bad idea? To use live, you first have to run a selection on the page, and then bind the live handler.
  4. jQuery.data > jQuery.fn.data: avoid jQuery(this)
  5. Bind and Trigger, get used to it: don’t use the short cut methods, save a function call
  6. Each is evil: there is only one true reason to use each, and that is when a closure is needed for each item. If you are just looping through an array, then the callback function gets triggered on every iteration. So using an array of 25 items, the callback gets triggered 25 times.
  7. Classes over styles: I would go so far as to say that using a class for a single style change is better than running through jQuery’s style module.
  8. Object.length, use it: Every jQuery selection comes with a length property that defines how many elements were found. Always check to make sure that there is a set of elements in your object before running a chain of methods.

Related Content:

Posted by Dion Almaer at 6:05 am
10 Comments

+++--
3.5 rating from 6 votes

10 Comments »

Comments feed TrackBack URI

Interesting that the author touches on doing away with the abstraction jQuery provides to get faster “raw” code, but fails to make some very basic optimisations in the super-fast “raw” version — no caching of length property — no caching of style property to minimize object lookup… Plus, and this is minor, pre-increment operator is faster than post-increment… and again, minor, you can combine the conditional with the incrementer expression… and you can achieve even higher speeds by going in reverse… But this is all rather irrelevant. Replacing all your .each() calls with verbose for/while loops is probably not going to make any difference. Time would be better spent learning about dom-reflow and the waterfall/HTTP topics.

I’d like to contribute a couple more ideas to his post (and it is a very good post) but again, another interesting topic covered on a website which seemingly has NO way to comment :(

… and that’s why I’m commenting here on Ajaxian.

Comment by JimmyP22 — April 29, 2010

I volunteer to be the dick who suggests optimising the blog by removing all those grocer’s apostrophe’s.

Comment by NickTulett — April 29, 2010

Sorry – bad day – that’s actually very interesting.

Comment by NickTulett — April 29, 2010

caching a length property (of an array) is not needed. if it is a function that it is good to cache it.

Comment by Aimos — April 29, 2010

I don’t understand #1 and #4, they’re a bit too succinct, and disagree with #6. Each is just better than For, I doubt anyone would ever notice the performance difference unless they were running global weather simulations. :) The others are pretty standard, except for “Delegate” — it’s a new addition to jQuery, and I should probably start learning it!

Comment by Baryn — April 29, 2010

There’s some good tips here as well:

http://www.artzstudio.com/2009/04/jquery-performance-rules/
http://blog.dynatrace.com/2009/11/09/101-on-jquery-selector-performance/

Comment by cancelbubble — April 29, 2010

Some interesting ideas, but for practical purposes, these tips also increase program volume and complexity, so their impact needs to be benchmarked on various popular browsers in order to decide if it’s really worth the extra baggage.

Comment by Michael Mahemoff — April 30, 2010

I dig how Corey looks under jQ’s hood. I am a big fan of reducing complexity and abstraction in framework cores so things built on top of them aren’t burdened with it. I agree that in normal situations (not designing the internals of a framework) some of these tips are better left to the dev’s discretion.

Comment by jdalton — May 1, 2010

Live isn’t bad because it does a query one time. It’s Bad because live delegates on the document element. This makes every event handler much slower to respond. You want to use delegate as low as possible in your document.

Comment by JustinMeyer — May 1, 2010

Justin: doesn’t using delegates as low as possible take away a lot of the benefit of using delegates? You say event handlers are “much slower to respond”, but what do you mean by much (have you done any profiling and compared it to assigning event handlers lower in the document)? I haven’t heard anybody else claim that so now I’m curious! :-)
In my experience using delegates on the document.body is very quick even when applied to horrible coded ASP.NET apps.

Comment by Jofan — May 4, 2010

Leave a comment

You must be logged in to post a comment.