コアウェブバイタル「LCP、INP、CLS、FCP、TTFB」などについて解説します

PageSpeed InsightsやGoogle Search Consoleの「ウェブに関する主な指標」にはLCP、INP、CLS、FCP、TTFBなどという指標が存在しますが、よく「どれが何だっけ？」と混乱してしまうため、備忘録も兼ねて綴っておきます。

Googleサーチコンソールを参照する際の参考になりましたら幸いです。

コアウェブバイタル(Core Web Vitals)と呼ばれる指標

画像引用：Web Vitals の概要: サイトの健全性を示す重要指標

よく「コアウェブバイタル」と呼ばれている指標が「ウェブに関する主な指標」に該当します。

Google Search ConsoleのコアウェブバイタルにはLCP、INP、CLSの3つがあり、PageSpeed Insightsには加えてFCP、TTFB、TBT、SIの7つがあります。

※FIDは2023年に呼称が変わってINPとなっています。

以下、各指標について説明します。

Largest Contentful Paint (LCP)

ページの読み込みの速さに関する指標です。読み込みが早いということはユーザーはページの表示を待たなくてもよいということなので、読み込みを早くするほどユーザー体験が向上します。

LCPはページの読み込み開始から2.5秒以内に終えることが理想とされています。

Interaction to Next Paint (INP)

例えば、ユーザーがハンバーガーメニューをクリックしたときなどウェブサイト上で何かアクションを起こしたとき、アクションに対してどれぐらいの速さでレスポンスがあったかを示す指標です。

ハンバーガーメニューをクリックしても開くのに2秒ほど間があったりなど、サイトからのレスポンスが遅い場合、ユーザーにとってストレスなので、レスポンスは早いほうが好ましいです。

INPはユーザーのアクションから200ミリ秒以下にレスポンスを返すことが理想とされています。

Cumulative Layout Shift (CLS)

ページの読み込み開始から終了まで、ユーザーの表示されている画面上に表示崩れが出現する現象をスコア化したものです。

ページを開くとテキストだけ表示されて2～3秒経過してから画像がドンッと表示される減少に遭遇したことがあるかと思います。

このように予期せぬ表示崩れがあるとユーザーにとってストレスになるため、このような表示崩れは少ないほうが良いです。

CLSは0.1以下に抑えることが望ましいです。

First Contentful Paint (FCP)

ページの読み込みの速さに関する指標です。ユーザーが最初に「何かコンテンツが表示された」と認識できるまでの時間を測定します。テキストや画像、SVGなどの要素が最初に表示されるタイミングを指します。

ページの表示が速いほどユーザーの離脱率が低くなるため、FCPは短いほど望ましいです。

FCPは 1.8秒以内 に収めることが理想とされています。

Time to First Byte (TTFB)

サーバーの応答速度を測る指標です。ユーザーがページをリクエストしてから、サーバーが最初の1バイトを返すまでの時間を示します。

サーバーの処理速度やネットワークの遅延などが影響するため、TTFBが長いとページの表示開始が遅れ、ユーザー体験が悪化します。

TTFBは 800ミリ秒以下 に抑えることが望ましいです。

Total Blocking Time (TBT)

ページのインタラクティブ性に関する指標です。ページの読み込み中に、メインスレッドが長時間ブロックされ、ユーザーの操作（クリックやスクロール）が一時的に無視される時間の合計を測定します。

例えば、JavaScriptの処理が重いと、ページは表示されていてもボタンを押しても反応しないことがあります。TBTが長いと、ユーザー体験が悪化します。

TBTは 200ミリ秒以下 に抑えることが理想とされています。

Speed Index (SI)

ページが視覚的にどれだけ速く表示されるかを示す指標です。ページ全体のコンテンツが視覚的に表示されるまでの平均時間を測定します。

Speed Indexが低いほど、ページがスムーズに読み込まれ、ユーザーは「速い」と感じます。逆に、高いとページの表示が遅く、ユーザーがストレスを感じやすくなります。

