Core Web Vitalsの測定と改善

この記事はCore Web Vitalsのパフォーマンス記事契約に従います。

TL;DR — Core Web Vitalsは、実際のユーザーにページがどう感じられるかを測るGoogleの3つのスコアです。読み込みはLCP、タップやクリックへの応答はINP、読み込み中の動きはCLSで測ります。「良好」はLCPが2,5秒未満、INPが200ミリ秒未満、CLSが0,1未満です。ランキングを少し後押ししますが、良いコンテンツの方がはるかに重要です。

Core Web Vitalsとは何か

Googleは使いやすいページを評価するため、「良いページ体験」を3つの測定可能な要素にまとめました。これがCore Web Vitals（しばしばCWVと略されます）です。

• Largest Contentful Paint（LCP）— 読み込み。 画面上で最大の要素（通常はヒーロー画像や見出し）が表示されるまでの時間です。良好は2,5秒以下です。
• Interaction to Next Paint（INP）— 応答性。 ボタンをタップしたり入力したりしてからページが反応するまでの時間です。良好は200ミリ秒以下です。
• Cumulative Layout Shift（CLS）— 視覚的安定性。 読み込み中にページのレイアウトがどれだけ動くかです。良好は0,1以下です。

スコアはどこから来るか

Googleが実際に使うスコアは、テストではなくChromeでサイトを訪れた実在ユーザーから得られます。Googleはそのデータを集め、訪問者の**75%**が体験した内容でページを評価します。自分の端末で速い結果を1回得ても、実際の訪問者の大半が良い体験をしなければ合格にはなりません。

そのため、速度テストツールで満点を取っても合格は保証されません。PageSpeed InsightsやLighthouseなどは、問題を探すのに適したシミュレーション端末での単一のラボテストであり、Googleがランキングに使う数値そのものではありません。

ランキングに影響するか

影響はあります。GoogleはCore Web Vitalsをランキングシステムで使うと説明していますが、公式の重みや割合は示していません。また、関連性の高いコンテンツはページ体験が低いページを上回り得ると明記しています。コンテンツが関連していなければ、速く安定していても救えません。 “it’s not going to make your site’s rankings jump up.” (翻訳)「それでサイトのランキングが急上昇するわけではありません。」

実務上、これらの数値だけを追っても大きなランキング効果が出ないサイトが多いでしょう。それでも、ページを速く安定させることは訪問者に伝わり、ランキングが動かなくてもコンバージョンを助けます。

よくある誤解

古い名称に注意： Core Web Vitalとして**FID（First Input Delay）**をまだ見かけることがありますが、終了しています。INPは2024年3月12日にFIDへ置き換わりました。 FIDの最適化を勧めるツールや記事は古い情報です。

正確なしきい値、フィールドデータとラボデータの違い、ランキングへの実際の影響、目的別のツールはAdvancedタブで詳しく確認します。

TL;DR — Core Web Vitalsは、実在するChromeユーザー（CrUX）のフィールドデータで測定する3つのUX指標です。LCP（読み込み、良好は≤2,5 s）、INP（応答性、≤200 ms）、CLS（視覚的安定性、≤0,1）を、移動する28日間のデータにおける75パーセンタイルで評価します。モバイルとデスクトップのしきい値は同じですが、Googleはそれぞれを別々に評価し、3指標すべてが良好であることを求めます。INPは2024年3月12日にFIDを置き換えました。 GoogleはランキングシステムがCore Web Vitalsを使うと説明していますが、公式の重みや「タイブレーカー」の割合はありません。良好なスコアが順位上昇を保証するわけではなく、関連性が優先されることがあります。Lighthouse／PSIのラボスコアは診断用で、フィールドデータと一致しないことがあります。TTFBとFCPは診断用の「その他のWeb Vitals」、TBTとSpeed Indexはラボの代理指標です。

Core Web Vitalとして数えられるもの

