High Performance jQuery

 

These are my notes from a talk given by Robert Duffy at the jQuery conference in Mountain View, California.

Before we look at high performance jQuery, we have to look at low performance jQuery. Part of my job is to take code that's running slow and make it faster. A lot of time we're looking at code that started as a prototype and it got rolled into production, and we have to fix it.

Clunky

This is what I call Clunky. One of my interview questions is

What is clunky, and how can you get rid of it?

Clunky for me is being slow enough to be almost completely unusable. If you remember typing at a DOS prompt, you could type something like five commands into the future while the computer was trying to catch up with you.

This is the Clunky excuse:

Works on my machine

But our users aren't using the latest computers. They have a limited amount of experience and a limited number of resources. You need to write applications that work as well in bad browsers as they do in good browsers.

We all have nice unclunky interfaces that provide an enjoyable and engaging experience. The iPhone provides a nice mobile unclunky experience. On the internet we have this concept of instant gratification.

jQuery makes it easy. It makes it easy to do good things, and it makes it easy to do bad things.

Demonstrate

[Robert gave a demo of a race car. He makes a great deal of noise about the fact that this race car is the fastest in the world, and is British. The engine written in very bad jQuery, with the pistons in the engine written as an ordered list, and jQuery that runs the engine, that pushes the car across the screen. The first run took 12 seconds.]

Optimizing this code is not rocket science.

Degrading Performance

This is one of the things that you see a lot in single-page applications, where the user has to stay on the same page for the application to work. If you're pulling things in and attaching events, you fall into some traps.

One case is Event Binding. In some cases, you put some DOM on the page, and you bind an event to it, but you keep binding the event. Maybe you bind an event to a 'close' button. If you click the button, the page may take a long time to close. Commonly, what you find you're doing is binding loads of events to this one button. One way to get around this is to use live events.

It's very easy to leave stuff lying around the DOM. In our example, our car is appending an "exhaust" div every time the engine cycles. If we remove that...

[Robert runs the test again, faster. The audience cheers when prompted. The car takes 6.8 seconds.]

It's still pretty slow.

Use the Right Tool

At the prototype stage, you don't worry about optimizing your code as much; you hide things, for example.

Rather than using .show() and .hide(), why not use CSS? Instead of .each(), use a for loop. Don't fall into the trap of using jQuery for everything. Use the right tool for the right job.

Instead of adding and removing to the DOM, just show and hide it. If an element is going to reappear on the page, don't remove it from the DOM.

[Robert runs the test again, faster. An audience member notices that the third cylinder is not firing in the visual example. Robert says not to worry about it; someone in the audience suggests the cylinder is not firing because the car is British.]

Don't Be Lazy

We all know the impact of our actions, but even the best programmers end up not caching some selectors, and copying and pasting code, and ending up with a bunch of selectors that aren't cached.

Rather than using a selector inside a loop, cache your re-used selectors. For example, don't run 'div.piston_head' over and over; assign it to a variable and don't execute them every time if the content is the same.

[Robert runs the test again, and the car runs at 2.4 seconds. Robert chastises us for our low level of enthusiasm for the faster car.]

Use CSS Classes

Propagating a CSS change to the live environment may be difficult in a large organization, but you should try to move as much out to CSS classes as possible.

[Robert shows the final run at 1.4 seconds and compares it to the initial run. The audience boos.]

These optimizations are actually quite simple. We don't need to worry about the rocket science at the beginning.

Thanks to Robert for the great talk.

Did you enjoy this post? Please spread the word.