Speed Indexは 3.0秒以下 に抑えることが望ましいです。

PageSpeed Insights で提示される改善項目について

PageSpeed Insightsを使えばウェブサイトの読み込み速度や表示崩れの問題などを無料で診断できます。

診断した結果、いろいろな診断項目、問題点、改善項目を挙げてもらえます。代表的な項目には以下などがあります。

診断項目	問題点	改善項目
最大コンテンツの描画 (LCP) 要素	LCPの表示に時間がかかっている	画像の最適化、サーバーの応答速度向上、CDNの活用
JavaScript の実行にかかる時間の低減	JSの処理時間が長い	不要なJSの削減、コードの最適化、遅延読み込み
メインスレッド処理の最小化	メインスレッドの負荷が高い	不要なJSを減らす、Web Workerを活用
第三者コードの影響を抑えてください	外部スクリプトがサイト速度を低下させている	使用しないサードパーティスクリプトを削除、遅延読み込み
レンダリングを妨げるリソースの除外	CSSやJSの読み込みが遅延を引き起こしている	非同期・遅延読み込みの設定、クリティカルCSSの活用
使用していない CSS の削減	不要なCSSが含まれている	未使用CSSを削除、CSSの分割と最適化
使用していない JavaScript の削減	不要なJSがページ速度を低下させている	未使用のJSを削除、コードの最適化
次世代フォーマットでの画像の配信	画像フォーマットが最適でない	WebPやAVIF形式を使用
静的なアセットと効率的なキャッシュ ポリシーの配信	キャッシュ設定が最適化されていない	長期間のキャッシュ設定を適用
ウェブフォント読み込み中のテキストの表示	フォント読み込み時にテキストが表示されない	フォールバックフォントを設定、font-display: swap を使用
適切なサイズの画像	画像が大きすぎる	画像サイズを最適化、レスポンシブ画像を使用
最新ブラウザに従来の JavaScript を配信しないようにしてください	古いJSが最新ブラウザ向けに配信されている	モダンJSの活用、ES6以降のコードを使用
メインスレッドでタスクが長時間実行されないようにしてください	長時間のタスクがメインスレッドを占有	タスクの分割、Web Workerの活用
過大な DOM サイズの回避	DOM要素が多すぎる	不要なHTMLの削減、軽量なコンポーネント設計
カスタム速度の記録と計測	速度の詳細な計測を推奨	Web Vitalsを計測し、最適化を継続
過大なネットワーク ペイロードの回避	データ転送量が多すぎる	画像・JS・CSSの圧縮、最適化
クリティカル リクエスト チェーンを回避してください	不要なリクエストが多い	依存関係を整理、リクエストの最適化

いろいろと項目がありますが要点をまとめると以下のとおりです。

• 画像や動画は可能な限りサイズを小さくする
• 不要なJavascriptは削除する
• HTMLやCSSの構造を不必要に複雑にしない

これを心がければ自然とコアウェブバイタルは良好な状態になります。

さいごに

今回はコアウェブバイタルであるLCP、INP、CLSについて簡単に解説しました。

定期的にPageSpeed InsightsやGoogle Search Consoleを確認して上記を参考にしつつサイトの状態をチェック、改善しましょう。

ウェブ広告の運用やアクセス解析など、ウェブマーケティングに関するお仕事のご相談は以下の公式LINEからお願いいたします。

LINEお友だち追加：真策堂

あわせて読みたい

ウェブサイトのアクセスが減少する主な原因をまとめてみた 実務にてウェブサイトのアクセスログ分析をしていると、前年や前月に比べてアクセスが減少している状況を見つけることがあります。 今回はよくあるアクセス減少の原因と…

あわせて読みたい

【GA4】アクセス増加の原因を分析、特定する方法を紹介します ウェブサイトへの流入が増加した際、何が原因で増加したのか包括的に分析する方法をまとめてみました。 日頃のアクセス解析のお役に立てれば幸いです。 【分析する項目…

あわせて読みたい

