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.
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. :)
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?
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
While we believe that this content benefits our community, we have not yet thoroughly reviewed it. If you have any suggestions for improvements, please let us know by clicking the “report an issue“ button at the bottom of the tutorial.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!