.on() simply grabs the event when it happens at the higher level that you specify (usually document or a container div), checks if the element that caused the event matches any of the selectors for any added .on() calls, and if so calls your handler.
This functionality is also provided by .live(), but as of jquery 1.7, this function is deprecated. Use .on() instead.
tl;dr
Use .on()! Using .on() to capture the event over attaching a handler directly to each element has virtually no performance impact when the event is triggered, even when there are a huge number of unique elements with their own .on() handler on the page. However, using .on() does have a very noticeable performance advantage when generating/rendering elements. So any performance arguments against .on() are invalid.Measuring Performance
Because of the way that it works, you may think that there is a performance hit to using .on() instead of attaching the handler to each element when it's created. So I decided to do some extensive testing to see if this was the case.I wrote a simple test page that dynamically generates lots of clickable elements. See this page at http://coordinatecommons.com/jquery-on-test.html.
For each test case, there are two different measures of performance. First is how long it takes to dynamically generate the elements. When using .on, this is mostly the time to simply generate the DOM elements. However, when using .click to bind the listener one at a time, it takes longer because of the added step to attach the listener at this point.
The second measure is how long it takes for the callback to be called after clicking. For this, the time is how long between the parent container's mousedown event and the event handler being called. Because the initial time is on mousedown, there is some variability test to test based on how much time it took me to let go of the mouse button. So any result here can vary by 100-150ms, the results should not be analyzed any more precise than 150ms intervals. And realistically you can probably subtract on average 80-100ms from each of these to get the actual times.
Test Cases
- Generate 10,000 divs with the same class name, using .on - generate 10,000 of the same type of element that will all use the same event handler. Attach the same class name to all elements, one call to .on.
- Generate 10,000 divs with one of 100 different classes names, click handler using .on - 100 different event handlers, 10,000 total elements. .on is called 100 times
- Generate 1,000 divs with unique classes, click handler using .on - 1,000 unique event handlers for 1,000 elements. .on is called 1,000 times
- Generate 10,000 divs with unique classes, click handler using .on - 10,000 unique event handlers for 10,000 elements. .on is called 10,000 times
- Generate 1,000 divs with unique IDs, click handler using .click - attach an event listener to each element with .click as the element is being added.
- Generate 10,000 divs with unique IDs, click handler using .click - same as above but with 10,000 elements.
Tests 1 and 6 are the ones that will really evenly compare performance of attaching a handler to each element as it's added versus using .on.
Test Conditions
For Chrome, Firefox, and IE9, a desktop machine (quad core 3 GHz, 8 gigs of RAM) running Windows 7 Professional 64 bit was used. For IE6, 7, and 8, a Windows XP Virtualbox VM running on the desktop machine above was used.Performance Results Table
| Chrome 17 | Firefox 11 | IE9 | IE8 | IE7 | IE6 | |
|---|---|---|---|---|---|---|
| Test 1 RENDER- 10K same class/handler .on | 912 ms | 271 ms | 3020 ms | 3142 ms | 3668 ms | 3877 ms |
| Test 1 CLICK - 10K same class/handler .on | 70 ms | 74 ms | 110 ms | 121 ms | 110 ms | 133 ms |
| Test 2 RENDER - 10K one of 100 class .on | 1081 ms | 344 ms | 3270 ms | 4857 ms | 5732 ms | 5965 ms |
| Test 2 CLICK - 10K one of 100 .on | 94 ms | 114 ms | 111 ms | 131 ms | 137 ms | 95 ms |
| Test 3 RENDER - 1,000 unique classes .on | 328 ms | 164 ms | 832 ms | 1483 ms | 1385 ms | 1021 ms |
| Test 3 CLICK - 1,000 unique classes .on | 140 ms | 162 ms | 107 ms | 140 ms | 107 ms | 120 ms |
| Test 4 RENDER - 10,000 unique classes .on | 2772 ms | 1397 ms | 14050 ms | 15602 ms | 47609 ms | 29614 ms |
| Test 4 CLICK - 10,000 unique classes .on | 245 ms | 252 ms | 149 ms | 421 ms | 409 ms | 442 ms |
| Test 5 RENDER - 1,000 unique ID .click | 281 ms | 175 ms | 898 ms | 1983 ms | 2133 ms | 2023 ms |
| Test 5 CLICK - 1,000 unique ID .click | 106 ms | 112 ms | 100 ms | 103 ms | 100 ms | 90 ms |
| Test 6 RENDER - 10,000 unique ID .click | 2826 ms | 1576 ms | 14618 ms | 50673 ms | 65835 ms | 66606 ms |
| Test 6 CLICK - 10,000 unique ID .click | 80 ms | 113 ms | 106 ms | 94 ms | 100 ms | 130 ms |
Results
Using .on() to capture the event over attaching a handler directly to each element has virtually no performance impact when the event is triggered, even when there are a huge number of unique elements with their own .on() handler on the page. I expected there to be at least some noticeable lag in the click times when there are 10,000 unique elements, but it was only noticeable on IE8 and below and just barely noticeable. And, that's with using .on() in a way that it shouldn't be used. Test 1 is the way that .on() should be used, and it performs wonderfully. Times are identical to test 6, where each element has a directly attached handler.
However, using .on() does have a very noticeable performance advantage when generating/rendering elements. This is obvious in test 1, the render times for the same number of elements is anywhere from 7 to 17 times faster than attaching the handler to each rendered element!
So based on this my recommendation is to use .on() to attach event handlers any time there will be more than one element added with the same function used for the handler.
Other observations
Another thing I found interesting is that on nearly all tests, Firefox is the fastest. Chrome is definitely behind Firefox for these tests. Also, seeing the numbers for IE8, it's a real shame that nearly 25% of the world is using this browser. Microsoft did very little to improve performance in between 6 and 8, and performance improvements in 9 many times are very small. Microsoft, IE10 better be blazingly fast! And, please, work on getting Windows XP users to upgrade to IE10. Firefox and Chrome run perfectly well on Windows XP, your own browser should as well.
