Demystifying jQuery .live() and why it’s generally faster than .bind()

by Cedric Dugas on December 1, 2009

Live() is kind of an odd method. Most people use it for binding an event to a selector injected in the DOM in a loaded page. It does its magic but how?

Event delegation and bubbling

The concept behind .live() is pretty ingenious. Basically there is a feature in javascript called event bubbling, when you click on a html tag the event is triggered to all its ancestors including the page document itself. What .live() does is bind 1 event to the document, from there when you click on your html tag it uses the event bubbling and determines if what you clicked on corresponds to your live selector and executes your binded function accordingly.

However it has one big drawback, if you are using event bubbling on 2 selectors, one ancestor of the other, the 2 events will be triggered. jQuery will look at all the ancestor and determine that 2 events need to be triggered. You could theoretically stop the propagation using a return false on the ancestor, however this would stop the event bubbling all together.

Speed gain is enormous on page load when binding a lot of selectors

Imagine you have this web application with 40 edit buttons on the same page, it will be a lot faster using .live() than using the .bind() method. Especially on load page. Remember that live only binds one event to the document and keep a pretty much consistent speed at the page load, where your .bind() event needs to parse your document to bind everything. This gain can be seen across all browsers, the more you have selectors more the gain is important.

With 40 selectors on the page load .live() is more or less 500% faster than .bind(). What is even more surprising, is that live() is also often faster when you actually execute the click function itself. It is however impossible to test this in IE because it happens generally in 1 ms. Overall .live() is faster when more than 5 selectors are binded. Below there is some tests that you can look for yourselves, one is using Firebug profiling, a lot more precise. Another with javascript date for testing across all browsers.

Tests are unanimous

Firefox Profiling (using firebug)
1000+ items                          9 items

View demo View demo

Across all browsers (using alerts and date stamps)
1000+ items                          9 items

View demo View demo

The next time you are binding events with jQuery ask yourself if .live() would not be better!

More links to satisfy your curiosity:
Jquery .live() documentation
More on Event Delegation
Got my curiosity picked up on .live() listening to yayQuery podcast

Ads

Become a successful developer using testking 646-985 web development course. Download the testking 70-630 demos and testking 352-001 study guide to learn latest tools and trends in web development.



9 comments

You said “It is however impossible to test this in IE because it happens generally in 1 ms”, you can test it with Google Chrome Frame wich adds the Chrome functionalities to Internet Explorer or any browser.

by Hugo on December 3, 2009 at 8:15 am. Reply #

Well using google frame would not give an actual representation of load time on IE, they rarely use Google frame.

by Cedric Dugas on December 3, 2009 at 8:58 am. Reply #

[...] Demystifying jQuery .live() and why it’s generally faster than .bind() « Position Absolute, resou… (tags: jquery tips) [...]

by links for 2009-12-07 « toonz on December 7, 2009 at 6:07 pm. Reply #

[...] Demystifying jQuery .live() and why it’s generally faster than .bind() [...]

by What I Read This Week (jQuery’s live(), algorithms, IE8 + VPN, Chrome ) » HTML + CSS + JavaScript » Blog Archive on December 9, 2009 at 10:02 am. Reply #

i have 5 edit menu base on my query when on click edit 1 it consist on of 6 user info, inside my user info i have a plugin called date picker. even if use .live() function it time 10s to appear my date picker.. can u give any suggestion what would i do? tnx

$(“#datepicker”).live(“click”, function(){
$(this).datepicker({ changeMonth: true, changeYear: true });
});

by nanat on March 4, 2010 at 8:37 pm. Reply #

i test it in google crome it runs fast.. while i can in firefox the speed is so slow..

by nanat on March 4, 2010 at 8:52 pm. Reply #

hi, can i use jQuery with telerik RadAjaxPanel

by Binoy on May 15, 2010 at 4:35 am. Reply #

Hi,

To solve the speed problem simply use the focus even instead of the click event.

$(“#datepicker”).live(“focus”, function(){
$(this).datepicker({ changeMonth: true, changeYear: true });
});

by Compiler on May 20, 2011 at 1:01 am. Reply #

[...] was thinking there was probably some performance caveat or something, but then I read this post on the relative speed of live() and now I’m thinking maybe it’s something worth exploring [...]

by totes profesh» Blog Archive » CSS, live(), and application state on December 7, 2013 at 9:33 pm. Reply #

Leave your comment

Required.

Required. Not published.

If you have one.