ブラウザという「ブラックボックス」を解体する：DevTools Performanceタブで深淵を覗く
フロントエンドエンジニアが「なんとなく重い」という感覚でパフォーマンスを語るのは、もう卒業しよう。ブラウザは魔法をかけているわけではない。それは極めて冷徹な計算機であり、我々が書いたコードを血眼になって解釈し、ピクセルに変換しているだけだ。
今日は、Chrome DevToolsのPerformanceタブという「外科手術のメス」を手に、ブラウザのメインスレッドで何が起きているのか、その深淵を覗いていく。
—
1. Flame Chartの「壁」を読み解く：Main Threadの静寂と喧騒
Performanceタブを開いたとき、最初に目に入るFlame Chart。多くのエンジニアは「赤いバーが長いな」と直感的に感じるだろう。だが、プロの視点は違う。我々が注目すべきは、「誰がメインスレッドを占有し、どのタスクが他の処理を遮断しているか」だ。
Flame Chartの縦軸はコールスタック、横軸は時間だ。ここで最も恐ろしいのは、長い `Task` がメインスレッドを独占し、ユーザーの入力を受け付けない「ジャンク（Jank）」状態だ。
ボトルネック特定のための思考プロセス
1. Long Tasksを探せ: 50msを超えるタスクは、ユーザー体験を損なう「悪」だ。
2. Bottom-Upタブを活用せよ: Flame Chartで特定したタスクを選択し、「Bottom-Up」タブを見る。どの関数が時間を食っているか、Self Time（その関数自身が消費した時間）をソートすれば、犯人は一発でわかる。
3. Recalculate Styleの罠: `Recalculate Style` が頻発しているなら、DOMの不必要な変更や、頻繁すぎるクラスの付け替えを疑え。
—
2. Layout（Reflow）という名の重罪を追う
ブラウザにとって、DOMとCSSOMを統合して「どこに何を置くか」を計算するLayoutは、最も重い処理の一つだ。特に、JavaScriptからDOMのサイズや位置（`offsetHeight` や `getBoundingClientRect()` など）を読み取ろうとする行為は、ブラウザに「強制同期レイアウト（Forced Synchronous Layout）」を強いることになる。
悪い例：レイアウト・スラッシング（Layout Thrashing）
// これは最悪のパターン。読み取りと書き込みが交互に発生している
const boxes = document.querySelectorAll(‘.box’);
for (let i = 0; i < boxes.length; i++) {
// 読み取り（Layoutを強制）
const height = boxes[i].offsetHeight;
// 書き込み（再計算を誘発）
boxes[i].style.height = `${height + 10}px`;
}
これを解決するには、読み取りと書き込みをフェーズごとに分離するのが鉄則だ。`requestAnimationFrame` を使い、読み取りを先に完了させ、その後にまとめて書き込む。これがブラウザのパイプラインに逆らわない、唯一の解法だ。
—
3. PaintingとCompositing：GPUへのバトンパス
Layoutが終わってもまだ終わりではない。その情報をビットマップデータに変換する `Paint`、そしてそれらを重ね合わせて画面に表示する `Composite` がある。
ここで重要なのは、「Composite Only」なプロパティを使うことだ。
- `transform` と `opacity` は、ブラウザが `Compositor Thread` に処理を委譲できる数少ないプロパティである。
- これらを使えば、メインスレッドが重い処理をしていても、アニメーションは滑らかに動く。逆に、`box-shadow` や `filter` をアニメーションさせると、メインスレッドのPaintタスクを巻き込み、パフォーマンスは一気に崖を転がり落ちる。
実践：GPU加速を確実にするヒント
.target {
/ これを指定すると、専用のLayerが生成され、GPUで合成される /
will-change: transform;
}
ただし、`will-change` は諸刃の剣だ。乱用すればブラウザのメモリを食いつぶし、逆にレンダリングを遅くする。必要な時にだけ、一時的に付与するのが賢いアーキテクトのやり方だ。
—
4. なぜ「非同期」が時に裏切るのか
現代のWebアプリでは `Promise` や `setTimeout` を多用するが、これらもまたメインスレッドのタスクキューに並ぶ。どれだけ非同期処理を駆使しても、結局「実行」されるのはメインスレッドだ。
もし、非同期のコールバックの中で重いDOM操作を行えば、それは即座にメインスレッドをブロックする。
プロの教訓：
「非同期だから安全」と考えるな。メインスレッドは常に、「今この瞬間に実行すべきタスク」を順番待ちしている。その列に「重い処理」を割り込ませないこと。それが、Webアプリケーションを極限まで高速化する鍵だ。
—
最後に：計測なき最適化は「ただの勘」である
ブラウザのレンダリングパイプラインを理解することは、エンジニアとしての武器になる。しかし、最も重要なのは、常にPerformanceタブで計測し、事実に基づいて仮説を立てることだ。
Chrome DevToolsは、ブラウザ内部で起きていることの「ヒント」をすべて与えてくれている。あとは、そのヒントをどう読み解き、いかにブラウザの負荷を減らすコードを書くか。その泥臭い試行錯誤の先にこそ、ユーザーを感動させる「ヌルサク」の体験が存在する。
さあ、エディタを閉じたら、まずは本番環境のプロファイルを録画することから始めよう。そこには、君の知らない「ボトルネック」が隠れているはずだ。
コメント