feat: Annotate our scroll events as passive
#1684
Conversation
Browsers need to process all events before they can do the default behavior. This is usually not a problem for most events because what we're doing is important and we can spend ~10ms processing an event, but this is a bigger problem when we're processing `scroll` events. `scroll` events trigger hundreds of times per second, and if you spend 10ms processing it, scrolling becomes very slow. Luckily, browsers provide us a way to tell it: hey, I'm not going to call `preventDefault`, just scroll away! That's done by adding `passive: true` when calling `addEventListener`. This basically tells the browser we won't call it, and that if we do call it, it's ok, we're wrong and shouldn't have called it, you don't need to respect our call. We are tracking scroll in two different places (should probably do only one, to be honest?) - dead clicks autocapture AND heatmaps (via `scrollManager`), so I've added it to both places! It's hard to see performance improvements in my super power mega blaster M3 but it should be helpful for lower-end devices.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Size Change: +736 B (+0.02%) Total Size: 3.28 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
We probably need some kind of reassurance that this works on IE.
It's not supported (https://caniuse.com/?search=passive-event-listener) which is fine, but we need to make sure it doesn't crash
Edit: I meant to comment rather than approve. I promise I've used a computer before!
Too late, I have infinite power now
I'll see if my Windows 11 can download it :) Edit: I can! https://github.com/ciao1092/IELauncher |
|
@robbie-c It works :) https://www.loom.com/share/ba333f3ede1d4cad90c058923db65d85?sid=46c05d34-300b-4e00-97bc-97148b782672 I'll wait for a second approve of yours |
Browsers need to process all events before they can do the default behavior. This is usually not a problem for most events because what we're doing is important and we can spend ~10ms processing an event, but this is a bigger problem when we're processing
scrollevents.scrollevents trigger hundreds of times per second, and if you spend 10ms processing it, scrolling becomes very slow. Luckily, browsers provide us a way to tell it: hey, I'm not going to callpreventDefault, just scroll away! That's done by addingpassive: truewhen callingaddEventListener. This tells the browser we won't call it, and that if we do call it, it's ok, we're wrong and shouldn't have called it, you don't need to respect our call.We are tracking scroll in two different places (should probably do only one, to be honest?) - dead clicks autocapture AND heatmaps (via
scrollManager), so I've added it to both places!It's hard to see performance improvements in my super power mega blaster M3 but it should be helpful for lower-end devices.