GoogleはCore Web Vitalsを、すべてのウェブページに適用され、すべてのサイト所有者が測定すべきで、Googleの全ツールに表示されるWeb Vitalsの一部と定義しています。正確に3つあり、それぞれページの感じ方の異なる側面を測ります。 “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (翻訳)「すべてのWebページに適用され、すべてのサイト所有者が測定すべきで、Googleの全ツールに表示されるWeb Vitalsの一部です。」

Googleは3つの「良好」しきい値を75パーセンタイルで評価します。LCPは2,5秒、INPは200ミリ秒、CLSは0,1です。p75ですべてが基準を超えて初めて、ページ全体が良好と判定されます。しきい値はモバイルとデスクトップで同じですが、端末種別ごとに別々に評価・報告されます。

TTFB、FCP、TBT、Speed Indexなど、聞いたことのある他の指標はCore Web Vitalではありません。詳しくは後で扱います。

LCP — 読み込み

LCPは、ユーザーが最初にページへ移動してから、ビューポートに見える最大の画像、テキストブロック、動画が描画されるまでの時間を示します。実際にはヒーロー画像、大きな背景画像、見出しブロックがLCP要素になることが多いです。表示される最大要素なので、ビューポートサイズが違えばLCP要素も変わり、フィールドとラボの数値がずれる理由になります。 “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (翻訳)「ユーザーが最初にページへ移動した時点を基準に、ビューポートに見える最大の画像、テキストブロック、動画の描画時間を示します。」

INP — 応答性

INPは、訪問中に発生するすべてのクリック、タップ、キーボード操作を観測し、ページ全体のインタラクション応答性を評価します。入力遅延、イベントハンドラー処理、次のフレームを描画するまでを含む、完全なインタラクションを測定します。 “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (翻訳)「ページ滞在中に起きるすべてのクリック、タップ、キーボード操作の遅延を観測し、ページ全体のインタラクション応答性を評価します。」

INPは置き換えられた指標より大きく改善されています。最初の操作だけを測るFIDと異なり、すべての操作を観測します。INPは2024年3月12日にCore Web Vitalとなり、First Input Delay（FID）を置き換えました。 FIDはSearch Consoleからも削除され、完全に引退しています。

注意点として、INPは最悪の1回の操作ではなく、すべての操作の高いパーセンタイルです。1回のぎこちないクリックだけで、全体が良好なページになる可能性を失うわけではありません。

CLS — 視覚的安定性

CLSは、ページのライフサイクル全体で発生する予期しないレイアウトシフトについて、最大のシフトスコアのまとまりを測ります。セッションウィンドウは、1秒以内に起きたシフトを最大5秒の範囲でまとめます。Googleが挙げる典型的な原因は、寸法不明の画像や動画、初期フォールバックより大きくまたは小さく描画されるフォントなどです。 “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (翻訳)「ページのライフサイクル全体で発生する予期しないレイアウトシフトごとに、レイアウトシフトスコアの最大のまとまりを測定するものです。」 “images or videos with unknown dimensions,” (翻訳)「寸法が分からない画像や動画」 “fonts that render larger or smaller than its initial fallback,” (翻訳)「初期フォールバックより大きくまたは小さく描画されるフォント」 “third-party ads or widgets that dynamically resize themselves.” (翻訳)「動的にサイズを変える第三者広告やウィジェット」

フィールドデータとラボデータ：測定と診断

この区別が最も混乱を招くため、正確に扱います。

• **フィールドデータ（CrUX）**は、サイトを訪れた実在ユーザーから集めたデータです。75パーセンタイル、移動28日間、モバイルとデスクトップ別で報告されます。Core Web Vitalsはこの現実の体験を表し、Googleのランキングシステムで使われます。
• ラボデータは、制御された環境でページを実行して原因を診断するデータです。 “data collected from the real users visiting your site.” (翻訳)「サイトを訪れる実際のユーザーから集めたデータ」 “data collected in a controlled environment with predefined device and network settings” (翻訳)「あらかじめ定めた端末とネットワーク設定の制御された環境で集めたデータ」

