⚡ Bolt: optimize scrollTopBtn scroll listener#129
Conversation
Replaced unthrottled DOM modifications in scroll event listener with a
state-tracking approach. Now, classList.add/remove are only invoked when
the visibility state of the button actually changes, eliminating
unnecessary layout thrashing on every scroll tick.
Also added `{ passive: true }` to avoid blocking main thread scrolling.
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: Added state tracking for the
scrollTopBtnvisibility toggle and applied the{ passive: true }flag to the scroll event listener.🎯 Why: Unthrottled scroll events triggering DOM modifications (
classList.add/remove) on every tick cause layout thrashing and high CPU usage.📊 Impact: Reduces main thread blocking during scrolling, shifting from N DOM writes (where N is the number of scroll events over 300px) to at most 1 DOM write per boundary crossing.
🔬 Measurement: Start the live preview server or app, scroll the page down past 300px, and observe CPU profiling in Chrome DevTools to confirm zero layout calculations while scrolling continuously beyond the threshold.
PR created automatically by Jules for task 4810233978442741863 started by @kaitoartz