「パフォーマンスで判断する」JavaScript vs CSS｜アニメーションの選択基準

こんにちは！

今日は「パフォーマンスで判断するJavaScript vs CSS」について解説します。
アニメーションをどちらで実装するか、悩んだことってありますよね。
実は現場での選択基準は、単なる「楽さ」じゃなくて、ブラウザの動作効率に大きく関わってくるんです。

僕がパフォーマンス重視に目覚めたきっかけ

正直な話、僕も最初はこんなことあんまり意識してなかったんです。
「アニメーション作るなら、とにかくJavaScriptで自由自在に制御しよう」くらいの感覚でした。
ほんまに若かったなあと思います（笑）

転機は、あるプロジェクトでした。
スマートフォンでページを見ると、スクロール時のアニメーションがめっちゃ重くて、フレームレートがドタバタになってしまったんです。
デバイスの内部発熱も半端なくて、クライアントから「こんなん使えん」って言われました。
その時に初めて気づいたんですよ。
「あ、技術選択には責任がある」って。

そこから僕は、ブラウザがどうやってアニメーションを処理しているのか、本気で勉強することにしました。
その経験が、今の判断基準になっているんです。

CSSアニメーションが得意な場面

結論から言いますと、CSSアニメーションは「GPUで計算できる変化」に向いています。
具体的には以下の場面です。

• transform（回転、スケール、移動）を使うアニメーション
• opacity（透明度）の変更
• 開始地点と終了地点が明確なアニメーション
• ユーザー操作に直接反応する必要がないアニメーション

なぜかって言うと、CSSアニメーションはブラウザのレンダリングエンジンが最適化してくれるからです。
GPUに処理を移譲できるので、メインスレッドに負荷がかからないんですよ。
つまり、JavaScriptの実行とぶつかってもカクカクしにくいんです。

例えば、マウスホバーで画像がふわっと出てくるとか、ページロード時に要素がスライドしてくるとか。
そういった「一度決まったら続く」系のアニメーションはCSSで実装するといいですよ。
コードもシンプルですし。

JavaScriptの出番はここ

逆に、JavaScriptが必要になる場面も確実にあります。
よくある現場あるあるをお伝えします。

• スクロール位置やマウス座標に応じた、リアルタイムなアニメーション
• 複数の要素が連鎖してアニメーションする
• ユーザー操作の途中で動きを調整したい場合
• ドラッグ＆ドロップのような、予測できないモーション

これらの場面では、CSSでは太刀打ちできません。
スクロール位置に応じてリアルタイムに計算する必要があるからです。
CSSでやろうとすると、無駄な計算が増えて、むしろパフォーマンスが悪くなっちゃいます。

ただし、JavaScriptを使う時は工夫が大切です。
例えば、requestAnimationFrame()を使って、ブラウザの描画タイミングに合わせるとか。
頻繁な値の更新はthrottleやdebounceで制限するとか。
そういった細かい気配りがパフォーマンスを大きく変えます。

実装前のチェックリスト

実装する前に、こんなことを確認するといいですよ。
これは僕が現場で毎回チェックするリストです。

1. アニメーションの内容は？
   transformやopacityだけで表現できるなら、CSS優先で考えましょう。
2. ユーザー操作に直結するか？
   スクロールやマウス移動に応じる必要があれば、JavaScriptが向いています。
3. 対象デバイスは？
   低スペックなスマートフォンが多いなら、CSSで負荷を減らしましょう。
4. 複数回実行される？
   毎回JavaScriptで計算するより、CSSで再利用した方が効率的です。
5. アニメーションの途中で止める可能性は？
   あれば、JavaScriptの制御が必要ですね。

このチェックリストを回すだけで、9割の判断は見えてきます。

まとめ

JavaScript vs CSSの選択は、「どちらが楽か」じゃなくて「ブラウザはどちらで効率的に処理できるか」で判断するといいですよ。
CSSはGPU最適化されているから、シンプルな動きに向いている。
JavaScriptはユーザー操作に応じた複雑な制御に向いている。
その特性を理解すれば、自動的に選択肢は見えてきます。

最初は戸惑うかもしれませんが、何度か実装していると「あ、この場面はこっちやな」って感覚的に分かるようになります。
その感覚を磨いていくことが、現場でのスキルアップにつながるんです。
一緒に頑張りましょう。