Clients ask for scroll-driven animation and a 90-plus mobile Lighthouse score in the same sentence, and the two are usually presented as a trade-off. They are not, as long as a handful of rules hold from the first commit.
Animate transform and opacity only
Those two properties can be handled by the compositor without triggering layout or paint. Animating width, height, top or box-shadow forces the browser to recalculate layout on every frame, which is where dropped frames on mid-range Android phones come from.
Budget the motion bundle
A scroll library, an animation library and a 3D renderer together can easily exceed 300 KB gzipped, which is most of your JavaScript budget spent before any application code loads. We hold motion code to roughly 80 KB gzipped and lazy-load anything below the fold.
Reserve space for everything
Cumulative Layout Shift is the metric animation damages most easily. Every image, video and embed needs explicit dimensions or an aspect ratio so nothing reflows when it arrives.
Turn it off when asked
Respect prefers-reduced-motion properly, which means disabling scroll hijacking and pinning, not just shortening durations. It is an accessibility requirement and it is also a good test: if the page is unusable without motion, the motion was carrying content it should not have been.
Simplify below 768 pixels
Pinned horizontal scroll sections and parallax layers should stack vertically on phones. Mobile is where Lighthouse is measured and where the weakest hardware lives, so it is the wrong place to spend your frame budget on an effect.
Make the budget fail the build
A performance budget that is only checked before launch will be exceeded within a quarter. Wire it into continuous integration so a regression fails the pull request that caused it, while the person who caused it still remembers why.