Google自身の案内では、ページにフィールドデータとラボデータの両方がある場合、取り組みの優先順位にはフィールドデータを使うべきです。LighthouseのPerformance ScoreはフィールドのCore Web Vitalsと一致しないことが多く、ラボはテストと反復に使うものです。 “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (翻訳)「あるページについてフィールドデータとラボデータの両方があるなら、取り組みの優先順位にはフィールドデータを使うべきです。」 “often does not correlate with field Core Web Vitals.” (翻訳)「フィールドのCore Web Vitalsとは一致しないことが多い」 出典

p75ルールと重要性

ページが合格するには、実在ユーザーの75%が「良好」のしきい値に入る必要があります。訪問者の4人に3人が良い体験をすればよく、悪い接続の少数の外れ値だけで判定されません。自分の端末で1,8秒だったという事実だけでは意味がなく、全員のp75が重要です。

ページレベルとオリジンレベルに惑わされない

多くのツールは既定でサイト全体のオリジンレベル平均を表示し、個々のページより良く見せます。ある調査では、3つのしきい値すべてを通過した個別ページは21,2%で、オリジンレベルでは33%でした。ページ体験を評価する際は、ページ単位のデータを優先します。 出典

トラフィックが少ないページにはCrUXフィールドデータがないことがあります。また、CrUXには利用統計への参加を選んだChromeユーザーだけが含まれます。これは不合格ではなく、データ適格性の差です。フィールドデータがないことは低いスコアと同じではありません。

Core Web Vitalsはランキングにどれだけ影響するか

Core Web Vitalsは確認済みのランキングシグナルです。ただし、現在のGoogle文書は公式の重み、割合、「タイブレーカー」というラベルを付けていません。Google自身の言葉であるかのように、そうした表現を繰り返さないよう注意します。

Googleの文書は、Core Web Vitalsが他のページ体験要素とともに、主要なランキングシステムが評価しようとするものに沿うと説明します。また、John Muellerはタイブレーカー以上だが関連性を置き換えないと述べています。 “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (翻訳)「他のページ体験の側面とともに、主要なランキングシステムが報いることを目指すものに沿っています」 “more than a tie-breaker, but it also doesn’t replace relevance.” (翻訳)「タイブレーカー以上ですが、関連性を置き換えるものでもありません」

一方で、MuellerはCore Web Vitalsはランキングの巨大な要因ではなく、それだけで大きく落ちるとは考えにくいとも述べています。Googleのページ体験文書も、ページ体験が低くても最も関連性の高いコンテンツを表示しようとすると明確に説明します。 “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (翻訳)「Core Web Vitalsはランキングの巨大な要因ではなく、それだけで大きく落ちるとは考えにくいです」 “it’s not going to make your site’s rankings jump up.” (翻訳)「それでサイトのランキングが急上昇するわけではありません」 “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (翻訳)「Google検索は、ページ体験が十分でなくても、常に最も関連性の高いコンテンツを表示しようとします」 “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (翻訳)「SEOだけを理由に完璧なスコアを目指すことは、時間の最善の使い方ではないかもしれません」

実務的には関連性が優先され、GoogleはCWVの重みを数値化していません。ランキングのためだけに改善しても大きな効果を得ないサイトが多い一方、ユーザーとコンバージョンのためのUX改善には価値があります。

2024年の更新に関する補足です。広い意味でのページ体験シグナルのうち、ランキングへ直接寄与すると確認されているのはCore Web Vitalsだけです。HTTPS、モバイルフレンドリー、侵入的インタースティシャルの抑制、内容の明確さは良い実践ですが、かつて文書が示唆したように直接ランキングを押し上げるものではありません。

その他のWeb Vitals — 診断用でCoreではない

