jQuery Toronto Lessons Learned: Finding Performance in Your Dev Tools

Recently, Alex McPherson and I spoke at jQuery Toronto. The conference was well organized and full of excellent content. This is a quick wrap-up of our experiences in the great white north and how I learned to make my slide deck perform better!

The State of jQuery is Strong!

The conference kicked off with a keynote by Dave Methvin on the state of jQuery. There has been considerable effort by the jQuery team to take some pretty big steps in recent months; specifically, version 1.9 established a line in the sand for many long-deprecated portions of the jQuery API, and a plans to drop support for older browsers in version 2.0 were put into motion. Two things stand out for me about Dave's talk: first, despite all of the outward communication surrounding the plans to finally remove deprecated code from 1.9 (and making an excellent compatibility plugin to help folks with the upgrade), many users were caught off-guard by the changes and said so on the jQuery bug tracker; secondly, he cited a statistic that Google search queries for "jquery" have finally surpassed those for "javascript."

I found both of these revelations surprising, but both make sense, in a way. Many developers are being introduced to jQuery prior to learning JavaScript (or at least needing to use it for anything significant.) This means that beginners might not understand why hot-linking to the latest build of jQuery isn't a very good idea since there may be breaking changes some day. Fortunately, one of the best developments to come out of [jQuery's recent refactor and open-sourcing of all of the jQuery websites was the creation of the jQuery Learning Center, which includes editable, open source documentation for learning the basics of JavaScript and jQuery. Consequently, the details of this process were deftly covered by jQuery Core team member Adam Sontag during the conference.

Chasing Down Performance Bottlenecks

Addy Osmani and Paul Irish from Google stepped up to the plate to deliver closing keynotes on the first and second day of the conference. Both of them covered similar content: how you can use the Chrome Developer tools to improve your productivity as developer and the overall user experience of what you're developing. This isn't the first time the notion of caring about your browser's framerate has come up, but it is probably the first time that it's been given an in depth explication in front of 500 jQuery developers.

On day one, Addy Osmani led the audience through a comprehensive walkthrough of what framerate is and why it matters to front end developers. By performing a handful of optimizations through the Chrome Developers tools, he was able to make visible improvements Pintrest's scrolling and rendering performance. If you haven't already, I highly recommend reading his post on how to create a development workflow around the Chrome Developer tools timeline and profiles. It's great to see more tooling and evangelism coming out of the woodwork on this topic, which was previously the exclusive domain of browser vendors and black magic to everyone elseā€”gone are the days of having to rely on your wits and visual acuity to make a complex or image-heavy page have silky-smooth scrolling and rendering performance.

Paul's talk was more of grab-bag of new front end awesomeness, but he also demo'ed what's possible with the latest version of Chrome Canary and a little bit of in browser magic to suss-out slow repaints and get to the bottom of potential rendering bottlenecks. He mentioned that much of what he and Addy were discussing are also now in the new Chrome Developers Documentation site, which is probably the best start-point for you if you're want to get more out of the tools you're probably already using.

Applying Optimizations

The best part of all this is that I found a way to make it specifically relevant to the content in my talk, "Fixing Broken Windows: 10 small things that will instantly improve your project." Being an avid fan of animated GIFs, I accordingly made a presentation that had lots of animation, both in the DOM and of the GIF variety. Because of this, my deck was a touch slow when animating between pages, especially with large background images. On the flight back, I decided to see how much I could do to make it perform a little bit better, using the some of the techniques that Addy and Paul talked about. So I fired up a session of Chrome Canary and was off to the races.

I started by using the Timeline panel to determine what my framerate was when my deck was acting slow and how that related to both script execution, rendering and layout performance. I noticed that a lot of costly rendering operations were being triggered by JavaScript. Some of these were unavoidable, but it did show me a few places that I could simplify the JavaScript call stack by moving away from synchronous events in favor of direct method calling for a minor improvement. But there was still a lot of jittering during transitions between slides, so I started to dig a little bit deeper.

Using the timeline panel to investigate bottlenecks

Next, I tried using a technique to force Chrome into rendering certain things in differently layers with GPU acceleration. By applying a null transform in css, the browser will treat those items differently and handle rendering in a separate thread on the GPU. The code change was pretty simple:

article img[src*="gif"] {
  -webkit-transform: translateZ(0);

And the results were astounding! Nearly all of the jittery-ness and jank (a technical term for ugly scrolling or framerate, covered in Addy's slides) went away, and my framerate skyrocketed. By forcing animated GIFs to render separately from the rest of the content in my slides, additional CPU cycles were free to handle the JavaScript and rendering going on during slide transitions. Applied knowledge FTW!

But there is one big caveat here, which Addy covered today in a post on Google Plus: this is by no means a universal solvent, and like most other things on the front-end, there's a point at which it can start to negatively impact performance.

Conference Wrap Up

Both Alex and I were thrilled to participate in the first ever jQuery Conference in Toronto. The content of our talks focused on what you can do to better organize and manage your applications, and how you can emphasize long term quality by getting rid of minor erosions in your development workflow. We each had a lot of good questions after our talks, in person and on Twitter. There were 31 excellent speakers that covered a wide range of topics that are relevant to jQuery Developers, which, as Dave Methvin pointed out, are quite a large group. 55% of the top ranked 10,000 websites currently use jQuery.

We had a great time and hope to make it back in to Canada for more poutine soon!

Scott Vinkle, an attendee, has compiled an almost comprehensive list of speaker's slide decks.

And a big thanks to Darcy Clarke and the other organizers for giving us such a warm welcome and putting on a fantastic conference!