Webパフォーマンスにおける比例的推論
ボトルネックとは、絶対的なしきい値を超えるフェーズではなく、合計時間の中で最も大きな割合を占めるフェーズのことである。
Lighthouseは数値を教えてくれるが、その数値が問題かどうかまでは教えてくれない。各フェーズを全体のパーセンテージに変換しよう。最大のパーセンテージがあなたのボトルネックである。絶対的なしきい値を超えるフェーズではない。これによって、どの修正が実際にCore Web Vitalsを改善するかが変わってくる。
2026年3月にArjen Karelが最終レビュー
Table of Contents!
絶対的なしきい値の問題点
Lighthouseが「Render Delayが350msである」と報告したとする。これに対してどう対処すべきか？
合計のLCPが700msの場合、350msのRender Delayは問題の半分を占めている。それを修正すべきだ。
しかし、合計のLCPが4,200msでTTFBが3,800msの場合、350msのRender Delayは全体の8%に過ぎない。それをゼロに修正したところで、350msしか短縮されない。依然として3,850msのLCPが残り、不合格となる。問題の90%はサーバーにあるのだ。
コンテキストのない絶対数は無駄な努力を招く。パーセンテージに変換すれば、ボトルネックは明白になる。
最大のパーセンテージから修正する
LCPもINPも、いくつかのフェーズに分解される。各フェーズが全体の一部を消費している。最も大きな部分がボトルネックである。そこから修正しよう。
これは複雑なことではない。しかし、多くのパフォーマンスツール、さらにはAIエージェントでさえ、このステップをスキップし、固定のしきい値を超えるものを最適化しようとするのは驚くべきことだ。
LCPの例
モバイル製品ページのLCPが3,820ms（不良）だとする。実際のユーザーからのフェーズ内訳は以下の通り：
- TTFB: 420ms (11%)
- Load Delay: 2,100ms (55%)
- Load Time: 680ms (18%)
- Render Delay: 620ms (16%)
16%のRender Delayをゼロに修正すれば、620ms短縮できる。55%のLoad Delayの問題を修正すれば、2,000ms以上短縮できる。どちらも現実の問題だが、ボトルネックは1つである。
Load Delayが55%ということは、ブラウザがHTMLを受信したにもかかわらず、ヒーロー画像を2秒以上リクエストしなかったことを意味する。ブラウザは画像を見つけられないのだ。画像が、preload scannerが見つけられるHTML内に存在していない。preloadヒントを追加すれば、LCPをほぼ半分に減らすことができる。
INPの例
チェックアウトページのINPが350ms（改善が必要）だとする。フェーズ内訳は以下の通り：
- Input Delay: 70ms (20%)
- Processing: 80ms (23%)
- Presentation: 200ms (57%)
パーセンテージを考慮しなければ、エージェントは70msが何らかのしきい値を超えているという理由でInput Delayを最適化するだろう。パーセンテージを示せば、Presentationをターゲットにする。時間の57%がそこで費やされているからだ。
Presentation（巨大なDOM、CSS containmentの欠如、高負荷な再描画）を修正することで、INPは350msから200ms以下に改善する。これで「改善が必要」から「良好」に変わる。Input Delayを70msから0msに修正（あり得ないが、仮定として）しても、70msしか短縮されない。依然として280msで不合格となる。同じ労力でも、結果は異なる。
エージェントがこれをスキップするとどうなるか
比例的コンテキストを持たないAIエージェントは、ツールが指示した通りに行動する。Lighthouseが長いTBTを警告すれば、エージェントはTBTを最適化する。その変更は技術的には正しい。だが、TBTは問題の20%に過ぎず、57%のボトルネックは手つかずのままなので、現実世界での影響は最小限にとどまる。
私はAI生成のパフォーマンス修正でこのパターンを絶えず目にしている。修正は症状に対処するだけで、ボトルネックは残ったままである。フィールドデータは改善しない。開発者は、なぜ「正しい」最適化が何の効果ももたらさないのかと疑問に思うだろう。
片方のアプローチは時間を無駄にし、もう片方は実際の問題を解決する。
CWV Superpowersなしでこれを行う方法
手動で行うこともできる。LCPの場合：Chrome DevToolsを開き、パフォーマンス・トレースを実行して、タイムラインでLCPマーカーを見つけ、4つのフェーズを測定する。それぞれを合計LCPのパーセンテージに変換する。最も高いパーセンテージから修正する。
INPの場合：Web Vitals Chrome拡張機能、またはeventエントリタイプのPerformanceObserverを使用する。INPのインタラクションを記録し、3つのフェーズの所要時間を取得して、パーセンテージに変換する。
あるいは、CWV Superpowersに、単一のラボのトレースではなく、何千もの実際のセッションからのフィールドデータを使って、これを自動的に行わせることもできる。
