Gsap performance

是什么

帮你把网页上 GSAP（GreenSock Animation Platform，业界主流网页动画库）做的动画从卡顿、掉帧调到顺滑 60 帧，让用户在低端机和老浏览器上也感觉得到"丝滑"。

怎么用

1. 把动画卡顿的页面截图或链接发给它，告诉它具体在哪一段觉得卡。
2. 它先看你的动画在改什么属性，把"会引起重排"的项替换成 GPU（图形处理器）友好的位移和透明度。
3. 它给频繁动的元素加上 will-change（提前提示浏览器优化）的开关，用完即关，避免内存浪费。
4. 它会把一堆零散动画合并成一条时间线，减少浏览器调度成本。
5. 改完后它会让你在 DevTools（开发者工具）里看一眼帧率曲线，确认掉帧的红条没了。

架构图

flowchart LR
  A[卡顿动画] --> B[替换为位移与透明度]
  B --> C[按需 will-change]
  C --> D[合并为时间线]
  D --> E[帧率曲线复核]

GSAP Performance

When to Use This Skill

Apply when optimizing GSAP animations for smooth 60fps, reducing layout/paint cost, or when the user asks about performance, jank, or best practices for fast animations.

Related skills: Build animations with gsap-core (transforms, autoAlpha) and gsap-timeline; for ScrollTrigger performance see gsap-scrolltrigger.

Prefer Transform and Opacity

Animating transform (x, y, scaleX, scaleY, rotation, rotationX, rotationY, skewX, skewY) and opacity keeps work on the compositor and avoids layout and most paint. Avoid animating layout-heavy properties when a transform can achieve the same effect.

• ✅ Prefer: x, y, scale, rotation, opacity.
• ❌ Avoid when possible: width, height, top, left, margin, padding (they trigger layout and can cause jank).

GSAP’s x and y use transforms (translate) by default; use them instead of left/top for movement.

will-change

Use will-change in CSS on elements that will animate. It hints the browser to promote the layer.

will-change: transform;

Batch Reads and Writes

GSAP batches updates internally. When mixing GSAP with direct DOM reads/writes or layout-dependent code, avoid interleaving reads and writes in a way that causes repeated layout thrashing. Prefer doing all reads first, then all writes (or let GSAP handle the writes in one go).

Many Elements (Stagger, Lists)

• Use stagger instead of many separate tweens with manual delays when the animation is the same; it’s more efficient.
• For long lists, consider virtualization or animating only visible items; avoid creating hundreds of simultaneous tweens if it causes jank.
• Reuse timelines where possible; avoid creating new timelines every frame.

Frequently updated properties (e.g. mouse followers)

Prefer gsap.quickTo() for properties that are updated often (e.g. mouse-follower x/y). It reuses a single tween instead of creating new tweens on each update.

let xTo = gsap.quickTo("#id", "x", { duration: 0.4, ease: "power3" }),
    yTo = gsap.quickTo("#id", "y", { duration: 0.4, ease: "power3" });

document.querySelector("#container").addEventListener("mousemove", (e) => {
  xTo(e.pageX);
  yTo(e.pageY);
});

ScrollTrigger and Performance

• pin: true promotes the pinned element; pin only what’s needed.
• scrub with a small value (e.g. scrub: 1) can reduce work during scroll; test on low-end devices.
• Call ScrollTrigger.refresh() only when layout actually changes (e.g. after content load), not on every resize; debounce when possible.

Reduce Simultaneous Work

• Pause or kill off-screen or inactive animations when they’re not visible (e.g. when the user navigates away).
• Avoid animating huge numbers of properties on many elements at once; simplify or sequence if needed.

Best practices

• ✅ Animate transform and opacity; use will-change in CSS only on elements that animate.
• ✅ Use stagger instead of many separate tweens with manual delays when the animation is the same.
• ✅ Use gsap.quickTo() for frequently updated properties (e.g. mouse followers).
• ✅ Clean up or kill off-screen animations; call ScrollTrigger.refresh() when layout changes, debounced when possible.

Do Not

• ❌ Animate width/ height/ top/ left for movement when x/ y/ scale can achieve the same look.
• ❌ Set will-change or force3D on every element “just in case”; use for elements that are actually animating.
• ❌ Create hundreds of overlapping tweens or ScrollTriggers without testing on low-end devices.
• ❌ Ignore cleanup; stray tweens and ScrollTriggers keep running and can hurt performance and correctness.