爆速アニメーションの秘密兵器！ `will-change` プロパティでブラウザの「心」を掴む方法

おい、諸君。フロントエンド開発、お疲れ様。今日もブラウザのレンダリングパイプラインと格闘してるか？いや、格闘というより、まるで泥沼にハマってるかのような感覚に陥ることもあるだろう。特に、アニメーション周りのパフォーマンスチューニングには頭を悩ませているんじゃないか？

今回は、そんな君たちに、ブラウザの「心」を掴み、アニメーションパフォーマンスを劇的に向上させるための強力な武器、`will-change` プロパティについて、現場のリアルを交えながら、これでもかと掘り下げていこうと思う。公式ドキュメントのコピペじゃ絶対に出てこない、俺たちの現場で培われた知見を惜しみなく伝授するぞ。

そもそも、ブラウザのレンダリングって何が大変なの？

まず、`will-change` の話に入る前に、ブラウザがどうやって画面に絵を描いているのか、その裏側を軽くおさらいしておこう。これが分かっていないと、`will-change` のありがたみも半減してしまうからな。

ブラウザは、HTML、CSS、JavaScriptを受け取って、最終的にピクセルに変換して画面に表示する。この一連のプロセスは、大きく分けていくつかのステップを踏む。

1. パース (Parsing): HTMLとCSSのコードをブラウザが理解できるデータ構造（DOMツリー、CSSOMツリー）に変換する。
2. スタイル計算 (Style Calculation): DOMツリーとCSSOMツリーを組み合わせて、各要素に最終的に適用されるスタイルを決定する。
3. レイアウト (Layout) / リフロー (Reflow): 要素のサイズや位置を計算する。これが「リフロー」だ。要素のサイズや位置が変わると、その要素だけでなく、影響を受ける他の要素も再計算する必要が出てくる。これが一番コストが高い処理の一つなんだ。
4. ペイント (Paint) / リペイント (Repaint): 要素の見た目（色、背景、影など）をピクセルデータとして描画する。これが「ペイント」だ。リフローが発生すると、影響を受けた要素は「リペイント」される。
5. コンポジット (Composite): 複数のレイヤー（描画された要素の断片）を重ね合わせて、最終的な画面を生成する。GPUが使われることが多い、比較的軽い処理だ。

君たちがよく遭遇するパフォーマンス問題の多くは、この「リフロー」と「リペイント」の頻発に起因している。特に、アニメーションで要素の位置やサイズを頻繁に変更すると、ブラウザは「あっちこっち」でリフローやリペイントを繰り返す羽目になる。これが、カクつきの原因だ。

`will-change` はブラウザへの「予言」だ！

さて、そこで登場するのが `will-change` プロパティだ。これは、開発者がブラウザに対して、「おい、この要素、これからアニメーションさせるから、ちょっと準備しておいてくれよ！」と事前に「予言」するためのプロパティなんだ。

具体的には、`will-change` を指定された要素は、ブラウザによって 「レイヤー化」 される可能性が高まる。レイヤー化とは、画面上の要素を独立した描画レイヤーとして扱うことだ。

なぜレイヤー化が重要か？それは、コンポジットのステップで真価を発揮するからだ。

レイヤー化されていない要素: アニメーションで位置やスタイルが変更されると、その要素を含む親のレイヤー全体が再計算（リフロー、リペイント）される可能性がある。
レイヤー化された要素: アニメーションで変更されるのは、その要素自身のレイヤーだけ。他のレイヤーには影響が少ない。ブラウザは、GPUを使ってそのレイヤーだけを高速に合成（コンポジット）できる。

つまり、`will-change` は、ブラウザに「この要素は独立したレイヤーとして扱って、アニメーションの準備をしておいてね」と指示することで、リフローやリペイントのコストを最小限に抑え、コンポジット処理を高速化しようとする最適化手法なんだ。

`will-change` の具体的な使い方と注意点

`will-change` は、CSSプロパティとして指定する。主に、アニメーションで変更されるプロパティを指定する。

/ 要素を特定して、これから transform をアニメーションさせるぞ、とブラウザに伝える /
.animated-element {
will-change: transform;
}

/ opacity も一緒にアニメーションさせるなら、カンマで区切って複数指定できる /
.another-animated-element {
will-change: transform, opacity;
}

/ 全てのプロパティが変更される可能性があるなら、’auto’ も使えるが、これは最終手段 /
.wild-card-element {
will-change: auto;
}

`will-change` を使うべき時、そして使うべきでない時

ここで、君たちが一番知りたいであろう「いつ使うべきか」について、俺の経験則を交えて話そう。

使うべき時:

CSS Transitions や Animations で、`transform` や `opacity` を頻繁にアニメーションさせる場合: これが `will-change` の最も効果的な使いどころだ。特に、要素の移動（`translate`）や回転（`rotate`）、拡大縮小（`scale`）といった `transform` 系プロパティは、レイアウトに影響を与えずに描画コストを比較的抑えられるため、レイヤー化との相性が抜群だ。
JavaScript で `requestAnimationFrame` を使って、`transform` や `opacity` をリアルタイムで更新する場合: こちらも同様に、コンポジット処理の最適化が効きやすい。
アニメーションが開始される「直前」に `will-change` を追加し、アニメーション終了後に削除する場合: これは、パフォーマンスへの影響を最小限にしつつ、アニメーションの滑らかさを最大限に引き出すための「神業」とも言えるテクニックだ。後で具体的なコード例を見せる。

使うべきでない時:

