
Gsap Performance
Tune GSAP tweens for compositor-friendly motion and fewer layout thrashes so marketing sites and product UI stay near 60fps.
Overview
GSAP Performance is an agent skill most often used in Build (also Ship) that guides solo builders to animate transforms and opacity, use will-change, and avoid layout-thrashing properties for smoother GSAP motion.
Install
npx skills add https://github.com/greensock/gsap-skills --skill gsap-performanceWhat is this skill?
- Prefer transform and opacity over width, height, top, left, margin, and padding to cut layout and paint cost
- Use x/y (translate) instead of left/top for movement with GSAP defaults
- Apply will-change: transform in CSS to hint layer promotion before animating
- Batch DOM reads and writes awareness—aligns with GSAP’s internal batching discipline
- Pairs with gsap-core, gsap-timeline, and gsap-scrolltrigger for end-to-end GSAP stacks
Adoption & trust: 20k installs on skills.sh; 8.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your GSAP animations stutter because tweens target layout properties or the browser repaints every frame instead of compositing layers.
Who is it for?
Indie builders polishing hero sections, product tours, or scroll-linked UI already using GSAP who need concrete performance rules without guessing.
Skip if: Teams that need a full performance audit of non-GSAP CSS animations only, or projects with no GSAP dependency.
When should I use this skill?
Optimizing GSAP animations, reducing jank, or when the user asks about animation performance, FPS, or smooth 60fps.
What do I get? / Deliverables
You refactor tweens toward transform/opacity, add will-change where appropriate, and ship motion that is cheaper to paint—then continue with gsap-scrolltrigger if scroll drives the sequence.
- Refactored tween property choices
- CSS will-change recommendations
- Performance rationale for animation sequences
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Animation implementation usually happens while building UI; this skill is the canonical shelf for GSAP motion craft in Prism. Frontend is where transform/opacity choices, will-change, and read/write batching are applied in component markup and GSAP vars.
Where it fits
Refactor a hero parallax from top/left to x/y before merging the landing page.
Profile stutter on mobile and strip margin/padding tweens in favor of scale.
Polish launch micro-interactions so demo recordings stay smooth on low-end devices.
How it compares
Performance-focused GSAP guidance, not a generic Lighthouse checklist or an MCP animation server.
Common Questions / FAQ
Who is gsap-performance for?
Solo and indie frontend builders using GSAP who want official Greensock performance rules inside Claude Code, Cursor, or similar agents.
When should I use gsap-performance?
During Build when authoring tweens and timelines; during Ship when fixing jank before launch; whenever users ask about GSAP FPS, will-change, or layout thrashing.
Is gsap-performance safe to install?
It is documentation-style procedural knowledge with no shell or network requirements in typical use; review the Security Audits panel on this Prism page before enabling any repo skill in your agent.
Workflow Chain
Requires first: gsap core
Then invoke: gsap scrolltrigger
SKILL.md
READMESKILL.md - Gsap Performance
# 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. ```css 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. ```javascript 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. -