Javascript OnScroll performance comparison

So, @SirPeople already answered your first question correctly, it is indeed a good test to see how often the animate function gets called, but it's a bad test to compare the performance of the different snippets.

This is a performance recording of the excecution:

The function animate isn't expensive at all. I took a performance recording (next picture), which shows that it takes between 0.64ms and 1.29ms in the one iteration I looked at (points 1-5). And once the function is done, the repaint takes no time at all (point 6), which might be because the page has almost no content. When we take a look at the time, we can see that all five animation functions and the repaint happen in less than 10ms, which, under normal circumstances, mean that we can get a fluid 60fps animation (point 7).

Also, if we want to compare onscroll event listeners we need to test each on it's own and compare the results. If one of the listeners would really be blocking it would have an influence on the whole page and without performance debugging you wouldn't know which one it was.

I made two jsfiddles window.scroll and RAF. And, to my surprise, there does not seem to be any difference.

Why are people concerned about this?

As you can see in the jsfiddles linked above, if the event handlers get too large, the entire page is going to lag.

Now what?

I'm no performance guru myself, but:

• Perhaps one of the other solutions is correct
• We can mark your event listeners as passive, although in my test it didn't really improve at all https://developers.google.com/web/updates/2016/06/passive-event-listeners
• We can optimize the event listener by removing parallax effects
• There's also this new thing called Intersection Observer which is supposed to be much faster, I didn't test it https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

I am not totally sure if I got correctly your questions and all your statements but I will try to give you an answer:

• Am I missing something or is this a valid test? If it's invalid, how could I test correctly?

It is a valid test if you are measuring the number of times a function has been called, this will of course depend on the browser, SO, if is GPU enhanced and some other benchmark parameters that has been commented in your question already.

If we consider that measurement correct then it can be said that by using timeouts or requestAnimationFramework could save time because we are basically following the principles of debouncing or throttling. Basically we do not want to request or called a function more times than is needed. In the case of the timer we will queue less functions calls and in the case of requestAnimationFrame because it enqueue calls before repainting and will execute them sequentially. In timeouts it could happen that calculations overlap if they are very heavy.

I found a better answer in why using requestAnimationFrame explaining the main problems with animations in the browser like Shear, flickering or frame skip. It also includes a good demo.

I think your testing method is correct, you also should interpret it correctly, maybe calls are close to be the same number because of your hardware and your engine, but as said, debounce and throttling are a performance relieve.

Here also one more article supporting not attach handlers to window scroll from Twitter. (Disclaimer: this article is from 2011 and browsers have deal with optimizations for scroll in different ways).

• why is everyone nervous about onscroll? If fluid animations require 5000 calculations over the complete site, there's no way to change it anyway?

I do not think there is nervousness in the performance hit, but the user experience will be worst for the above mentioned animation problems that your overcalling of scroll can cause, or even if there is a desynchronization with your timer you could still get the same 'performance' problems. People just recommend saving calls to scroll because: Human visual permanence doesnt require a super high frame rate and so it is useless to try to show images more often. For more complex calculations or heavy animations browsers are already working on optimizations, like you have check, some browsers had optimize this things in comparison with the 2, 3 or 6 years ago the articles you expose were written.