`will-change`という「禁断の魔術」――ブラウザのレイヤー合成を極限まで制御する
フロントエンドのパフォーマンスチューニングにおいて、`will-change`ほど誤解され、かつ強力な力を持つプロパティはない。「アニメーションがカクつくなら、とりあえず`will-change: transform`を当てろ」――そんな先人の教えを鵜呑みにして、アプリケーション全体をゾンビのようなレイヤーの塊にしていないだろうか？
今日は、ブラウザの合成エンジン（Compositor）の裏側を覗き込み、このプロパティがなぜ「劇薬」なのか、そして真のプロフェッショナルはどう使いこなすべきかを語ろう。
—
ブラウザが「レイヤー」を生成する瞬間の重み
まず、ブラウザがレンダリングを行う際、何が起きているのかを正しく認識する必要がある。通常、ブラウザはDOMをパースし、CSSOMを適用してRender Treeを作る。その後、Layoutを経てPaintを行い、最後にこれらを合成（Composite）して画面に表示する。
`will-change`は、ブラウザに対して「この要素は今後変更されるから、今のうちに専用の『合成レイヤー（Composited Layer）』に切り出しておけ」という命令を送るものだ。
これによって、その要素の再描画（Repaint）や変形（Transform）が、メインスレッドの負担を避けて、GPUによる合成処理だけで完結するようになる。確かにこれはパフォーマンスの劇的な向上をもたらす。しかし、ここには隠れたコストがある。
1. メモリ消費の急増: レイヤーはそれぞれGPUメモリを消費する。テクスチャの生成は見た目以上に負荷が高く、モバイル端末では数枚の巨大レイヤーを作成しただけでブラウザがクラッシュする、あるいは描画が極端に遅くなる現象が発生する。
2. レイヤー爆発のリスク: 不必要な要素をレイヤー化すると、ブラウザはそれらを管理するためのメタデータやバッファを大量に確保し続けなければならない。これが積もり積もると、スクロールのガタつき（Jank）を誘発する最大の要因となる。
—
実践的アーキテクチャ：`will-change`の正しい流儀
`will-change`を「常駐」させるのは愚策だ。本来、レイヤー化は「必要な瞬間だけ」行うのが鉄則である。
1. ホバーやアクティブ時に動的に適用する
最も安全なアプローチは、CSSで永続的に指定するのではなく、JavaScriptやCSSの疑似クラスで「変化の直前」にのみ付与することだ。
/ 普段は何も設定しない /
.card {
transition: transform 0.3s ease;
}
/ 変化の直前にブラウザにヒントを与える /
.card:hover {
will-change: transform;
}
2. JavaScriptでの動的制御（推奨）
もし複雑なアニメーションを制御するなら、JavaScriptで制御するのが最も堅牢だ。アニメーション開始時に`will-change`を付与し、終了後に削除する。これでメモリリークを防ぐ。
const element = document.querySelector(‘.target’);
// アニメーション開始時に最適化を指示
element.style.willChange = ‘transform, opacity’;
element.addEventListener(‘transitionend’, () => {
// 終了したら必ず解除する（これが重要！）
element.style.willChange = ‘auto’;
}, { once: true });
—
なぜ「副作用」が生まれるのか：スタッキングコンテキストの罠
`will-change`を使用すると、その要素は強制的に「スタッキングコンテキスト」を形成する。つまり、Z軸の重なり順が独立して管理されることになる。
もし、何百もの要素に`will-change`を付与した場合、ブラウザの合成器はこれらすべてのレイヤーの重なりを計算し続けることになる。これが「過剰使用によるレンダリングコストの増大」の正体だ。
上級者の知見:
デベロッパーツール（Chromeの`Layers`パネル）を必ず確認してほしい。画面上の要素に対して、意図しないほど多くのレイヤーが生成されていないか？もし「何でもない要素」が独立したレイヤーとして切り出されているなら、それはメモリをドブに捨てているのと同じだ。
—
まとめ：プロフェッショナルが守るべき3つの鉄則
1. 「とりあえず」は厳禁: `will-change`は、パフォーマンス計測の結果、明らかなボトルネックが確認された場合にのみ使用する。
2. 寿命を管理する: 常に適用するのではなく、変化の前後という限られた時間だけ適用するライフサイクルを設計する。
3. GPUメモリを意識する: モバイル端末の制約は厳しい。高解像度の画像や巨大なDOM要素に安易に適用すると、テクスチャ転送のボトルネックにより、むしろ描画が遅くなることを忘れてはならない。
ブラウザのエンジンは非常に優秀だが、万能ではない。我々エンジニアは、彼らが「どう計算しているか」を想像し、最短ルートを走れるように道筋を作るべきだ。それが、堅牢でキビキビと動くWebアプリケーションを作る唯一の道である。
さあ、エディタを開いて、君のアプリケーションのレイヤー構造を再確認してみよう。その「最適化」は、本当に最適か？
コメント