頻繁に登場するものの、誤って分類される指標です。どれもCore Web Vitalsではありません。

• Time to First Byte（TTFB） — レスポンスの最初のバイトが届くまでの時間です。LCPに影響しますが、Core Web Vitalではありません。
• First Contentful Paint（FCP） — 最初のコンテンツが描画されるまでの時間です。
• Total Blocking Time（TBT） — ラボでINPを近似する指標です。
• Speed Index — 知覚される読み込み速度のラボ指標です。 “precedes every other meaningful loading performance metric” (翻訳)「意味のある読み込みパフォーマンス指標はすべてこれに先行します」 “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (翻訳)「TTFBはCore Web Vitalsの指標ではないため、サイトが『良好』のTTFBしきい値を満たすことは絶対に必要ではありません」 “cannot measure INP” (翻訳)「実ユーザーがいなければINPは測定できません」

これらはデバッグに使います。Core Web Vitalsとして報告したり、しきい値をランキングの合否条件として扱ったりしません。

引退させるべき神話

新しいCore Web VitalとしてEngagement Reliabilityを見かけることがありますが、Googleによる公式発表はありません。第三者コンテンツだけで流通している名称です。Core Web VitalsはLCP、INP、CLSです。Googleが別のことを言うまでは、この3つだけを扱います。

測定方法と目的別のツール

仕事に合ったツールを選びます。

• ランキング関連（フィールドデータ）： PageSpeed Insights、Google Search ConsoleのCore Web Vitalsレポート、CrUX API／BigQuery、web-vitals JavaScriptライブラリ。
• デバッグ（ラボデータ）： Lighthouse、Chrome DevTools Performanceパネル、PageSpeed Insightsのラボ欄。

提案する流れは、GSCでフィールド上の失敗ページグループを見つけ、PageSpeed Insightsでページ単位を確認し、LighthouseまたはDevToolsで診断・反復することです。フィールドの数値は最大28日間更新されない点を前提にします。

次に進む：ウェブパフォーマンスのクラスター

このハブが地図です。以下の各テーマが独立した詳しい解説になります。

3つのCore Web Vitals

• Largest Contentful Paint — LCP要素、2,5秒以下の目標、早く描画する方法。
• Interaction to Next Paint — FIDを置き換えた応答性指標で、入力遅延、イベント処理、表示遅延を扱います。
• Cumulative Layout Shift — セッションウィンドウ、典型的な原因、シフトを防ぐ方法を扱います。

補助・診断指標

• Time to First Byte — LCPに影響するサーバー／レスポンス遅延で、デバッグに使います。
• First Contentful Paint — 最初のコンテンツの描画を表す読み込み診断です。
• Total Blocking Time — INPを近似するLighthouseのラボ指標です。
• Speed Index — 知覚される読み込み速度のラボ指標です。

測定方法

• PageSpeed Insights — CrUXフィールドデータとLighthouseラボレポート。
• Google Lighthouse — PSIとDevToolsの診断エンジン。
• Chrome UX Report（CrUX） — Googleの評価が使う実ユーザーデータセット。

クラスター全体についてはウェブパフォーマンスのハブを参照します。各兄弟ページは公開時にここへ自動的にリンクします。 出典

AI要約

Advanced版の要点をまとめます。

