Core Web Vitalsの見方｜LCP・INP・CLSを測って直す順番

先に答え：点数ではなく、実ユーザーの3指標とページの役割を見る

Core Web Vitalsは、読み込みのLCP、操作への応答のINP、表示の安定性のCLSで実際のユーザー体験を捉える指標です。2026年10月12日に確認したGoogle公式資料では、良好の目安はLCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下で、モバイルとパソコンを分け、ページ読み込みの75パーセンタイルで評価します。

画像を拡大 ↗

LCP、INP、CLSの測定対象と主な原因候補を対応づけた図。閉じる ×

一つの改善方法を全指標へ当てはめません。

3指標すべてを「良好」にする価値はありますが、PageSpeed Insightsの単発スコアだけで公開可否や検索順位を断定しないでください。GoogleはCore Web Vitalsをランキングで考慮する要素と説明する一方、関連性の高い内容より優先される唯一の要素とはしていません。読者が目的を達成できる内容、操作、アクセシビリティも同時に確認します。

フィールドデータとラボデータを分ける

Search ConsoleのCore Web Vitalsレポートは、Chrome UX Report（CrUX）に基づく実際の利用状況データです。過去28日間のデータ、URLグループ、端末区分で問題を把握します。データ量が不足する新規・小規模サイトでは「データがありません」と表示されることがあります。

一方、LighthouseやPageSpeed Insightsのラボテストは、特定条件でその場のページを再現して原因候補を探す用途です。実ユーザーデータと一致しないことは異常ではありません。

画像を拡大 ↗

実ユーザーのフィールドデータと、特定条件のラボデータの用途を比較した図。閉じる ×

Search ConsoleとPageSpeed Insights等の結果を同一視しないための図です。

LCP：最大の主要要素が見えるまでを分解する

LCPはビューポート内の大きな画像、テキストブロック、動画のポスター等が描画されるまでの時間です。web.devは、前ページのアンロード、接続、リダイレクト、サーバー応答なども実測のLCPへ影響すると説明しています。

確認順は、LCP要素を特定し、その要素の取得開始が遅いのか、ファイルが重いのか、サーバー応答が遅いのかを分けます。

1. 対象URLと端末条件を固定する。
2. LCP要素が画像か見出しかを確認する。
3. 画像なら表示寸法、形式、圧縮、先読みの必要性を確認する。
4. CSSやJavaScriptが描画を止めていないか確認する。
5. リダイレクトやサーバー応答時間を確認する。

「画像を全部消す」は最後の手段です。重要な説明画像を残し、実際の表示寸法に合わせたデータを配信する方が、内容と速度の両立を図れます。

INP：一番遅い操作の種類を見つける

INPはクリック、タップ、キーボード操作に対するページ全体の応答性を評価します。重いJavaScript、長い処理、複雑なDOM、連続して走る第三者スクリプトなどが遅延要因になります。

画像を拡大 ↗

LCP、INP、CLSそれぞれで最初に確認する要素を示す図。閉じる ×

原因を特定してから修正方法を選びます。

メニュー、検索、フォーム、タブ、同意バナー等を実際に操作し、「押してから表示が変わるまで」が遅い箇所を記録します。操作名が分からない依頼ではなく、次の形で伝えます。

これは記入形式の架空例です。数値は実測した場合のみ記入し、ツールの一回の値を全利用者の結果として扱いません。

CLS：後から入る要素の場所を先に確保する

CLSは予期しないレイアウト移動の累積を表します。画像の幅・高さが未指定、Webフォントの置き換え、後から挿入されるバナーやエラー文、上部への広告挿入などが典型的な確認対象です。

意図したユーザー操作の直後に起きる移動など、CLSに含まれない場合もあります。数値だけでなく録画や実際の操作で、利用者が誤タップしそうな動きを確認します。

改善作業は「グループ→代表URL→共通部品」の順で進める

Search Consoleでは類似ページがURLグループとしてまとまります。記事群で同じ問題が出るなら、各記事の本文を一つずつ直す前に、共通ヘッダー、画像テンプレート、記事カード、同意バナー等を疑います。

画像を拡大 ↗

URLグループの確認から代表URL調査、共通部品の修正、公開後の再測定へ進む流れ。閉じる ×

同じ問題を記事ごとに重複修正しないための手順です。

1. モバイル／パソコン、指標、URLグループを記録する。
2. 代表URLをPageSpeed InsightsやDevToolsで調べる。
3. 共通部品か、そのURL固有の要素かを特定する。
4. 修正前の条件と結果を保存する。
5. 検証環境で本文・画像・フォームを操作確認する。
6. 本番公開後、同条件のラボテストで退行がないか確認する。
7. Search Consoleの実ユーザーデータ更新を待ち、グループで改善を確認する。

修正依頼テンプレート

対象URL：https://example.com/guide
端末区分：モバイル／パソコン
問題の指標：LCP／INP／CLS
確認元：Search ConsoleのURLグループ／PageSpeed Insights／実機
確認日時：2026-10-12 15:40 UTC
再現操作：ページを開く→メニューを押す→記事一覧へ移動
目視した現象：＿＿＿＿
候補要素：ヒーロー画像／メニュー処理／後挿入バナー等
修正後に守る機能：本文、画像、フォーム、アクセシビリティ
希望：共通部品かURL固有かを切り分け、修正前後を同条件で比較

速度改善のために重要な説明や操作を削る前に、原因要素とユーザーの目的を照合します。「100点にする」ではなく、遅い・反応しない・動いて押し間違える状態を具体的に減らすことが目標です。

SITE PORTを検討するときの確認ポイント

サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後に何を自分で変更できるかを確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。DNS・メール・計測の設定が通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝えて対応範囲を確認してください。

関連記事

[画像を軽くする順番](/articles/website-images-size-alt)・[スマホ公開前の操作チェック](/articles/mobile-website-prelaunch-check)