Webページのパフォーマンス指標は10種類近くあり、そのうち検索順位の評価に使われるのは3つだけです。残りは順位には直接使われないものの、その3つが悪化した原因を切り分けるために必要になります。この記事では、順位に効く指標と原因調査に使う指標を分けて整理し、それぞれの公式なしきい値と、症状ごとにどれを見ればよいかをまとめます。3指標そのものの基準と改善手順はコアウェブバイタルとは？3指標（LCP・INP・CLS）の基準と改善方法【2026年版】で個別に解説しているため、本記事が扱うのはその外側です。
まとめ：どの指標を、どの場面で見るか
- 検索順位の評価に使われるのは LCP・INP・CLS の3つ（Core Web Vitals）だけ。判定は実ユーザーの記録（フィールドデータ）の75パーセンタイル値で行われる。
- TTFB・FCP・TBT・Speed Index は順位の評価対象ではない。3指標が悪いときに、どこで時間を失っているかを特定するための指標として使う。
- FID は2024年3月に INP へ置き換えられ、Core Web Vitals から外れた。いま「LCP・FID・CLS」と書かれている解説は更新されていない。
- Lighthouse のパフォーマンススコアは TBT 30%・LCP 25%・CLS 25%・FCP 10%・Speed Index 10% の加重平均。90点は「ラボ環境の1回の測定が良好」という意味で、フィールドデータでの合格とは別物。
- CDN が効くのは TTFB と、それに引きずられる LCP まで。JavaScript の実行時間が原因の INP・TBT や、サイズ指定漏れによる CLS は CDN では動かない。
パフォーマンス指標の地図：フィールド指標とラボ指標
指標を覚える前に、測定方法が2系統ある点を押さえると混乱が減ります。フィールドデータは Chrome の実ユーザーから集めた実測の記録で、Google が検索の評価に使うのはこちら側です。ラボデータは決まった条件でツールが再現した測定値で、Lighthouse や PageSpeed Insights の「診断」欄がこれにあたります。
同じページでも両者の数値は一致しません。フィールドは回線もデバイスもばらばらな実ユーザーの分布であり、ラボは固定条件の1回分だからです。順位を気にする場面ではフィールド、原因を追う場面ではラボ、と目的で使い分けます。
| 指標 | 測定系統 | 良好の基準 | 主な用途 |
|---|---|---|---|
| LCP | フィールド／ラボ | 2.5秒以内 | 順位評価（Core Web Vitals） |
| INP | フィールドのみ | 200ミリ秒以内 | 順位評価（Core Web Vitals） |
| CLS | フィールド／ラボ | 0.1以内 | 順位評価（Core Web Vitals） |
| TTFB | フィールド／ラボ | 0.8秒以内 | サーバー応答の切り分け |
| FCP | フィールド／ラボ | 1.8秒以内 | 初回描画の切り分け |
| TBT | ラボのみ | 200ミリ秒未満 | INPの当たり付け |
| Speed Index | ラボのみ | 3.4秒以内 | 表示の進み方の確認 |
Core Web Vitals の3指標はいずれも、フィールドデータの75パーセンタイル値で判定されます。平均値ではないため、大半のユーザーが快適でも、下位25%が極端に遅ければ不合格です。
順位に使われる3指標の現在地とFIDの廃止
Core Web Vitals は LCP（読み込み）・INP（応答）・CLS（レイアウトの安定）の3つです。基準は LCP 2.5秒以内、INP 200ミリ秒以内、CLS 0.1以内で、モバイルとデスクトップは別々に評価されます。
2024年3月、応答性の指標が FID（First Input Delay）から INP（Interaction to Next Paint）へ入れ替わり、FID は Core Web Vitals から外れました。FID は最初の操作に対する「反応が始まるまでの遅延」しか測っておらず、操作してから画面が実際に描き変わるまでの時間は対象外でした。INP はページ滞在中のすべての操作について、入力から次の描画までを測り、その中で最も遅い部類の値を代表値に採ります。FID が良好でも INP が不合格になるサイトが出るのはこのためで、「FIDは通っていたはず」という感覚は現在の判定には使えません。
各指標の意味と改善手順はコアウェブバイタルの解説記事で個別にまとめています。3指標の判定方法（28日間・75パーセンタイル）とweb-vitals・CrUX APIでの計測コードはCore Web Vitalsとは：LCP・INP・CLSの基準値とweb-vitals・CrUX APIでの測り方で詳しく扱っています。ここから先は、この3指標が悪化した原因を探すための指標を扱います。
Core Web Vitals以外の指標：TTFB・FCP・TBT・Speed Index
TTFB：サーバー応答の速さがLCPの上限を決める
TTFB（Time to First Byte）は、リクエストからレスポンスの最初の1バイトが返るまでの時間です。良好は0.8秒以内、1.8秒を超えると不良とされます。Core Web Vitals には含まれませんが、TTFB は FCP や LCP より前段に位置するため、TTFB が1.5秒かかっていれば LCP が2.5秒を切る余地はほとんど残りません。LCP が不合格でフロント側の最適化を一通りやっても動かない場合は、まず TTFB を測るのが順序として正しい判断です。
逆に、TTFB そのものを0.8秒以内に収めること自体が目的ではありません。web.dev も、Core Web Vitals の達成を妨げていないなら TTFB の良好基準を必ず満たす必要はない、という立場を明示しています。
FCP：白い画面が終わるまでの時間
FCP（First Contentful Paint）は、ページに遷移してから最初のコンテンツ（テキスト、画像、SVG要素、白以外のcanvas）が描画されるまでの時間です。良好は1.8秒以内、1.8〜3.0秒が改善が必要、3.0秒超が不良で、モバイルとデスクトップを分けて75パーセンタイルで評価します。
FCP が遅いのに LCP との差が小さいなら、ボトルネックは主要コンテンツではなく初期表示までの経路（サーバー応答、レンダリングを妨げるCSSやJavaScript）にあります。FCP と LCP の差が大きい場合は逆に、最大要素になっている画像や動画の配信が原因です。
TBT：ラボでINPの当たりを付ける
TBT（Total Blocking Time）は、FCP 以降にメインスレッドが50ミリ秒を超えて占有された時間の合計です。平均的なモバイル端末で200ミリ秒未満が良好とされ、ラボ環境でしか測れません。
TBT は INP の代理指標として使われます。TBT が低ければ INP も低い傾向がありますが、web.dev は限界も明示しています。ラボでは実際の操作が発生しないため、ユーザーが操作しない時間帯の詰まりを問題として拾ってしまう一方、実際の操作で起きる遅延は取りこぼしがちです。応答性の本番判定はあくまでフィールドの INP で、TBT は原因のあたりを付ける道具と位置づけてください。
Speed Index：表示がどう進んだか
Speed Index は、ページ読み込みの様子を動画として記録し、フレーム間の視覚的な進み方から「コンテンツがどれだけ速く表示されていったか」を算出する指標です。モバイルでは3.4秒以内が良好、3.4〜5.8秒が改善が必要、5.8秒超が不良となります。ラボ専用の指標で、単一の時点ではなく表示の推移を見る点が他と異なります。LCP は良好なのに体感が遅いという食い違いがあるときに、途中経過が長く空白のままだったかどうかを確認する用途です。
Lighthouseスコアの内訳と、90点が意味しないこと
PageSpeed Insights などで表示されるパフォーマンススコアは、単独の測定値ではなく5指標の加重平均です。Lighthouse 10以降の重み配分を挙げます。
| 指標 | 重み |
|---|---|
| Total Blocking Time | 30% |
| Largest Contentful Paint | 25% |
| Cumulative Layout Shift | 25% |
| First Contentful Paint | 10% |
| Speed Index | 10% |
スコアの区分は0〜49が不良（赤）、50〜89が改善が必要（オレンジ）、90〜100が良好（緑）です。なお TTI（Time to Interactive）は Lighthouse 8 では10%の重みを持っていましたが、Lighthouse 10 で採点から外れました。TTI に言及している改善記事や社内資料は、現行の採点ロジックとずれています。
ここで踏み込んで言うと、スコア90点を目標に据える運用は勧めません。理由は2つあります。1つは、このスコアがラボ環境の1回の測定に基づく値で、順位の判定に使われるフィールドデータの75パーセンタイル値とは母集団が違うこと。もう1つは、重みの30%を占める TBT が順位の評価対象ではないことです。TBT を削ってスコアを85点から92点に上げても、フィールドの INP が200ミリ秒を超えたままなら評価は変わりません。優先すべきは Search Console の「ウェブに関する主な指標」レポートに出るフィールド値であり、Lighthouse のスコアはその原因を探すときに開く画面です。
症状別・見るべき指標の選び方
「サイトが遅い」という報告は、指標に分解すると別々の問題に分かれます。報告された症状から入るほうが、スコア画面を上から順に潰すより速く原因に届きます。
- クリックしてから何も出ない：TTFB。サーバー処理、リダイレクトの連鎖、キャッシュのミスを疑う。
- 白い画面が続く：FCP。レンダリングを妨げるCSSやJavaScript、Webフォントの読み込みを見る。
- 主要な画像や見出しだけ遅れて出る：LCP。最大要素の配信方法、画像形式、遅延読み込みの設定ミスを確認する。
- タップやクリックの反応が鈍い：フィールドの INP、ラボの TBT。長時間実行される JavaScript を分割する。
- 読んでいる途中で表示がずれる：CLS。画像や広告枠のサイズ指定、後から挿入される要素を確認する。
- 数字は悪くないのに体感が遅い：Speed Index。表示が段階的に進んでいるか、途中で長く止まっていないかを見る。
CDNで改善する指標・しない指標
CDN の導入はパフォーマンス改善の定番ですが、効く範囲は限定的です。CDN が短縮するのは配信距離とサーバー処理、つまり TTFB であり、その結果として起点が早まる FCP と LCP まで波及します。web.dev も TTFB の改善策として CDN の利用を挙げています。
一方、INP と TBT は自サイトの JavaScript がメインスレッドを占有している時間の問題なので、配信を速くしても短くなりません。CLS も、画像や広告枠に寸法が指定されていないことが原因であれば CDN とは無関係です。CDN を入れたのに Core Web Vitals の判定が変わらないという相談は、たいていこの切り分けを飛ばしています。導入を検討するなら、先に TTFB を測り、0.8秒を超えていることを確認してからにすべきです。
よくある質問
FIDはなくなったのですか？
2024年3月に INP へ置き換えられ、Core Web Vitals から外れました。現在の3指標は LCP・INP・CLS です。FID を含む「LCP・FID・CLS」という説明は更新されていない情報です。
TTFBはCore Web Vitalsに含まれますか？
含まれません。TTFB は補助的な指標で、順位の評価には使われません。ただし LCP より前段の時間なので、TTFB が大きいと LCP の基準（2.5秒以内）を満たす余地がなくなります。
TBTとINPは何が違うのですか？
TBT はラボ環境でメインスレッドが塞がった時間の合計、INP は実ユーザーの操作から次の描画までの時間です。TBT は実際の操作を伴わないため INP の代理でしかなく、判定に使われるのはフィールドの INP です。
CDNを入れればCore Web Vitalsは改善しますか？
TTFB とそれに続く LCP には効きますが、JavaScript の実行時間が原因の INP や、サイズ指定漏れによる CLS は改善しません。まず TTFB を測って0.8秒を超えているかを確認してください。
公式のしきい値はどこで確認できますか？
Core Web Vitals の基準は Google の web.dev（Web Vitals のページ）に、Lighthouse の採点重みとスコア区分は Chrome for Developers の Lighthouse パフォーマンススコアのドキュメントに記載されています。しきい値は指標のライフサイクルに応じて見直されるため、判断の前に一次情報で確認するのが確実です。
関連記事
- コアウェブバイタルとは？3指標（LCP・INP・CLS）の基準と改善方法【2026年版】
- オンページSEO（内部対策）とは？内部施策の一覧と優先順位・進め方
- 検索順位を上げるためのスマートフォンサイトにおけるSEO対策手法