• Core Web Vitalsは3つのフィールド指標です。 LCP（読み込み、良好は≤2,5秒）、INP（応答性、≤200 ms）、CLS（視覚的安定性、≤0,1）です。TTFB、FCP、TBT、Speed IndexはCoreではありません。
• フィールドデータで判定します。 実在するChromeユーザーのCrUXを75パーセンタイルで、移動する28日間にわたり評価します。モバイルとデスクトップのしきい値は同じですが、別々に判定し、3指標すべてが良好であることを求めます。
• INPは2024年3月12日にFIDを置き換えました。 FIDは完全に引退し、最初だけでなくすべてのインタラクションを測ります。
• ラボツールは診断用です。 Lighthouse／PSIはフィールド測定ではなく、原因を見つけるために使います。フィールド数値の反映には最大28日かかります。
• ページレベルとオリジンレベルを分けます。 私のCWV研究 では個別ページの約21,2%が通過し、オリジンでは約33%です。オリジン平均は失敗ページを隠します。
• ランキングでは使われますが、重みは未公表です。 GoogleのランキングシステムはCore Web Vitalsを使うと述べていますが、公式の割合や「タイブレーカー」というラベルはありません。関連性が優先され、良好なスコアもランキングを保証しません。Muellerは「ランキングの巨大な要因ではない」と述べています。2024年の文書で直接ランキングに寄与すると確認されているのはCWVだけです。
• Engagement Reliabilityは確認済みのCore Web Vitalではありません。
• **ツールの使い分け：**フィールドはPSI、GSCのCWVレポート、CrUX API、web-vitals.js、デバッグはLighthouse、DevTools、PSIラボ欄です。

公式ドキュメント

Googleの一次資料を確認します。

web.dev（Chromeチーム） 出典 出典 出典 出典 出典 出典 出典 出典 出典 出典 出典

Google Search Central 出典 出典 出典

Chrome for Developers 出典

出典からの引用

Googleによる記録された発言です。各リンクは出典ページの引用箇所へ移動します。

Google — Core Web Vitalsとは何か

Core Web Vitalsの定義、LCP、INP、CLSに関する原文引用を、出典リンクとともに掲載します。 “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (翻訳)「すべてのWebページに適用され、すべてのサイト所有者が測定すべきで、Googleの全ツールに表示されるWeb Vitalsの一部です。」 “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (翻訳)「ユーザーが最初にページへ移動した時点を基準に、ビューポートに見える最大の画像、テキストブロック、動画の描画時間を示します。」 “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (翻訳)「ユーザーがページを訪れている間に起きるすべてのクリック、タップ、キーボード操作の遅延を観測し、ページ全体のインタラクション応答性を評価する指標です。」 “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (翻訳)「ページのライフサイクル全体で発生する予期しないレイアウトシフトについて、最大のシフトスコアのまとまりを測定します。」 出典 出典 出典 出典

Google — INPによるFIDの置き換え

INPが安定したCore Web Vitalとなり、FIDを置き換えたことに関する原文引用です。 “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” (翻訳)「Interaction to Next Paint（INP）は安定したCore Web Vital指標となり、First Input Delay（FID）に置き換わりました。」 出典

Google — フィールドとラボ、ランキング

フィールドデータを優先すべきこと、CrUXが実ユーザーのデータセットであることに関する原文引用です。 “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (翻訳)「あるページについてフィールドデータとラボデータの両方があるなら、取り組みの優先順位にはフィールドデータを使うべきです。」 “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (翻訳)「Chrome User Experience Report（Chrome UX Reportとも呼ばれ、略してCrUX）は、Web上の人気のある場所を実際のChromeユーザーがどう体験するかを反映するデータセットです。」 出典 出典

GoogleのJohn Mueller

Core Web Vitalsのランキング上の位置づけと、関連性を置き換えないことに関する発言を要約します。 “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (翻訳)「ランキング要因であり、タイブレーカー以上ですが、関連性を置き換えるものでもありません。」 “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (翻訳)「Core Web Vitalsはランキングの巨大な要因ではなく、それだけで大きく落ちるとは考えにくいです。」 出典 出典

Core Web Vitalsチェックリスト

正しい指標を測り、正しいページを直していることを確認します。

