お疲れ様です。今日のコードレビューの前に、少しブラウザの裏側の話をさせてほしい。
実務でフロントエンドをやっていると、なぜか「スマホで特定のモーダルを開いた瞬間にカクつく」「無限スクロールのリストが重い」といったパフォーマンスの壁にぶぶつかることがあるよね。DevToolsのPerformanceタブを開いて、Main threadが真っ赤になっているのを見て頭を抱えた経験、誰しも一度はあるはずだ。
そのパフォーマンスチューニングの切り札として、私たちはよく `will-change: transform` や `translate3d(0, 0, 0)` といった「お呪い」を唱えてきた。でも、「なぜそのコードを書くとブラウザが軽くなるのか」、その内部メカニズムをGPUラスタライズの文脈から正確に説明できるだろうか？
今日は、CPUによる描画から、GPUによるハードウェアアクセラレーションへの移行プロセスという「ブラウザの裏側の真実」を、現場目線で徹底的に紐解いていこう。
—
1. そもそもブラウザは画面をどうやって作っているのか？
私たちが書いたHTML/CSSが画面にピクセルとして描き出されるまでには、長くてシビアなパイプラインが存在する。
ざっくりとおさらいしておこう。
1. DOM / CSSOMの構築: HTMLをパースしてDOMを作り、CSSをパースしてCSSOMを作る。
2. レンダーツリー構築 (Attachment): DOMとCSSOMを結合して、画面に表示すべき要素だけの「レンダーツリー」を作る。
3. レイアウト (Reflow): 各要素が「画面のどこに、どのサイズで配置されるべきか」を計算する。
4. ペイント (Paint): 「文字を描く」「背景に色を塗る」「ボーダーを引く」といった描画命令のリスト（レコード）を生成する。
5. 合成 (Composite): ペイントされた各レイヤーを画面上に合成し、最終的なピクセルとして画面に映し出す。
このパイプラインの中で、かつてはステップ1から4までの大部分をCPU（メインスレッド）が汗水垂らして一人でこなしていた。しかし、モダンなWebアプリでこれをやると、メインスレッドがパンクする。そこで登場するのがGPUによるラスタライズとハードウェアアクセラレーションだ。
—
2. CPU描画の限界と、GPUラスタライズへの移行プロセス
CPUがボトルネックになる理由
CPUは汎用的な計算の天才だが、何千、何万というピクセルを同時に塗りつぶす（ラスタライズする）ような「並列処理」はぶっちゃけ苦手だ。
例えば、複雑なアニメーションの最中にJavaScriptで重い処理が走ったり、DOMが再構築（Reflow）されたりすると、メインスレッドがブロックされる。すると、ペイントや合成の処理が遅れ、ユーザーのスクロールがカクつく（フレームレートが落ちる）という現象が起きる。
GPUラスタライズの救済
ここでGPU（Graphics Processing Unit）の出番だ。GPUは、数千ものコアを同時に動かして並列計算を行うモンスターマシーンだ。
ブラウザは、特定の条件を満たした要素をメインスレッドの支配下から切り離し、独立した「レイヤー（合成レイヤー / Compositing Layer）」に昇格させる。そして、そのレイヤーのラスタライズ（ベクター的な描画命令をピクセルデータに変換する処理）と合成の処理を、GPUに丸投げするのだ。これがGPUラスタライズの正体である。
一度レイヤーがGPUにアップロードされてしまえば、移動（Transform）や透明度（Opacity）の変更といったアニメーションは、メインスレッドを一切巻き込まずに、GPU上で爆速で処理される。これがハードウェアアクセラレーションの恩恵というわけだ。
—
3. 現場で使える！GPUレイヤーを強制生成する実践テクニック
「じゃあ、すべての要素をレイヤーにすればいいじゃん！」と思ったそこのあなた、それは大きな間違いだ。
GPUのVRAM（ビデオメモリ）には限りがある。何でもかんでもレイヤーに昇格させると（レイヤー爆発）、メモリを食いつぶし、かえってパフォーマンスが劣化するという「諸刃の剣」なのだ。
では、実務ではどう使い分けるべきか？
アニメーションやモーダルなど、「動かすことが確実なパフォーマンスクリティカルな要素」に対してのみ、意図的にGPUレイヤーを生成させるのがプロの技だ。
以下のコードを見てほしい。実務でよくある、滑らかにスライドインするドロワーメニューの実装例だ。
このコードのポイント（シニアからの解説）
1. `will-change: transform;` の正しい使い方
CSSにこれを書いておくと、ブラウザはレンダリングエンジン（BlinkやWebkitなど）のレイヤー化の判断を前倒しし、最初からGPU側でレイヤーを構築してスタンバイしてくれる。昔は `transform: translateZ(0)` や `backface-visibility: hidden` というハック（通称：GPUハック）が主流だったが、現在は仕様に沿った `will-change` を使うのがモダンなベストプラクティスだ。
※ただし、常時すべての要素に貼るのはメモリの無駄遣いなので、「動かす直前」や「インタラクティブなコンポーネント」に限定すること。
2. アニメーションさせるプロパティの厳選
CSSアニメーションを実装する際、`width`、`height`、`top`、`left` などを動かしていないだろうか？これらはブラウザにレイアウト（Reflow）とペイント（Repaint）を毎フレーム強制するため、CPUが悲鳴を上げる。
GPUラスタライズの恩恵を100%受けるためには、`transform`（移動・拡大縮小・回転）と `opacity`（透明度）の2つだけをアニメーションさせるのが鉄則だ。これらはレイアウトやペイントをバイパスし、合成（Composite）のフェーズだけで完結するため、驚異的な滑らかさを実現できる。
—
4. まとめ：ブラウザと会話できるエンジニアになろう
フロントエンドの仕事は、単にデザイン通りの見た目をコードに落とし込むことだけじゃない。その裏側で、ブラウザという限られたリソースの塊が、どれだけ必死にピクセルを計算し、画面を描き出しているか。その「仕組み」を想像できるかどうかが、ジュニアとシニアの分かれ道だ。
「なぜかこのアニメーションがカクつく」と思ったときは、DevToolsのLayersパネルを開いて、「今、どの要素がGPUレイヤーに昇格しているか？」を確認してみるといい。ブラウザの挙動が手に取るようにわかるはずだ。
明日からの実装では、ぜひ「GPUラスタライズとメインスレッドの関係」を意識して、CPUに優しい、ユーザー体験の滑らかなコードを書いていこう。
さて、それでは今日のコードレビューに戻るとしようか。何か質問があればいつでも聞いてくれ。
コメント