fixing-motion-performance

Janky CSS animations usually animate layout or paint properties like width, height, or top. Switch to compositor-only properties, transform and opacity, so the browser skips layout and paint during the animation.

Use CSS scroll-timeline or view-timeline for scroll-linked motion instead of listening to scroll events and reading scrollY. For visibility-based triggering, use IntersectionObserver, which avoids polling scroll position every frame.

Layout thrashing happens when code interleaves DOM reads and writes in the same frame, forcing repeated layout recalculation. Batch all reads first, then all writes, or use a FLIP pattern: measure once, apply the change, measure again, then animate via transform.

Use will-change temporarily and surgically, only on elements about to animate, and remove it afterward. Overusing it creates too many promoted layers, which consumes memory and can hurt performance instead of helping.

No. The rules apply within your existing animation stack, whether CSS, WAAPI, Motion, rAF, or GSAP. Library migration or rewriting is explicitly out of scope unless you request it.

Blur and filter animations trigger expensive paint work on every frame, especially on large surfaces. Keep blur under 8px, use it only for short one-time effects, and prefer opacity and translate for continuous motion.