Looker Studioのフィルター、データソースを消す方法 Looker Studioのフィルターとデータソースを消そうとすると、消したはずなのにぴょこっとまた現れることありませんか？ 小ネタですが、地味に嫌なこの現象の解決方法を…

FCPとLCPは何が違うのか

この2つは同じ「表示の速さ」を測っている指標なので、混同しやすいところかなと思います。違いは計測の終点です。

どちらもページの読み込み開始が起点ですが、FCPは何かひとつでも描画された瞬間、LCPは画面内で最も大きい要素が描画された瞬間を終点にします。定義上LCPはFCP以降に発生するので、LCPがFCPより小さい値になることはありません（LCP | web.dev）。

この関係を知っておくと、2つの数値の差から原因を切り分けられます。

• FCPの時点ですでに遅い → 最初の描画まで到達できていない。サーバー応答（TTFB）やレンダリングを妨げるCSS/JSが疑わしい
• FCPは速いのにLCPが遅い → 骨組みは出ているのに主役が出てこない状態。ファーストビューの大きな画像や見出し周りの読み込みが重い可能性が高い

「どの要素がLCPなのか」はPageSpeed Insightsの診断に「最大コンテンツの描画 (LCP) 要素」として表示されるので、まずそこを確認してから手を打つのが早いと思います。ページによってはヒーロー画像ではなく大きめのテキストブロックがLCP要素になっていることもあり、思い込みで画像だけ圧縮しても効かないケースもあるかなと。

LCP・INP・CLSは何がどう違うのか

3つとも並べて語られますが、測っている対象も時間帯もバラバラです。整理すると以下のようになります。

指標	測る対象	測る時間帯	単位
LCP	読み込みの速さ	ページを開いてから表示が完了するまで	秒
INP	操作への応答性	表示された後、ユーザーが操作したとき	ミリ秒
CLS	表示の安定性	ページ滞在中ずっと	スコア（単位なし）

LCPとINPはどちらも「速さ」なので似て見えますが、LCPは読み込み中の話、INPは読み込みが終わった後の話です。なのでLCPが良好でもINPが悪いという組み合わせは普通に起こります。画像を軽くしてLCPを改善しても、クリック後に走るJavaScriptが重いままならINPは動かない、という感じかなと。

CLSだけは時間ではなくスコアで、しかも計測が一瞬で終わりません。ページ滞在中に発生したズレを累積するため、スクロールした先で広告や埋め込みが後から挿入されるようなページだと、ファーストビューだけ整えても数値が改善しないことがあります。

Search ConsoleとPageSpeed Insightsで数字が違う理由

同じページなのに、PageSpeed Insightsは高得点なのにSearch Consoleでは「改善が必要」のまま、ということがあります。これは見ているデータが別物だからです。

• フィールドデータ（実際のユーザーの環境で計測された値）：Chrome ユーザー エクスペリエンス レポート（CrUX）由来で、直近28日間の集計。Search Consoleの「ウェブに関する主な指標」もこちら
• ラボデータ（Lighthouseがその場で計測した値）：PageSpeed Insightsの下段。実行するたびに条件が変わるので数値も揺れる

そして良好かどうかの判定は、フィールドデータの75パーセンタイルで行われます（Web Vitals | web.dev）。平均ではないので、大半のユーザーが快適でも、回線や端末が非力な下位25%が足を引っ張ると判定は改善しません。

ここから実務上いえることが2つあります。

ひとつは、改善しても評価に反映されるまで時間がかかること。28日間の集計なので、修正した翌日にSearch Consoleを見ても変わっていないのが普通です。

もうひとつは、ラボにしかない指標があること。この記事で挙げた指標のうちTBTとSI、そしてFCPはSearch Consoleの「ウェブに関する主な指標」には出てきません。特にTBTはラボでINPの代わりに見る目安として使われることが多く、ラボでTBTを削っておくと結果的にフィールドのINPも動く、という関係で捉えておくといいのかなと思います。