• Googleがランキングに使う指標について、ラボスコアだけでなくCrUXのフィールドデータを読んでいる。
• オリジンレベルの平均だけでなく、ページレベルの数値を確認している。
• 3指標すべてを確認している：p75におけるLCP ≤2,5 s、INP ≤200 ms、CLS ≤0,1。
• モバイルとデスクトップを別々にレビューしている（Googleはそれぞれを評価する）。
• FIDを最適化していない。FIDは2024年3月12日に引退したため、INPを使う。
• GSCのCore Web Vitalsレポートで、単発のURLではなく失敗しているページグループを確認している。
• トラフィックの少ないページでは、CrUXのフィールドデータがまったくないことがあると理解している。
• ラボツール（Lighthouse／PSI）は、合格／不合格の判定ではなく診断に使い、完全なPerformance Scoreを待っていない。
• フィールドの修正が反映されるまで最大28日間を見込んでいる。
• コンテンツの関連性や、より大きなSEOの成果を後回しにしてCWVだけを追っていない。

メンタルモデル

1. 3つの次元、3つの指標。 LCPは読み込み、INPは応答性、CLSは視覚的安定性です。問題の次元が分かれば、開くべき指標と詳しい解説が分かります。

2. ランキングにはフィールド、修正にはラボ。 Googleは28日間のp75 CrUXフィールドデータで評価し、LighthouseとPSIのラボスコアは原因を見つけます。ラボスコアをランキング値と扱いません。

3. ページレベルはオリジンレベルより優先。 「合格」したオリジンが失敗ページを隠すことがあります。両方を表示するツールではページレベルを信頼します。

4. 使われるが重みはない。 CWVは確認済みシグナルですが、Googleは公式の重みを付けていません。関連性が上回ることもあります。ユーザーとコンバージョンのために直し、ランキングの急上昇は期待しません。

5. 「Coreなのか」テスト。 Core Web VitalsはLCP、INP、CLSだけです。TTFBとFCPは診断指標、TBTとSpeed Indexはラボの代理指標です。Engagement Reliabilityはまったく確認されていません。

Core Web Vitals — チートシート

3つのCore Web Vitals（フィールドデータ、p75）

診断指標 — Core Web Vitalsではない

早わかり

• 評価はCrUXフィールドデータの75パーセンタイル、28日間の移動期間で、モバイルとデスクトップを別々に行います。
• INPは2024年3月12日にFIDを置き換えました。 FIDは完全に引退しています。
• LighthouseとPSIのラボスコアは診断用で、フィールド測定ではありません。フィールドCWVと一致しないこともあります。
• ページレベルの数値を確認します。オリジン平均は誤解を招くことがあります（私のCWV研究 ではページ約21,2%、オリジン約33%が3指標すべてを通過）。
• ランキングではGoogleのランキングシステムが使いますが、公式の重みは未公表です。関連性が優先され、良好なスコアも保証ではありません。
• Engagement Reliabilityは確認済みのCore Web Vitalではありません。

どのCore Web Vitalから調べるべきか

リリース後にCore Web Vitalsが悪化した場合

1. シグナルを確認する。 フィールドとラボ、URLとオリジン、モバイルとデスクトップを分けます。ラボ1回だけの変化なら、インシデントと宣言する前に再現します。
2. 失敗した指標を特定する。 LCP、INP、CLSは異なる問題を表します。複数が動いたら、共有リリース変更と第三者スクリプトを確認します。
3. 回帰をデプロイに結び付ける。 変更前後のRUMまたは再現可能なラボトレースを比較します。

作業を無駄にするCore Web Vitalsのミス

Lighthouseの合成スコアを最適化する

Googleのフィールド評価は、単一のLighthouse Performance数値ではなく、実ユーザーデータのLCP、INP、CLSを使います。失敗したフィールド指標を診断し、Lighthouseは制御されたデバッグ環境の1つとして使います。

Core Web Vitalsをランキングの近道として扱う

CWVはGoogleが公式の重みを付けていないページ体験シグナルで、関連性が優先されます。ユーザーのために悪い体験を直しますが、ランキング上昇を約束したり、根拠なく重要なコンテンツやインデックス作業を後回しにしたりしません。

