こんにちは。プロダクトのパフォーマンス改善で日々ブラウザの挙動と格闘している君なら、「なぜかこのアニメーションだけカクつくんだよな…」とDevToolsのパフォーマンスパネルを睨みつけた経験が一度はあるはずだ。
DOMをいじり、レイアウトを計算し、ペイントして画面にピクセルを落とし込む。この一連のパイプラインは非常にデリケートで、少しでもメインスレッドを重くすると、ユーザーはすぐに「モッサリしたUIだな」と感じ取る。
今回は、その描画のボトルネックを鮮やかに回避し、UIを60fps/120fpsの滑らかな世界へ導くための奥義――「GPUアクセラレーションとコンポジット（合成）」の裏側の仕組みについて、実務の現場目線で徹底的に解説しよう。
—
1. ブラウザの裏側で何が起きているのか？：レイアウト・ペイントから「コンポジット」へ
まず、ブラウザが画面を表示するまでのプロセスを簡単におさらいしておこう。
HTMLがパースされてDOMツリーができ、CSSが当たってCSSOMができ、それを合体させてレンダーツリーを作る。ここまでは基本だ。問題はその先にある。
1. Layout (Reflow): 各要素が画面上のどこに、どれくらいのサイズで配置されるかを計算する。
2. Paint: テキスト、色、影、境界線などのピクセル情報を実際のビットマップとして描き込む。
3. Composite: ペイントされた複数のレイヤー（層）を、正しい重なり順（Z-indexなど）で重ね合わせて最終的な画面を作る。
ここで重要なのは、「何もしなければ、すべての要素は単一の巨大なレイヤー（あるいは少数のレイヤー）として扱われる」という点だ。
もしアニメーションによって要素が1ピクセル動くだけで、ブラウザは「レイアウトの再計算」や「広範囲の再ペイント」をメインスレッドでやり直そうとする。これがカクつきの主原因だ。
GPUアクセラレーションの正体
ここで登場するのがGPUだ。特定の条件を満たした要素をブラウザが「独立したレイヤー（Compositing Layer）」に昇格させると、そのレイヤーの描画と移動の処理がCPU（メインスレッド）の手を離れ、GPUの専用プロセッサにオフロードされる。
GPUは並列処理の化け物だ。テクスチャ（レイヤーの画像データ）をVRAM（ビデオメモリ）に保持し、それを移動させたり（translate）、拡大縮小したり（scale）、透明度を変えたり（opacity）する合成処理を、メインスレッドをブロックすることなく高速に実行できる。これが「GPUアクセラレーション」の正体だ。
—
2. `transform` と `will-change` の正しいお作法
では、どうやってブラウザに「この野郎を独立したレイヤーに昇格させろ」と指示するのか。
昔はよく `transform: translate3d(0, 0, 0)` や `backface-visibility: hidden` といった、いわゆる「GPUハック」が使われていた。古いブラウザで強制的にGPUレイヤーを作らせるための泥臭いハックだが、現在のモダンブラウザでは、よりセマンティックでスマートな方法が用意されている。それが `will-change` プロパティだ。
`will-change` の使い方と注意点
`will-change` は、「将来的にこのプロパティが変更される予定だから、事前にブラウザ側で最適化の準備（レイヤーの独立化など）をしておいてくれ」と伝える宣言だ。
.modal-dialog {
/ 開閉アニメーションでtransformとopacityが変わることを事前に予告 /
will-change: transform, opacity;
}
しかし、ここでシニアとして強く釘を刺しておきたい。「とりあえず全部の要素に `will-change` を書け」というのは最悪のアンチパターンだ。
メモリ消費のトレードオフ（VRAM爆食いの罠）
GPUレイヤーを作るということは、ブラウザはその要素を「独立した画像（テクスチャ）としてVRAMに常時保持する」ことを意味する。
もし画面上の無数のカードやアイコンに `will-change` を乱用するとどうなるか？
ブラウザ（特にモバイルや低スペック端末）のVRAMはあっという間に枯渇する。メモリが足りなくなると、最悪の場合はタブがクラッシュするか、逆にスワップが発生してパフォーマンスが劇的に悪化するという本末転倒な事態に陥る。
鉄則:
- 「今まさにアニメーションしている最中の要素」や、「ユーザーがホバー・クリックした瞬間にインタラクティブに動くことが確実な要素」に限定して適用する。
- アニメーションが終わったら（あるいは不要になったら）、JavaScriptで動的に `will-change: auto` に戻すのが理想的な設計だ。
—
3. 実践：レイヤーを独立させて極上のモーダルアニメーションを作る
百聞は一見にしかず。現場でそのまま使える、GPUアクセラレーションを意識したクリーンなモーダルのサンプルコードを見てみよう。
HTML
CSS
/ 背景のオーバーレイ：opacityのみをアニメーションさせる /
.modal-backdrop {
position: fixed;
inset: 0;
background-color: rgba(0, 0, 0, 0.5);
display: flex;
align-items: center;
justify-content: center;
/ 初期状態は非表示（opacityとvisibilityで制御） /
opacity: 0;
visibility: hidden;
transition: opacity 0.3s ease, visibility 0.3s ease;
z-index: 1000;
}
/ モーダル本体：レイアウトプロパティ（topやleft）ではなく、transformを使用する /
.modal-content {
background: #ffffff;
padding: 2rem;
border-radius: 8px;
width: 90%;
max-width: 500px;
/ 初期状態は少し下にオフセットし、透明にしておく /
opacity: 0;
transform: translateY(20px) scale(0.95);
/ 複合的なトランジションの設定 /
transition: transform 0.3s cubic-bezier(0.16, 1, 0.3, 1), opacity 0.3s ease;
}
/ アクティブ状態のクラスが当たったとき /
.modal-backdrop.is-open {
opacity: 1;
visibility: visible;
}
.modal-backdrop.is-open .modal-content {
opacity: 1;
/ 位置とスケールを元に戻す。GPU処理対象なので滑らかに動く /
transform: translateY(0) scale(1);
}
/
【重要】アニメーション実行中の要素に対してのみ、
あるいはホバーなどのインタラクション前にwill-changeを付与する。
/
.modal-backdrop.is-animating .modal-content {
will-change: transform, opacity;
}
JavaScript
const backdrop = document.getElementById(‘modalBackbackdrop’);
const closeBtn = document.getElementById(‘closeBtn’);
// モーダルを開く関数
function openModal() {
// 1. アニメーション開始前にwill-changeを効かせるためのクラスを付与
backdrop.classList.add(‘is-animating’);
backdrop.classList.add(‘is-open’);
// 2. トランジション完了後にwill-changeを解放してVRAMを解放する
const handleTransitionEnd = () => {
backdrop.classList.remove(‘is-animating’);
backdrop.removeEventListener(‘transitionend’, handleTransitionEnd);
};
backdrop.addEventListener(‘transitionend’, handleTransitionEnd);
}
// モーダルを閉じる関数
function closeModal() {
backdrop.classList.add(‘is-animating’);
backdrop.classList.remove(‘is-open’);
const handleTransitionEnd = () => {
backdrop.classList.remove(‘is-animating’);
backdrop.removeEventListener(‘transitionend’, handleTransitionEnd);
};
backdrop.addEventListener(‘transitionend’, handleTransitionEnd);
}
// 実際のアプリではトリガーボタンからopenModal()を呼び出してください
このコードのポイント
1. `top` や `left`、`width` や `height` をアニメーションさせていない: これらを動かすと毎フレーム「Layout (Reflow)」が走り、メインスレッドが悲鳴を上げる。代わりに `transform` と `opacity` のみに絞っているため、LayoutとPaintがスキップされ、Compositeフェーズだけでアニメーションが完結する。
2. `will-change` のライフサイクル管理: JavaScript側で `transitionend` イベントを監視し、アニメーションが終わったら `is-animating` クラスを剥がして `will-change` を外している。これにより、VRAMの無駄遣いを防ぐというプロフェッショナルなメモリ管理を実現している。
—
4. デバッグの极意：DevToolsを使い倒せ
「本当にこの要素はGPUレイヤーになっているのか？」
それを自分の目で確かめるために、Chrome DevToolsの機能を使いこなそう。
1. DevToolsを開き、`Cmd + Shift + P`（Windowsは `Ctrl + Shift + P`）でコマンドパレットを開く。
2. `Show Layers` と入力し、レイヤーパネルを表示する。
3. 3Dビューで、現在のページがどの要素ごとにレイヤー分割されているかを視覚的に確認できる。
4. また、モーダルを開閉したときに、余計な領域がペイントされていないかを確かめるために、Renderingタブから 「Paint flashing」 にチェックを入れてみるのもおすすめだ。緑色に光るエリアが狭ければ狭いほど、ブラウザの負荷は低い。
—
まとめ
フロントエンドにおけるパフォーマンスチューニングは、魔法の呪文を唱えて万事解決とはいかない。ブラウザのレンダリングパイプラインを正しく理解し、「CPUに何をさせ、GPUに何を肩代わりさせるか」をロジカルに設計することが求められる。
- アニメーションには `transform` と `opacity` を使う（Layout/Paintの発生を防ぐ）。
- `will-change` はここぞというピンポイントで使い、終わったら解放する（VRAM枯渇を防ぐ）。
この基本原則をチームメンバーと共有し、ユーザーにストレスフリーで吸い付くようなUI体験を提供しよう。さて、次のチケットに取り掛かるとしようか。
コメント