ブラウザのレイヤー化とGPUコンポジットの判断基準

合成レイヤーとは何か

ブラウザはページ全体を1枚の絵として毎フレーム塗り直しているわけではありません。レンダリングの最終段であるコンポジット（合成）では、ページを複数の合成レイヤー（compositing layer）に分割し、各レイヤーを独立したGPUテクスチャとして保持します。最終画面は、これらのテクスチャをGPU上で重ね合わせる（compose）だけで生成されます。段ごとの全体像は レンダリングパイプライン詳説 で扱っているので、本稿はどの要素がレイヤーに昇格するかと、そのコストと制御に焦点を絞ります。

合成レイヤーに分かれていることの効能は明快です。あるレイヤーの位置や不透明度だけが変わったなら、そのテクスチャの中身（ピクセル）は不変なので、ペイントもラスタライズもやり直さず、配置パラメータを変えて再合成するだけで済みます。これが transform / opacity のアニメーションが軽い根本理由です。

合成レイヤーへの昇格条件

要素がレイヤーへ昇格するかは、開発者が直接指定するものではなく、ブラウザが**発見的規則（heuristics）**で判定します。Chromium では概ね次のいずれかに該当すると専用レイヤーが割り当てられます。

・3D変換: transform に translateZ / translate3d / rotate3d など Z 軸を含む指定
・アニメーション対象: transform / opacity をコンポジタで動かしている要素
・will-change: transform / opacity を値に持つ will-change 指定
・特定要素: <video>, <canvas>, WebGL コンテキスト, 一部の <iframe>
・position: fixed / sticky（スクロール時に独立して動くため）
・重なりの都合: 既存レイヤーと z 順で重なる要素（後述のオーバーラップ）

歴史的には transform: translateZ(0) や backface-visibility: hidden を「ハック」として書き、強制的にレイヤー化する手法が広く使われました。現在はこの意図を表明する正規の手段として will-change が用意されています。

transform / opacity がメインスレッド外で動く理由

transform と opacity だけが特別扱いされるのは、これらがテクスチャの中身を変えない変換だからです。両者の値はペイント段が生成する描画命令リスト（display list）には焼き込まれず、プロパティツリーのノードとして別管理されます。合成時にこのノードの値（変換行列・α値）を読んで適用するため、値を差し替えるだけで反映でき、ペイントもラスタライズも不要です。

決定的なのは実行スレッドです。合成はコンポジタスレッドで駆動でき、メインスレッド（JS実行・スタイル計算・レイアウトが走る場所）から独立しています。

/* 良い：合成のみで完結。コンポジタスレッドで駆動され、JS が重くても滑らか */
.card { will-change: transform; }
.card:hover { transform: translateX(20px) scale(1.05); opacity: 0.85; }

/* 悪い：見た目は近いが left/width はレイアウト起点。毎フレーム メインスレッドが要る */
.card-bad:hover { left: 20px; width: 105%; }

なお、合成がコンポジタスレッドで完結するのは、合成を別プロセスのGPUプロセスに依頼する構造とも対応します。レンダラとGPUの分離は ブラウザのマルチプロセス・アーキテクチャ を参照してください。

レイヤー爆発のコスト

レイヤー化は無料ではありません。各レイヤーは専用のGPUテクスチャを持ち、その容量は実ピクセル数で決まります。

1レイヤーのVRAM ≒ 幅(px) × 高さ(px) × デバイスピクセル比^2 × 4バイト
例: 300×200 の要素を DPR 2 の画面で → 600×400×4 = 約 0.96 MB

レイヤーが増えると、(1) GPUメモリ消費が積み上がり、(2) 毎フレームの合成処理そのもの（重ね合わせるレイヤー枚数）が増え、(3) レイヤー管理のためのメインスレッド側の簿記も増えます。数十枚程度なら問題になりにくいですが、リストの全項目に will-change を当てるといった操作で数百〜数千枚に膨れると、メモリ圧迫とジャンクを招きます。これが**レイヤー爆発（layer explosion）**です。

will-change の正しい使い方

will-change は、これから変化するプロパティを事前にブラウザへ伝え、変化が始まる前にレイヤー昇格やテクスチャ確保を済ませてもらうためのヒントです。要点は短命に使うことに尽きます。

/* 悪い：常時昇格。動いていなくてもレイヤーを確保し続ける */
.item { will-change: transform; }

// 良い：動く直前に付け、アニメーションが終わったら外す
el.addEventListener('pointerenter', () => {
  el.style.willChange = 'transform';     // 直前に昇格を予約
});
el.addEventListener('transitionend', () => {
  el.style.willChange = 'auto';          // 終わったら解放してレイヤーを返す
});

実務指針は次の通りです。

• 対象を transform / opacity に限る：これら以外の will-change（例 width）は合成で完結せず、ヒントの旨みが薄い。
• 指定数を絞る：同時にアニメーションする少数要素にだけ当てる。「全部に予防的に」は禁物。
• 付けたら外す：JSで動的に付与し、transitionend / animationend で auto に戻してレイヤーを解放する。
• 実測で確かめる：DevTools の Layers パネルでレイヤー枚数とメモリを、Rendering の Layer borders で昇格範囲を可視化する。

まとめ