なので、直すときはPageSpeed Insightsのラボデータを見ながら作業して、効いたかどうかの答え合わせは数週間後にSearch Consoleでする、という二段構えになります。

「良好」と「不良」の境目はどこにあるのか

記事内では各指標の理想値を挙げましたが、実際にPageSpeed InsightsやSearch Consoleを見ると、緑・オレンジ・赤の3段階で色分けされています。理想値を超えたら即「不良」というわけではなく、あいだに「改善が必要」の帯があります。まとめると以下のとおりです。

指標	良好	改善が必要	不良
LCP	2.5秒以下	2.5〜4.0秒	4.0秒超
INP	200ミリ秒以下	200〜500ミリ秒	500ミリ秒超
CLS	0.1以下	0.1〜0.25	0.25超
FCP	1.8秒以下	1.8〜3.0秒	3.0秒超
TTFB	800ミリ秒以下	800〜1800ミリ秒	1800ミリ秒超
TBT	200ミリ秒以下	200〜600ミリ秒	600ミリ秒超
SI	3.4秒以下	3.4〜5.8秒	5.8秒超

（出典：LCP / INP / CLS / FCP / TTFB 各記事、TBTとSIは Lighthouse のスコア基準）

ここで注意したいのは、TBTとSIの境目は「Lighthouseというツールが測定環境で出した値に対する基準」だということかなと。LCP・INP・CLSのように実際のユーザーの体験を集計したものではないので、同じ土俵で比べるものではないと思っています。

検索の評価対象になるのはLCP・INP・CLSの3つ

指標が7つも並ぶと「全部を緑にしないといけないのか」と身構えてしまうところですが、Googleがページエクスペリエンスの一部として扱っているのは、ウェブに関する主な指標であるLCP・INP・CLSの3つです。FCP・TTFB・TBT・SIは、その3つがなぜ悪いのかを突き止めるための診断用の指標という位置づけになります。

とはいえ補助指標を無視していいという話でもなくて、PageSpeed Insightsのパフォーマンススコア（0〜100の点数）の内訳を見ると、Lighthouse 10以降の重み付けはTBTが30%、LCPとCLSがそれぞれ25%、FCPとSIがそれぞれ10%となっています。TBTの比率が一番大きいので、「スコアが伸びない」と悩んでいる場合はJavaScriptの重さを疑うのが近道かなと思います。

逆に言えば、スコアを100点に近づける作業と、Search Consoleの「改善が必要」を消す作業は、必ずしも同じ作業ではありません。検索まわりで困っているなら、点数よりも3指標の判定を先に見た方が良いと思います。

TTFB・FCP・LCPは一本の線、INPとCLSは別系統

指標同士の関係を頭に入れておくと、どこから手を付けるかが決めやすくなります。

TTFB・FCP・LCPの3つは、同じ「ページを開いてから表示されるまで」の時間軸の上に順番に並んでいます。サーバーが最初の1バイトを返し（TTFB）、その後に何かが描画され（FCP）、最後に一番大きい要素が描画される（LCP）という流れなので、上流のTTFBが遅ければ下流のFCPもLCPも自動的に遅くなります。SIはこの区間で画面がどう埋まっていくかを見ている指標なので、やはり同じ系統です。

一方でINPは表示が終わった後の操作への応答、CLSは滞在中に起きたズレなので、この線とは別軸になります。ただしINPについては、ラボ計測のTBTが近い性質を持っていて、web.devでもTBTが長いページはINPも悪くなりやすいと説明されています。実ユーザーのINPが集まっていない段階では、TBTを目安に手を打つのは現実的なやり方かなと。

なので優先順位としては、まずTTFBを見て上流が詰まっていないか確認し、そこが問題なければLCP要素の重さを見る。表示側が片付いてからJavaScript（TBT/INP）とレイアウト（CLS）に進む、という順番が無駄が少ないと思います。表示が遅い原因を画像だと決めつけて圧縮を頑張っても、実はサーバー応答が遅かった、というケースもあり得るので、順番に切り分けるのが結局は早いのかなと考えています。