gsap-performance

Animate transform properties (x, y, scale, rotation) and opacity, which stay on the compositor and avoid layout. Add will-change: transform in CSS only on elements that actually animate, and use stagger or quickTo instead of creating many individual tweens.

Avoid animating width, height, top, left, margin, and padding because they trigger layout and can cause jank. Use GSAP's x and y (translate transforms) and scale instead to achieve the same visual movement on the compositor.

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

Pin only the elements that need it, use a small scrub value like scrub: 1 to reduce scroll work, and call ScrollTrigger.refresh() only when layout actually changes, debounced where possible. Test on low-end devices to verify smoothness.

Jank occurs when hundreds of simultaneous tweens or ScrollTriggers run at once, or when layout-heavy properties are animated. Use stagger for identical animations, virtualize long lists, animate only visible items, and kill off-screen animations.

No. Apply will-change only to elements that are actually animating, since blanket layer promotion wastes memory and can hurt performance. Use it as a targeted hint, not a default for every element.