URL、オリジン、モバイル、デスクトップの値を混ぜる

異なる範囲は異なる結果を示します。すべての値に範囲を付け、オリジンのフォールバックやデスクトップ集計が緑だからといってページ合格を主張しません。

リリース確認をCrUX待ちにする

移動28日間のウィンドウはデプロイQAには遅すぎます。まずラボとRUMで仕組みを確認し、その後CrUXで長期的なフィールド結果を確認します。

Core Web Vitalsを測るツール

Core Web Vitals History & Competitor Comparisonで確認します。

1. LCP、INP、CLSの今日の合否をスコアカードで読み、週次グラフで良好帯へ向かっているかを確認します。 出典（example.com）
2. サイトを追加します。
3. モバイルまたはデスクトップを選び、比較を実行します。

フィールドデータ — 実ユーザーのCore Web Vitals測定

• PageSpeed Insights — ページとオリジンのCrUXフィールドデータにLighthouseラボレポートを併記します。
• Google Search Console — Core Web Vitalsレポートで、失敗するページグループを見つけます。
• CrUX API／BigQuery — 元データから国別・カスタム分析を行います。（web-vitals）

ラボデータ — デバッグ用（ランキング用ではない）

• Lighthouse — 診断機会とランキングに使わないPerformance Score。
• Chrome DevTools Performanceパネル — LCP、レイアウトシフト、長いタスクのトレース診断。
• PageSpeed Insightsのラボ欄 — フィールドデータの下にあるLighthouse由来の推奨事項。

経験則： GSCでフィールド上の失敗箇所を見つけ、PSIでページレベルを確認し、LighthouseまたはDevToolsで診断と反復を行います。

時間を使う価値のあるリソース

関連する私の執筆 出典 出典 出典 出典 出典 出典

公式資料 出典 出典

業界の資料

• Google Core Web Vitals Ranking Factor：タイブレーカー以上 （Search Engine Journal）— CWVは「タイブレーカー以上」だが関連性を置き換えないというJohn MuellerのReddit発言を報じます。
• 小規模・ローカル企業におけるGoogle Core Web Vitalsの優先順位 （Search Engine Roundtable）— 小規模／ローカル企業では最優先にしないというMuellerの発言を扱います。
• 確認：Core Web Vitalsは大きなランキング要因ではない （Stan Ventures）— 「ランキングの巨大な要因ではない」という発言を文脈付きで扱います。
• Core Web VitalsがSEOへ与える影響 （RUMvision）— 発言とランキングシグナルのニュアンスをまとめたFAQです。
• Google Page Experience Update：タイブレーカー （Search Engine Roundtable）— 更新前の初期のタイブレーカー説明です。

引用する価値のある統計

• 個別ページの約21,2%だけが3つすべてのCore Web Vitalsを通過します。 オリジンレベルでは約33%です。これは私のCWVデータ調査（CrUXとAhrefs Site Auditの5,2Mページ）によるもので、Googleのシステムは一般にページを個別に評価するため、見かけ上良好なオリジン平均が多くの失敗ページを隠すことがあります。 出典
• サイトが最も苦戦するのはLCPです。 この調査では、古いFIDとCLSは改善が進んだ一方、LCPは遅れており、“almost no sites on 3G or slower connections are passing.” (翻訳)「3G以下の低速接続で3指標を通過しているサイトはほとんどありません。」 出典
• 「良好」のしきい値： LCP ≤2,5 s、INP ≤200 ms、CLS ≤0,1で、いずれもフィールドデータの75パーセンタイルで判定します。Googleが文書化しているCore Web Vitalsの目標です。 出典
• INPは2024年3月12日にFIDを置き換えました。 FIDがCore Web Vitalでなくなり、Search Consoleから削除された日付です。 出典

自分で確認する：Core Web Vitals

Core Web Vitalsについて5つの短い問題で確認します。各問に答えてから解説を確認します。

