Attaching JavaScript Handlers to Scroll Events — a how-NOT-to.

Boost page performance when attaching scroll events using the Twitter method — creating clean, reusable, performance-driven code.

I came across an article by John Resig, Learning from Twitter — it completely changed how I attach JavaScript handlers to scroll events. It’s a simple trick that sets a slight delay, will boost performance and help keep your code object-orientated. Here’s the correct way:

var scrolling = false;

$( window ).scroll( function() {
  scrolling = true;
});

setInterval( function() {
  if ( scrolling ) {
    scrolling = false;
    // Do your thang!
  }
}, 250 );

// or for modern browsers
document.addEventListener( 'wheel', ( evt ) => {
  // Do your thang!
}, { capture: false, passive: true });

The Wrong Way

It’s a very, very, bad idea to attach handlers to the window scroll event.

Depending upon the browser the scroll event can fire a lot and putting code in the scroll callback will slow down any attempts to scroll the page (not a good idea). Any performance degradation in the scroll handler(s) as a result will only compound the performance of scrolling overall.

$( window ).scroll( function() {
  // Do your thang!
});

The Correct Way

It’s much better to use some form of a timer to check every X milliseconds OR to attach a scroll event and only run your code after a delay (or even after a given number of executions – and then a delay).

var scrolling = false;

$( window ).scroll( function() {
  scrolling = true;
});

setInterval( function() {
  if ( scrolling ) {
    scrolling = false;
    // Do your thang!
  }
}, 250 );

The modern browser way.

For input events (touchstart, wheel, scroll, etc.), most modern browsers support passive events:

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

This allows the UI thread to immediately handle the scroll event before passing over control to your custom event handler. Without passive option, your custom handler will always be called before the UI thread does anything with the event.

Scroll event throttling (adding a delay between handling the events) can be implemented quite neatly using lodash or rxjs, if you have them in your build already.

Hope this helps to clear things up and provides some good advice for future infinitely-scrolling-page developers!

Comments

  1. Oliver Schöning November 4, 2018

    Nice and simple 🙂 I occasionally also use _.debounce and _.throttle with lodash.

  2. For input events (touchstart, wheel, scroll etc) most modern browsers support ‘passive’ events e.g.

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

    This allows the UI thread to immediately handle the scroll event before passing over control to your custom event handler. Without passive option, your custom handler will always be called before the UI thread does anything with the event.

    Scroll event throttling (adding a delay between handling the events) can be implemented quite neatly using lodash or rxjs, if you have them in your build already

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

All comments are held for moderation and only published when on topic and not rude. You'll even get little stars if you do an extra good job.

You may write comments in Markdown. This is the best way to post any code, inline like `<div>this</div>` or multiline blocks within triple backtick fences (```) with double new lines before and after.

Want to tell me something privately, like pointing out a typo or stuff like that? Contact Me.

icon-search icon-link