High CPU usage when scrolling

[fbmcipher]

A performance issue I spotted while researching performance impact of will-change. This happens in Chrome too, but it's easier to see in Safari.

Steps to Reproduce

1. Open em on an iPhone or a simulator.
2. Attach Safari DevTools, and enable compositing borders to show repaint counters for each element.
3. Scroll up and down slowly.

Current Behavior

Static elements like the scroll zone and the toolbar excessively while the viewport scrolls. See the number on the scroll zone, for example, which rapidly rises – showing 274+ repaints even though its content hasn't changed at all.

Screen.Recording.2025-11-28.at.02.31.36.mov

This measurably thrashes the main thread, taking up more than 50% of the CPU cycles during a profile of the screen recording above:

Expected Behavior

Elements shouldn't repaint as the user scrolls.

[raineorshine]

This is probably due to the parallax effect in the scroll zone. Can you confirm?

[fbmcipher]

To confirm this, I ran two performance profiles on a physical iPhone 16 (2024):

• run 1: ScrollZone enabled
• run 2: ScrollZone returns null, disabling the entire scroll zone and the parallax effect created using useScrollTop() and transform

In both runs, I scrolled the thoughtspace slowly for 15s, both down and up – as a constant variable to keep both runs as similar as possible.

• Both runs show high CPU usage – an average of 34.5% utilisation
• The number of repaints is still unusually high, but stayed consistent between both runs (run 1: 1108, run 2: 1167)
  • So we can rule out the parallax effect, as disabling the entire ScrollZone had no impact on repaint count.
• The number of JavaScript entries is really high (run 1: 30153, run 2: 21644)
  • The drop in JS entries is very likely due to the parallax effect being disabled – though interestingly, CPU load remains constant. So the parallax effect is doing a lot of JS work, but not in a way that's negatively impacting performance.
  • There are still 20-30k events, timers and function calls within 15 seconds – which seems unusual.
  • JavaScript took 46-56% of total CPU usage in the profile.

Still working out what's causing the very high amount of repaints, but the profile does show some immediate culprits re: the high amount of JavaScript entries:

[raineorshine]

Okay, thanks! Great findings.

The only other hook/component that uses useScrollTop is usePositionFixed which has gone through a few refactors such as #2405 which may have inadvertently affected the performance.

Apparently I switched from a ministore to useState in fe50724 which seems bad for performance. I can see that I didn't want to use a throttled value any more, but maybe I should have created a new ministore and updated the DOM directly to keep it out of the React component lifecycle.

Or it could be something else!