LCP、INP、CLSの修正が実際に反映されたことを証明する

パフォーマンス修正では、出荷当日のラボスコアだけを祝うのが落とし穴です。ラボ（Lighthouse）は変更が機能し得るかを示し、実ユーザーに効いたかを示すのはフィールドデータ（CrUX）だけです。両方をこの順で実行します。

テスト1 — 修正でラボ指標が改善した

• 実行するテスト： 変更前後でページをCore Web Vitals Checker、Lighthouse、PageSpeed Insightsに通します。
• 期待結果： 対象のラボ指標が正しい方向へ動きます。
• 失敗の解釈： ラボに変化がなければ、変更は重要なボトルネックに触れていません。 出典

テスト2 — 実ユーザーが実際に感じる（フィールドデータ）

• 実行するテスト： CrUXまたはGSCでページ／オリジンのLCP、INP、CLSのp75を追跡します。Core Web Vitals History & Competitor ComparisonまたはGSCのCore Web Vitalsレポートを使います。
• **期待結果：**修正した指標のp75が「良好」に入り、その状態が続きます（LCP ≤2,5秒、INP ≤200ms、CLS ≤0,1）。
• **失敗の解釈：**ラボは改善したがフィールドが改善しない場合、実ユーザーの端末、ネットワーク、キャッシュ、ページ範囲を確認します。
• **監視期間：**28日間の移動期間。CrUXは後追いの28日データなので、p75を信頼するには約4週間のフィールドデータ蓄積が必要です。1週目に判定しません。
• **ロールバックのトリガー：**p75が再び「不良」のしきい値を超える、またはテンプレート変更後にGSCの「良好」URL数が減る場合です。実ユーザーのパフォーマンスがリリースで悪化した強い兆候です。

このテーマの継続KPI

個別の修正を検証するだけでなく、ページ体験が健全かを四半期ごとに確認します。Googleがしきい値を公開しているため、ここでは根拠のある基準を使います。

p75 LCP、INP、CLS（フィールドデータ）

• 指標： ページグループと端末ごとに、実訪問での各Core Web Vitalの75パーセンタイル値です。
• 分かること： 実ユーザーの75%が良い体験を得ているかどうかです。GoogleがURLを合格と分類する正確な基準であり、遅いユーザーの長い裾野を反映するため、平均ではなくp75が重要です。
• 取得方法： CrUXのCore Web Vitals履歴と競合比較、URLパターン別のフィールドデータをまとめるGSCのCore Web Vitalsレポート、または単一URLならPageSpeed Insightsから取得します。
• ベンチマーク／現実的な範囲： Googleのしきい値は「良好」のLCP ≤2,5s、INP ≤200ms、CLS ≤0,1です。「要改善」／「不良」の範囲はそれぞれ2,5–4s／>4s、200–500ms／>500ms、0,1–0,25／>0,25です。作り物の目標ではなく、公開された基準です。
• 頻度： 28日間の移動期間なので毎月確認します。毎日確認しても同じ過去の期間を読み直すだけです。ラボスコアを先行指標、CrUXのp75を遅行指標として扱います。

サイト全体の「良好URL」カバレッジ

• 指標： GSCのCore Web Vitalsレポートで、インデックス済みURLのうち「良好」に入る割合を、モバイルとデスクトップで別々に追跡します。
• **分かること：**修正がどれだけ広がったか。サイトを変えるのは単一の速いページではなく、テンプレート単位の改善です。
• **取り出し方：**GSC → Core Web Vitalsレポート → 時間ごとの「良好」／「要改善」／「不良」URL数を確認します。
• **ベンチマーク／現実的な範囲：**状況依存です。テンプレートとトラフィック構成に左右されるため、自分のベースラインを定め、作り物の割合を追わずに「良好」の割合を徐々に高めます。
• **頻度：**毎月。フィールドの反映を待つテンプレート／テーマ変更の直後は毎週確認します。

変更履歴