⚡ Bolt: Optimize scrollTopBtn scroll event listener#122
Conversation
- Wrap scrollTopBtn visible toggle inside requestAnimationFrame to throttle execution to once per frame
- Add { passive: true } to the window scroll listener to avoid blocking main thread when preventDefault is not used
Co-authored-by: kaitoartz <56949089+kaitoartz@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
1 participant
💡 What: The scroll event listener for the
scrollTopBtnvisibility toggle has been optimized by wrapping the callback inside arequestAnimationFrameloop, and the{ passive: true }flag has been added to the event listener options.🎯 Why: High-frequency scroll events execute multiple times per frame, forcing layout recalculations that can cause stutter and layout thrashing. Furthermore, by default the browser waits to see if a scroll event listener calls
e.preventDefault(), delaying scroll updates.📊 Impact: This drastically improves scrolling performance by ensuring DOM manipulation (
classListupdates) only executes once per frame, and by indicating to the browser that scrolling will not be blocked.🔬 Measurement: Testing visual scroll fluidity under slow CPU simulation will show less jank and 60fps maintenance.
PR created automatically by Jules for task 15301131144574196423 started by @kaitoartz