gsap-performance

GSAP で書いた動きが滑らかに動かないときのスキルです。説明文は「カクつきを減らしたい」「60fps で動かしたい」「動きの性能について聞かれた」ときに呼ぶよう書いています。

GSAP を作っている GreenSock が公開している公式の手引きです。新しく動きを作るときより、作った動きを見直すときに効きます。

SKILL.md の大きさ（2026-10-23 時点）

4,139 バイト

同梱ファイル（SKILL.md 1 枚）

0 件

「やってはいけない」

4 項目

見直す観点は 6 つ

本文は次の 6 つの観点に分かれています。

• 動かす属性transform と opacity を優先し、幅や位置の属性は避ける
• will-change実際に動く要素にだけ、CSS で付ける
• 読み書きの順番DOM の読み取りと書き込みを交互にしない
• 要素が多いときstagger を使い、長い一覧は見えている分だけ動かす
• 頻繁に変わる値マウスに付いてくる動きは gsap.quickTo() で
• 同時に動く量画面の外や使っていない動きは止めるか消す

transform と opacity を優先する

動かすなら x・y・scale・rotation・opacity を選べ、というのが最初の規則です。これらは合成の段階で処理され、レイアウトの計算と、描き直しの大半を避けられる、と説明されています。

width・height・top・left・margin・padding は、動かすたびにレイアウトの計算が走ります。GSAP の x と y は既定で transform（translate）を使うので、位置を動かすなら left と top の代わりにこちらを使います。

読み取りと書き込みを交互にしない

GSAP 自身は更新を内部でまとめています。問題になるのは、GSAP と一緒に自分で DOM の大きさを読んだり書き換えたりする処理を混ぜたときです。

読みと書きが交互に並ぶと、そのたびにレイアウトの計算がやり直されます。先に全部読み、あとでまとめて書く（書くのは GSAP に任せる）よう勧めています。

マウスに付いてくる動きは quickTo

マウスの位置に合わせて要素を動かすような、値が頻繁に変わる動きには gsap.quickTo() を使います。動くたびに新しいトゥイーンを作らず、1 つのトゥイーンを使い回すためです。本文には、x と y の 2 つを quickTo() で作り、mousemove で値を渡す例があります。

ScrollTrigger の負荷

スクロール連動の動きについても 3 つの注意があります。

GSAP を使っていない

規則の大半は GSAP の書き方（quickTo()・stagger・x と y・ScrollTrigger）に結び付いています。CSS のアニメーションや別のライブラリで書いているなら、そのまま当てはまらない部分が多くなります。

ページ全体の読み込みが遅い

このスキルが扱うのは、動いている最中の滑らかさだけです。画像の大きさ、読み込みの順番、Core Web Vitals のようなページ全体の速さは扱いません。そちらは web-perf の担当です。

動きそのものを作り直したい

どの動きを残し、どれを減らすかを決めたいなら、improve-animations のほうが洗い出しから入れます。基本の書き方から作るなら gsap-core と gsap-timeline を、本文も案内しています。

SKILL.md 1 枚で、書き方を渡すだけ

SKILL.md の解析では、外部通信・シェル実行・ファイル操作の記述は見つかっていません。同梱ファイルは無く、SKILL.md 1 枚（4,139 バイト、2026-10-23 時点）で完結しています。

測り方は書かれていない

規則を全部当てても、遅さの原因が別のところにあれば変わりません。「性能の低い端末で試す」とは 2 か所で書かれていますが、どう試すかは任されています。

will-change を全部に付けない

will-change と force3D を「念のため」すべての要素に付けるのは、「やってはいけない」に入っています。付けるのは実際に動く要素だけで、CSS で付けるよう書かれています。

片付けを忘れると性能も壊れる

「やってはいけない」の最後は片付けです。残ったトゥイーンや ScrollTrigger は動き続け、性能と正しさの両方を損なう、と書かれています。画面を切り替える作りなら、離れたときに止めるか消すかを決めておきます。

動きを減らす設定には触れていない

動きを減らす設定（prefers-reduced-motion）には触れていません。動きの量を減らす話はありますが、性能のためで、利用者の設定に合わせる話ではありません。設定ごとの切り替えは gsap-core の gsap.matchMedia() の節にあります。

要素を動かすと、まわりの要素までガタつきます

width・height・top・left などを動かしていると、動くたびにまわりのレイアウトも計算し直されます。同じ見た目を x・y・scale で作れないか、まず確かめてください。本文の規則は、位置を動かすなら left と top ではなく x と y を使え、です。

一覧の項目を 1 つずつ時間差で出しています。重くなりませんか

同じ動きなら、delay をずらした別々のトゥイーンを並べるより stagger を使うほうが効率的だ、と本文にあります。項目が多い一覧なら、見えている項目だけを動かすか、一覧そのものを仮想化することも勧めています。数百の動きを同時に作るのは避けるよう書かれています。

画面の大きさが変わるたびに ScrollTrigger.refresh() を呼んでいます

本文は、レイアウトが実際に変わったときだけ呼ぶよう勧めています。画面の大きさが変わるたびに呼ぶのは避け、できれば間引きます。画像や中身をあとから読み込んだあとが、呼ぶべき場面です。

どれくらい速くなるかの目安はありますか

本文に数値の目安はありません。説明文に「60fps」とあるだけで、規則ごとにどれだけ効くかは書かれていません。直す前と後を、手元の端末と性能の低い端末の両方で比べるのが確実です。