Speed Up Scroll Events with Passive Event Listeners

Joshua Bemenderfer

Okay, let me get this out of the way real quick. I hate websites that attach wheel (or touchstart and touchmove) events to a page. Utterly hate them. The main reason is the horrid resulting performance, especially on mobile. You see, the browser has to wait to redraw the page until the event listener finishes execution, as the event is able to be canceled. If your event runs on every single scroll, then scrolling the page gets incredibly janky, especially if you don’t debounce the events. Thankfully, there is now a solution: Passive Event Listeners.

Passive Event Listeners allow you to attach un-cancelable handlers to events, letting browsers optimize around your event listeners. The browser can then, for example, keep scrolling at native speed without waiting for your event handlers to finish executing.

While they are a relatively new addition to the spec, they’re already supported by most of the big players. (Everybody except IE, Edge, and Opera Mini, basically.)

Additionally, their usage is such that they don’t really break existing behavior. If you need to support the other browsers, you can use this polyfill.

Usage

Using passive events, unfortunately, is pretty complicated.

Say your original code is something like this:

// Really, if you're using wheel, you should instead be using the 'scroll' event, as it's passive by default.
document.addEventListener('wheel', (evt) => {
  // ... do stuff with evt
}, true)

You’ll need to replace it with this:

document.addEventListener('wheel', (evt) => {
  // ... do stuff with evt
}, {
  capture: true,
  passive: true
})

Yeah. I know. Almost impossible to wrap your head around. 😉

Let me try to explain.

So, often when registering scroll events, you add the last parameter, true, to indicate that your event should run in the capturing phase. (ie. top-down instead of bottom-up)

One of the new features enabling passive events is the EventListenerOptions spec. Sounds scary, but it really just optionally replaces that capture boolean with an object with a few properties. In this case, we can set capture to true to get the same result as the first example, and then set passive to true to make the event passive.

To improve performance further, make sure you’re throttling or debouncing your events. :)

Uses

The events with the greatest perceived performance penalty (say that five times fast) on mobile are scroll, wheel, touchstart, and touchmove. Scroll already is passive by default, so that takes one event out of the equation. As of Chrome 55, touchstart and touchend are passive as well.

So, if you’re handling any of those four events on mobile, it couldn’t hurt to throw in that tiny polyfill and add { passive: true } to those events. 99% of the time you won’t need to cancel those events anyway, and using { passive: true } can add a massive performance boost. So why not?

✖ Clear

🕵 Search Results

🔎 Searching...