gsap-performance

Animate only transform properties (x, y, scale, rotation) and opacity, which stay on the compositor and avoid layout and paint. Add will-change: transform in CSS for elements that animate, and avoid width, height, top, and left.

gsap.quickTo() creates a single reusable tween for a property that updates frequently, such as mouse-follower x/y positions. It avoids creating a new tween on every mousemove event, reducing overhead.

No. Apply will-change only to elements that actually animate, since it promotes elements to their own compositor layer and consumes memory. Setting it everywhere 'just in case' wastes resources.

Jank often comes from animating layout properties, pinning too many elements, or calling ScrollTrigger.refresh() on every resize. Use scrub with a small value, pin only what is needed, and debounce refresh calls to fire only when layout actually changes.

Use stagger instead of many separate tweens with manual delays, and reuse timelines rather than creating new ones each frame. For long lists, consider virtualization or animating only visible items to avoid hundreds of simultaneous tweens.