Using event capturing to improve Basecamp page load times

$.ready(function() {
  $("article.todolist, section.todolists").sortable();
});

$(document).on("mousedown", ".sortable_handle", function() {
  $("article.todolist, section.todolists").sortable();
});

Phases and Stages

W3C’s DOM Level 2 Events API specifies two phases for events: capturing and bubbling. The third argument to the addEventListener method lets you specify which phase you’re concerned with when you register to be notified of events on an element. How are these phases different?

Bubbling

Bubbling is the phase we use in everyday development. When an event like mousedown is triggered on an element, any event listeners on that element are notified. Then the listeners on each parent element are notified in succession until propagation is canceled or the event reaches the outermost element on the page.

When you use event delegation techniques like jQuery’s delegate method or Backbone view events, you’re taking advantage of the bubbling phase.

Capturing

The capturing phase is the inverse of the bubbling phase. Capturing happens before bubbling, and in reverse order—instead of starting on the target element and propagating outwards, the outermost element is notified of the event first. Then the event makes its way down the hierarchy until it reaches the target.

The mechanics of the capturing phase make it ideal for preparing or preventing behavior that will later be applied by event delegation during the bubbling phase. And that’s how we’re going to use it here—to initialize the sortable in response to a mouse click, but just before the event starts bubbling and other handlers have a chance to deal with it.

Implementing Capturing

To make use of capturing, we have to go down to the metal. jQuery’s event methods only work for bubbling and don’t let us tap into the capturing phase. The capturing handler looks like:

document.addEventListener("mousedown", function(event) {
  if ($(event.target).closest(".sortable_handle").length) {
    $("article.todolist, section.todolists").sortable();
  }
}, true);

(Note the true at the end of the addEventListener call—that’s what tells the browser to use capturing.)

Now the expensive sortable initialization is deferred until the point of intent. Reordering works again and our page loads are snappy!

A nice consequence of this approach is that we’ll no longer waste time initializing sortables on touch devices, since they’ll never trigger mousedown events. (Eventually we’d like to get reordering working on all devices, but we’ll save that for a later iteration and take the performance win now.)

“But I Can’t Use It!”

Capturing works in browsers that support the W3C event model. That means all modern browsers from the last ten years, and Internet Explorer as of version 9.

We’re in a lucky place because the new Basecamp requires IE 9 or higher. But we could use this capturing technique even if we needed to support older versions of IE by conditionally falling back to the older code where necessary.

Don’t be blindsided by conventional wisdom. Before dismissing capturing because you can’t use it everywhere, consider the places you can use it to progressively enhance the experience for those with a more modern browser.

Taking It Further

Deferred initialization is a definite improvement, but we’re still doing more work on mousedown than we need to. Consider the case where you click on a to-do to check it off or visit its permapage. It’s unnecessary to initialize every sortable on the page at click time—we need only to worry about the sortable under the mouse pointer.

So let’s scope our capture handler down to just the current sortable:

document.addEventListener("mousedown", function(event) {
  $(event.target).closest(".sortable").sortable();
}, true);

This works for reordering to-dos within a single list, but now it’s not possible to move a to-do from one list to another. We can fix it by listening for a sortstart event and then initializing all the sortable’s siblings:

$(document).on("sortstart", ".sortable_container", function(event) {
  $(event.currentTarget).find("> .sortable").sortable();
});

Now we do as little initialization work as possible on mousedown and defer the heavy lifting until the first mouse movement after clicking, when we know you really want to reorder.

Measuring the Win

How does the deferred initialization approach pay out in practice? Here are the results from measuring the time it takes to execute all page load callbacks on a sample project, averaged over five runs:

	Before	After	Net Win
Project permapage	443 ms	211 ms	2x
To-do lists index	555 ms	93 ms	6x

Not bad for just shuffling a few lines of code around!

If you’re looking to speed up page load times in your own projects, start by profiling. Then identify the hotspots and defer them until the furthest point of intent—where you know the user is about to perform the action you need to set up.