will-changeとレイヤー昇格

will-changeは、要素がアニメーションする予定であることをブラウザーに伝えるヒントです。これにより、アニメーション開始前に要素を独自のGPUコンポジターレイヤーへ昇格させるなど、最適化の準備をあらかじめ行えるようになります。

変更されるプロパティを指定します。will-change: transform、will-change: opacity、will-change: transform, opacityのように記述します。アニメーション終了後にヒントを削除するには、will-change: autoを使用します。

実際にアニメーションする要素に対して、アニメーション中だけwill-changeを適用します。JavaScriptで（クラスを介して）追加と削除を行うほうが、静的な要素に設定したままにするより効率的です。

昇格した各レイヤーはGPUメモリを消費します。多数の要素を同時に昇格させるとメモリに負荷がかかり、パフォーマンスが低下する可能性があります。特に、GPU RAMが限られているモバイルデバイスでは顕著です。昇格は必要な箇所に限定し、意図的に行ってください。

will-changeを*や多数の要素に適用してはいけません。レイヤーを作りすぎると、最適化によるコストが効果を上回ります。まずプロファイルを取得し、特定のカクつきの問題が確認できた箇所にのみwill-changeを追加してください。

will-changeが登場する前は、開発者はtransform: translateZ(0)やtranslate3d(0,0,0)を使ってGPUへの昇格を強制していました。will-changeは、意図を意味的に表現する正しい方法です。translateZハックは今でも機能しますが、意図を表すものではなく、実装の詳細にすぎません。

昇格したレイヤーは新しいスタッキングコンテキストを作成します。これによりz-indexの動作が変わります。昇格した要素の子要素はドキュメントルートではなく、その要素を基準に重なり順が決まります。要素を昇格させる際は、スタッキングコンテキストの変化に注意してください。

mouseenter時またはアニメーション開始時にwill-changeを追加し、mouseleave時またはアニメーション終了時に削除します。これにより、アイドル状態の要素のためにGPUメモリを恒久的に消費することなく、ブラウザーに準備時間を与えられます。

Chrome DevTools → Layersパネルで、昇格したレイヤーを可視化できます。レイヤー数が多い（数百ある）場合は、過剰な昇格を示しています。MemoryセクションにはGPUメモリの使用量が表示されます。昇格したレイヤー数は最小限に抑え、ローエンドデバイスのプロファイルでも監視してください。

CSSのcontain: layout paintは、分離と同様に、レイアウトとペイントの計算をサブツリー内に制限します。GPUレイヤーを作成せずに自己完結型のウィジェットのパフォーマンスを向上できるため、アニメーションしない要素にはwill-changeよりコストの低い最適化です。

will-changeは、すべての現代的なブラウザーで完全にサポートされています。ブラウザーはこれを命令ではなくヒントとして扱うため、リソースが不足している場合は無視することがあります。保証として依存せず、パフォーマンスに関する指針としてのみ使用してください。

will-changeを多数の要素に同時に適用する主なリスクは何ですか。

will-changeはアニメーション開始前に要素をGPUコンポジターレイヤーへ昇格させるため、アニメーション開始時の昇格コストをなくせます。プロファイリングでカクつきが確認された箇所にのみ、動的かつ控えめに適用し、過剰な昇格によるGPUメモリの過度な消費を避けてください。