fixing-motion-performance

Janky CSS animations usually animate layout or paint properties like width, height, or top instead of compositor properties. Switch to transform and opacity, which skip layout and paint, and avoid interleaving DOM reads and writes in the same frame.

Use CSS scroll-timeline or view-timeline for scroll-linked motion instead of listening to scroll events or polling scrollTop. For visibility-based pausing, use IntersectionObserver so off-screen animations stop consuming frames.

Layout thrashing happens when code interleaves layout reads (like getBoundingClientRect) and writes in the same frame, forcing repeated reflows. Batch all DOM reads before writes, measure once, and animate via transform using a FLIP-style approach.

Use will-change temporarily and surgically to promote an element to its own compositor layer before an animation. Avoid applying it broadly or permanently, since many or large promoted layers consume memory and can hurt performance.

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

No. The rules apply within your existing animation stack, whether CSS, WAAPI, Motion, GSAP, or rAF. Library migrations or rewrites are only done when explicitly requested, and mixing animation systems in one component is discouraged.