魔法の杖か、諸刃の剣か。`will-change`の正体と賢い付き合い方
現場でパフォーマンスチューニングをしていると、必ず一度は「とりあえず `will-change: transform;` を入れとけ」というおまじないに出くわすはずだ。確かに、アニメーションがカクつくときにこれを書くと、嘘みたいにヌルヌル動くことがある。
しかし、なぜそうなるのか。そして、なぜ「全部の要素」に入れてはいけないのか。今日は、ブラウザの「レンダリングエンジン」という黒い箱の中で何が起きているのか、その裏側を覗いてみよう。
レイヤー化：ブラウザの「カンバス」戦略
ブラウザは通常、画面を一枚の絵のように描画する。だが、`will-change` を指定すると、ブラウザは「お、この要素は後で激しく動くんだな」と察知し、その要素を「独立したレイヤー（Composited Layer）」として切り離す準備を始める。
これを専門用語で「GPUアクセラレーションの活用」と呼ぶ。通常、描画はCPUで行われるが、レイヤー化された要素はGPUのVRAM（ビデオメモリ）へと配置される。CPUは「この要素は動かないから再描画しなくていい」と判断し、GPUが高速にそのレイヤーを合成（コンポジット）する。これが、アニメーションが劇的に滑らかになるカラクリだ。
諸刃の剣：メモリと戦うブラウザ
ここで注意が必要だ。レイヤーを生成するということは、「その要素をGPUメモリに焼き付ける」という行為に他ならない。
もし、ページ内のあらゆる要素に `will-change` を乱用したらどうなるか？
1. VRAMの枯渇: GPUメモリがパンクし、ブラウザはレンダリングの優先順位を判断できなくなる。
2. メモリオーバヘッド: レイヤーの構築・管理コストが積み重なり、かえってメインスレッドの負荷が増大する。
3. Z-indexの崩壊: レイヤーは重なり順（スタッキングコンテキスト）に影響を与えるため、予期せぬ要素が手前に表示される「レイヤー汚染」が起きる。
`will-change` は、いわば「今からここを工事するから、資材を別置き場に運んどくね」という宣言だ。資材置き場が足りなくなれば、現場はむしろ混乱する。
実践：賢い `will-change` の使い方
「必要なときだけ、終わったらすぐ捨てる」。これが鉄則だ。CSSで常駐させるのではなく、必要になる直前に適用し、終わったら外すのが最もクリーンな設計だ。
以下に、実務で使える「動的適用」のパターンを示す。
/
- 賢いwill-changeの管理パターン
- アニメーション開始直前に付与し、終了後に削除する
/
const targetElement = document.querySelector(‘.js-animate-target’);
// アニメーションを開始するトリガー関数
function startAnimation() {
// 1. レイヤー化をブラウザに指示
targetElement.style.willChange = ‘transform, opacity’;
// 2. CSSのトランジションやアニメーションをトリガー
targetElement.classList.add(‘is-animating’);
}
// アニメーション完了後の処理
targetElement.addEventListener(‘transitionend’, () => {
// 3. 重要：終わったらwill-changeを解放する
// これにより、GPUメモリの圧迫を防ぐ
targetElement.style.willChange = ‘auto’;
targetElement.classList.remove(‘is-animating’);
}, { once: true });
チーフアーキテクトからの助言
`will-change` を使う前に、まずは以下の手順を試してほしい。
1. まずはCSSだけで解決を試みる: `transform` や `opacity` の変更であれば、多くのモダンブラウザは自動的にGPU最適化を検討する。
2. DevToolsを確認する: Chrome DevToolsの「Layers」パネルを開き、本当にその要素が別レイヤーになっているか確認しよう。
3. `contain` プロパティと組み合わせる: `contain: paint;` などを併用することで、その要素の再描画範囲をブラウザに教え、無駄な計算をさらに減らすことができる。
ブラウザのレンダリングエンジンは、君たちが思っている以上に賢い。我々エンジニアの仕事は、そのエンジンを信じつつ、どうしても重い計算が必要な「ここぞ」という場面でだけ、正しいヒントを投げてやることだ。
「とりあえず」のコードは、いつか必ず技術的負債となって返ってくる。仕組みを理解し、制御可能なコードを書くことこそが、真のプロフェッショナルへの道だ。現場からは以上だ。
コメント