フロントエンドエンジニアとしてある程度経験を積んでくると、一度はぶち当たる壁がある。
「アニメーションをガシガシ動かしていると、なぜかスマホ端末でスクロールがカクつく」「CPU使用率が跳ね上がってファンが回り出す」。
この手のパフォーマンス問題に直面したとき、ネットの海を漂うと「とりあえず `will-change: transform` を書け」という呪文のようなアドバイスが無数に出てくる。
だが、ちょっと待ってほしい。その魔法の呪文、本当にどういう仕組みで動いているか理解して使っているかい？
今回は、ブラウザの心臓部である「レンダリングエンジン」と「GPU」の裏側の世界に踏み込み、合成レイヤーがどのように生まれ、そして私たちのVRAM（GPUメモリ）をどう食い潰していくのか、現場のリアルな視点から徹底的に解剖していこう。
—
1. ブラウザの裏側で何が起きているのか？ DOMから合成レイヤーへの道
まず、ブラウザが画面を表示するまでの大まかなフローを復習しておこう。HTMLをパースしてDOMを作り、CSSを当ててCSSOMを作り、そこから「レンダーツリー」を構築する。ここまでは基本だ。
問題はその先、「レイアウト（ペイント）」と「合成（Compositing）」のフェーズだ。
昔のブラウザは、Webページ全体をまるで1枚のキャンバスのように捉え、すべてをCPUでガリガリとピクセル単位で描画（ペイント）していた。だから、小さな要素が1つ動くだけで、画面全体の大部分を再描画（リペイント）しなければならず、メインスレッドが悲鳴を上げていた。
そこで現代のブラウザは賢くなった。画面をいくつかの「層（レイヤー）」に分割し、それぞれを独立して処理する仕組みを取り入れたんだ。これが「合成レイヤー（Composited Layers）」だ。
GPUに仕事を奪う（オフロードする）ということ
合成レイヤーに昇格した要素は、ブラウザによって個別のテクスチャとして切り出され、GPUのVRAMへと送り込まれる。
GPUは並列処理の化け物だ。CSSの `transform`（移動・拡大縮小・回転）や `opacity`（透明度）の変更が起きたとき、GPUはこのテクスチャをそのまま「動かしたり、透かしたり」するだけでよくなる。
つまり、メインスレッド（JavaScriptの実行やスタイルの計算を行う場所）を一切ブロックせずに、60fps（あるいは120fps）の滑らかなアニメーションを実現できるというわけだ。これがGPUアクセラレーションの正体だ。
—
2. どんな条件で合成レイヤーは生成されるのか？
「じゃあ、すべての要素をレイヤーにしてしまえば最強じゃん！」と思ったそこのあなた。甘い、甘すぎる。
ブラウザが勝手にレイヤーを作ってくれる条件や、こちらから強制的にレイヤー化させる条件には、以下のようなものがある。
1. 3D系CSSプロパティの使用: `transform: translateZ(0)` や `transform: translate3d(…)`
2. `will-change` プロパティの指定: ブラウザに対して「これからこのプロパティ変わるから覚悟しといてね」と事前に宣言する
3. 特定のHTML要素やCSS効果:
- `
- `CSS Filters`（`blur()` や `drop-shadow()` など）
- `opacity` や `transform` を持つCSSアニメーション／トランジション（実行中のみレイヤー化することが多い）
- `position: fixed` や `sticky` を持つ要素（実装やブラウザのバージョンによる）
特に有名なのが、かつてパフォーマンスハックとして乱用された `transform: translateZ(0)` だ。これは「何も動かさなくていいから、とりあえずGPUにレイヤーを作らせてくれ」というブラウザへのハック（強制レイヤー昇格）だった。
`will-change` の正しい使い方
このハックの現代的な正当後継者が `will-change` だ。例えば、ホバー時に大きく拡大するカードコンポーネントがあるとする。
.card {
/ 通常時は普通のレイヤー /
transition: transform 0.3s ease;
}
.card:hover {
/ ホバー時にGPUアクセラレーションを有効化する /
transform: scale(1.05);
}
これだと、マウスカーソルが乗った「瞬間」にブラウザが慌ててレイヤーを生成するため、最初の1フレだけカクつく（レイヤー生成のコストが発生する）ことがある。そこで `will-change` の出番だ。
.card {
/ 「この要素は近いうちにtransformが変わるよ」とブラウザに事前にお告げをする /
will-change: transform;
transition: transform 0.3s ease;
}
.card:hover {
transform: scale(1.05);
}
これで、ブラウザは事前にGPU側へレイヤーの準備を済ませておくことができる。初動の引っかかりが綺麗に消えるというわけだ。
—
3. 【警告】GPUメモリの爆食いと「レイヤーの爆発」という悪夢
ここまで聞くと「じゃあ、サイト内の全要素に `will-change: transform` を貼っておけば万全だな！」と思うかもしれないが、それをやったら現場のインシデント案件として明日君の机にチャットが飛ぶことになる。
忘れてはならない。GPUのメモリ（VRAM）は無限ではない。 特にスマホ（iPhoneやAndroidのミドルレンジ帯）のVRAMは非常にシビアだ。
1つの合成レイヤーを作るということは、ブラウザはその要素のピクセルデータをGPUのメモリ上に保持し続けるということだ。
もし、ページ内の何百個もあるリストアイテムのすべてに `will-change` を仕掛けたらどうなるか？
- VRAMの枯渇: ブラウザがメモリを食いつぶし、最悪の場合タブがクラッシュする（「Aw, Snap!」の画面だ）。
- レイヤーの爆発（Layer Explosion）: メモリ管理のオーバーヘッドがかえってパフォーマンスを悪化させる。
- メモリ転送のボトルネック: DOMの変更に伴い、CPUからGPUへテクスチャデータを転送するバスの帯域が圧迫される。
「力づくの最適化は、しばしば最悪のバグを生む」。これがシニアの経験則だ。
—
4. 実務で使える！クリーンなコードと検証のベストプラクティス
では、実務において私たちはどう立ち回るべきか。具体的なコード例を見ていこう。
パターンA：インタラクティブなUI（ドロワーメニューやモーダル）
ユーザーが操作する直前、あるいはホバーする可能性が極めて高いものに絞って適用する。
ボトルネックの特定方法（Chrome DevToolsの使い方）
「なんとなく遅い気がする」でコードを書くのはプロ失格だ。必ずDevToolsで裏付けを取ろう。
1. Chromeで対象のページを開き、`F12` でDevToolsを開く。
2. コマンドメニュー（`Cmd + Shift + P` または `Ctrl + Shift + P`）を開き、「Show Layers」（レイヤーを表示）と入力して実行する。
3. 3Dビューで、どの要素がどのサイズでレイヤー化されているか、意図しない巨大なレイヤーが作られていないかを目視で確認する。
4. 「Rendering」タブを開き、「Paint flashing」（ペイントの点滅）や 「Layer borders」（レイヤーの境界）にチェックを入れて、スクロール時に不要な部分が再描画・レイヤー化されていないかをライブで監視する。
—
5. まとめ：シニアからのメッセージ
GPUアクセラレーションと合成レイヤーの生成は、フロントエンドのパフォーマンスチューニングにおける強力な武器だ。だが、それは同時に「諸刃の剣」でもある。
- 本当にアニメーションやスクロールが重い場所（ボトルネック）だけに絞って使うこと。
- 不要になったら（あるいは静的な状態に戻ったら）`will-change` を外しっぱなしにしないこと（※JSで動的に付与・削除するテクニックも有効だ）。
- 常にChrome DevToolsでレイヤー数とメモリ消費量を計測する習慣をつけること。
ブラウザの仕組みを正しくハックし、ユーザーに「まるでネイティブアプリのような滑らかな体験」を届けるのが、我々フロントエンド・スペシャリストの腕の見せ所だ。明日からのコードレビューでは、無駄な `will-change` が貼られていないか、ぜひ厳しくチェックしてみてほしい。
コメント