fixing-motion-performance

Animate only compositor-friendly properties like transform and opacity instead of layout properties like width or position. Batch DOM reads before writes, avoid scroll-event-driven animation, and use will-change temporarily only where layer promotion is needed.

Layout thrashing happens when code interleaves layout reads (like getBoundingClientRect) and writes (like style changes) in the same frame, forcing repeated reflows. Fix it by measuring once, then animating via transform, or by using FLIP-style transitions.

Use CSS Scroll or View Timelines (animation-timeline: view()) for scroll-linked motion when available, and IntersectionObserver for visibility detection and pausing. Polling scrollTop or scrollY in event handlers triggers continuous layout work and should be avoided.

Yes, the rules apply within any existing animation system including CSS, WAAPI, Motion, rAF, and GSAP. The Skill explicitly avoids migrating or rewriting animation libraries and never mixes multiple animation systems within the same component.

Blur animation is acceptable only for small surfaces at 8px or less and for short, one-time effects. Never animate blur continuously or on large surfaces; prefer opacity and translate transitions before reaching for blur.

will-change promotes elements to compositor layers, which consumes memory and can hurt performance when overused. Apply it surgically and temporarily, avoid many or large promoted layers, and validate layer behavior with browser tooling.