レイアウト（`width`, `height`, `margin`, `padding`, `top`, `left` など）を変更する場合: これらのプロパティは、リフローを引き起こしやすい。`will-change` でレイヤー化しても、根本的なリフローのコストは避けられない。むしろ、不要なレイヤーを作成してメモリを圧迫するだけになる可能性もある。
アニメーションが頻繁でない、あるいは一度しか発生しない場合: `will-change` を指定すると、ブラウザは「予備的なレイヤー化」を行う。これは、ある程度のメモリと処理コストを必要とする。頻繁に使わないものにまでこれを適用すると、かえってパフォーマンスを悪化させる可能性がある。
要素が画面外にスクロールされた後も `will-change` を付けっぱなしにする場合: これもメモリの無駄遣いだ。スクロールされて見えなくなった要素にまでレイヤー化されたままでは、メモリを圧迫するだけ。
「とりあえず」で何にでも使う場合: これは絶対にやめろ。`will-change` は諸刃の剣だ。無闇に使えば、パフォーマンスの悪化を招く。

実践！ `will-change` を効果的に使うためのコード例

理論は分かっただろう。じゃあ、現場でどう使うのか、具体的なコードを見せていくぞ。

例1：基本的な `transform` アニメーションの最適化

まずは、シンプルな例から。要素を横に移動させるアニメーションだ。

will-change transform Example

will-change: transform の例

このコードでは、`.animated-box` に `will-change: transform;` を指定している。これにより、ブラウザは `.animated-box` を独立したレイヤーとして扱おうとし、`transform` プロパティの変更（`translateX`）によるアニメーションが、よりスムーズに、そして低リソースで実行されるようになる。

ポイント:

`will-change: transform` は、`transform` プロパティの変更によるアニメーションに特化して最適化を促す。
`opacity` も同様に `will-change: opacity` で最適化できる。
`transform` と `opacity` は、レイアウトに影響を与えにくいため、`will-change` との相性が非常に良い。

例2：JavaScript で動的に `will-change` を追加・削除するテクニック

先ほども触れたが、`will-change` はアニメーションが始まる「直前」に追加し、終わったら「削除」するのが最も効果的だ。これにより、不要なレイヤー化によるリソース消費を防げる。

Dynamic will-change Example

JavaScript で動的に will-change を操作

解説:

1. `will-change` の追加: ボタンがクリックされ、アニメーションが始まる直前に `square.style.willChange = ‘opacity, transform’;` で `will-change` を設定します。これにより、ブラウザは `opacity` と `transform` の変更に備えて、要素をレイヤー化する準備をします。
2. アニメーションの開始: `fade-and-move` クラスを追加し、CSS Transition を発火させます。同時に `opacity` と `transform` の値を変更します。
3. `will-change` の削除: `transitionend` イベントリスナーを使って、CSS Transition が完了したタイミングを検知します。トランジションが終了したら、`square.style.willChange = ‘auto’;` (または `”`) で `will-change` を解除します。`’auto’` は、ブラウザにレイヤー化の最適化を任せるデフォルト値のようなものです。
4. リセット: リセットボタンでは、要素のスタイルを初期状態に戻します。

なぜ `transitionend` を使うのか？
JavaScript で `setTimeout` を使って `will-change` を削除しようとすると、ブラウザの描画タイミングによっては、Transition が完了する前に `will-change` が削除されてしまい、最適化の効果が得られない可能性があります。`transitionend` イベントは、CSS Transition が実際に完了したことを保証してくれるため、より確実な方法です。

`{ once: true }` の重要性:
`addEventListener` の第二引数に `{ once: true }` を指定することで、イベントリスナーは一度だけ実行された後に自動的に削除されます。これにより、同じイベントが複数回発生しても、意図しない動作を防ぐことができます。

まとめ：`will-change` は「適切に」使えば最強の武器

さて、ここまで `will-change` プロパティについて、その仕組みから実践的な使い方までを解説してきた。

`will-change` は、ブラウザに「この要素はこれからアニメーションするぞ！」と事前に知らせ、レイヤー化を促すことで、特に `transform` や `opacity` のアニメーションパフォーマンスを向上させる。
レイヤー化された要素は、GPUによるコンポジット処理が高速化される。
使うべき時は、頻繁に `transform` や `opacity` をアニメーションさせる場合。
使うべきでない時は、レイアウト変更、頻繁でないアニメーション、要素が画面外にある場合など。
JavaScript で動的に追加・削除することで、パフォーマンスへの影響を最小限にしつつ、効果を最大限に引き出せる。

`will-change` は、まさにブラウザのレンダリングパイプラインの深層を理解し、その挙動を先読みして最適化するための強力なツールだ。しかし、その強力さゆえに、「適切に」使うことが何よりも重要だ。無闇に使えば、かえってパフォーマンスを悪化させ、メモリを圧迫するだけの「お邪魔キャラ」になりかねない。

君たちには、この `will-change` という武器を、その特性を理解した上で、賢く、そして大胆に使ってほしい。そうすれば、ユーザーを魅了する、滑らかでレスポンシブなアニメーションを、自信を持って実装できるようになるはずだ。

さあ、今日の話はここまでだ。早速、君たちのプロジェクトで試してみてくれ。何か分からないことがあれば、いつでも声をかけてくれ。俺が、君たちのコードに命を吹き込む手助けをしよう。健闘を祈る！

【実務・中級編】 will-changeプロパティの最適化 – Webブラウザの仕組み実践ガイド