フロントエンドの戦場で、数多のパフォーマンス・チューニングという名の「泥仕合」を潜り抜けてきた諸君なら、一度は壁にぶつかったことがあるはずだ。
「なぜ、JavaScriptの処理を極限まで削ったはずなのに、スクロールが引っかかるのか？」
「なぜ、アニメーションがiPhoneでは滑らかなのに、特定のAndroid端末ではガクつくのか？」
その答えは、メインスレッドの向こう側――「コンポジタースレッド（Compositor Thread）」という、ブラウザエンジンの深淵にある。今日は、多くのエンジニアが見過ごしがちな、しかしWebアプリケーションの「生命線」とも言えるコンポジタースレッドの役割と、その限界値について、アーキテクチャの観点から深く掘り下げていこう。
—
1. メインスレッドという名の「過密都市」
ブラウザのメインスレッドは、常にパンク寸前の過密都市だ。DOMの構築、CSSの解析、JavaScriptの実行、そして悪名高き「Layout（リフロー）」と「Paint（リペイント）」。これらすべてが、たった一つのスレッドで順番待ちをしている。
ここで想像してほしい。JavaScriptで巨大なJSONをパースしている最中に、ユーザーが画面をスクロールしようとしたらどうなるか。メインスレッドがJavaScriptに占有されていれば、スクロールの描画処理は後回しにされ、ユーザーは不快な「カクつき（Jank）」を感じることになる。
この絶望的な状況を打破するために設計されたのが、コンポジタースレッドだ。
2. コンポジタースレッド：独立独歩の演出家
コンポジタースレッドの最大の使命は、「メインスレッドがどんなに忙しくても、ユーザーの操作（スクロールやアニメーション）に対して即座に応答を返すこと」にある。
レンダリングパイプラインにおいて、メインスレッドが「何を描くか（Paint）」を決定した後、その情報は複数の「レイヤー」に分割され、コンポジタースレッドに渡される。コンポジタースレッドは、これらのレイヤーをGPUメモリ上に展開し、最終的な画面として「合成（Composite）」する。
特筆すべきは、スクロール処理の多くは、現在、コンポジタースレッドだけで完結できるという点だ。メインスレッドが無限ループで固まっていても、スクロールだけはスルスルと動く。これが現代のブラウザが魔法のように滑らかに動く正体だ。
アーキテクチャの急所：Fast Scrollable Region
コンポジタースレッドは、画面のどの領域が「JavaScriptの介入（`wheel`や`touchstart`のイベントリスナー）なしでスクロールできるか」を把握している。これを Fast Scrollable Region と呼ぶ。ここにイベントリスナーを不用意に設置すると、コンポジタースレッドは「JavaScriptが何かするかもしれないから、メインスレッドの返事を待とう」と判断し、せっかくの独立性を放棄してしまう。
これが、我々が `passive: true` を親の仇のように唱え続ける理由だ。
// 悪い例：メインスレッドの返信を待つため、スクロールがブロックされる可能性がある
window.addEventListener(‘touchstart’, (e) => {
// 何らかの処理
});
// 良い例：コンポジタースレッドに「スクロールは止めないから先に進めてくれ」と伝える
window.addEventListener(‘touchstart’, (e) => {
// 何らかの処理
}, { passive: true });
3. 「レイヤー」という名の劇薬
コンポジタースレッドの恩恵を最大限に受けるには、要素を独立したレイヤー（GraphicsLayer）に格上げする必要がある。`transform: translateZ(0)` や `will-change: transform` を使うアレだ。
これを適用すると、その要素はメインスレッドの「Paint」の呪縛から解き放たれ、コンポジタースレッドがGPUの力を使って位置や不透明度を操作できるようになる。しかし、ここにはシニアエンジニアこそが陥る罠が潜んでいる。
メモリの爆発：Layer Explosion
レイヤー化された要素は、それぞれが「ビットマップ（テクスチャ）」としてGPUメモリに保存される。高解像度のディスプレイ（Retinaなど）では、このメモリ消費量は無視できない。
「アニメーションを滑らかにしたいから」といって、全ての要素に `will-change` を付与するのは、メモリ効率の観点からは自殺行為だ。メモリが枯渇すれば、ブラウザはレイヤーを破棄し始め、逆にパフォーマンスは著しく低下する。最悪の場合、タブがクラッシュする。
4. 実践：コンポジタースレッドを使い倒す最適化戦略
では、具体的にどのようなコードを書くべきか。コンポジタースレッドに「だけ」仕事をさせるための、極限のCSSアニメーションの例を見てみよう。
/
パフォーマンスの敗北者：
left/topを変更すると「Layout -> Paint -> Composite」の全工程が走る。
メインスレッドが忙しいと、アニメーションは即座にガタつく。
/
.bad-animation {
position: absolute;
top: 0;
transition: top 0.3s;
}
/
パフォーマンスの覇者：
transform/opacityのみを変更する場合、ブラウザは「Composite」のみで処理を完結できる。
メインスレッドをバイパスし、コンポジタースレッドとGPUが直接会話する。
/
.good-animation {
will-change: transform; / 必要な時だけ、事前にレイヤー化を促す /
transform: translateY(0);
transition: transform 0.3s cubic-bezier(0.4, 0, 0.2, 1);
}
重大なバグの回避：サブピクセル・レンダリングの罠
コンポジタースレッドで要素を動かす際、`transform` で移動させた要素のテキストが「ぼやける」現象に遭遇したことはないだろうか。これは、要素がレイヤー化された瞬間に、ブラウザがその要素を「一枚の画像」として固定し、その画像を拡大縮小・移動させるからだ。
これを防ぐには、「アニメーションの最終状態」で綺麗に描画されるようにレイヤーを構成する、あるいは `backface-visibility: hidden` でハードウェアアクセラレーションを明示的に制御するなどの泥臭い調整が必要になる。
5. 結論：アーキテクトとしての視点
コンポジタースレッドは、ブラウザが我々に与えてくれた「最後の聖域」だ。しかし、その聖域に土足で踏み入り、過剰なレイヤー生成や不適切なイベントリスナーで汚してはならない。
1. メインスレッドを解放せよ: `will-change` は魔法の杖ではない。コストを理解して使え。
2. Fast Pathを死守せよ: `transform` と `opacity` 以外のプロパティでのアニメーションは、現代のWeb標準では「負債」である。
3. ブラウザと対話せよ: Chrome DevToolsの「Layers」パネルや「Rendering -> Layer borders」を常に開き、自分のコードがブラウザの内部でどのようなレイヤー構造を生んでいるかを肉眼で確認しろ。
我々上級エンジニアの仕事は、単に動くコードを書くことではない。ブラウザという複雑怪奇なマシンの構造を理解し、そのポテンシャルを100%引き出すための「道筋」を作ることなのだ。
次にスクロール自慢のサイトを作るときは、ぜひコンポジタースレッドの鼓動を感じてみてほしい。そこにこそ、真のユーザー体験が宿っているのだから。
コメント