sindresorhus
commented
12 months ago Performance in browsers, especially with events like window.onscroll, is complex. debounce and throttle can indeed add overhead, particularly in browsers like Firefox that handle event processing differently. Your findings suggest that in some cases, the additional logic of debounce or throttle might be more expensive than handling frequent, small operations directly.
This isn't a one-size-fits-all issue. It's context-specific, depending on the nature of the operations within the scroll handler and the browser's event processing. If performance is critical, profiling is essential. Consider alternative methods like passive event listeners or requestAnimationFrame for smoother handling of scroll events.
Hi,
Using this package or throttle I have done some tests in Firefox and I have noticed using either package (yours or theirs) for throttling or debouncing a window.onscroll function is worse then just allowing the function to run on every pixel scroll.
I wouldnt have thought this because i thought the debounce would prevent any operations from happening but it seems the operations the debounce does to debounce operations from happening is more expensive then the operations just happening.
It seems in firefox on every metric they measure says using debounce or throttle for onscroll is worse for performance.
Does anyone have anything to weigh in on this? I am not a performance measuring pro.