2026.10.20 開発

Core Web Vitalsとは：LCP・INP・CLSの基準値とweb-vitals・CrUX APIでの測り方【2026年10月】

Core Web Vitalsは、Googleがページの使いやすさを測るために定めたLCP・INP・CLSの3指標で、実際のChrome利用者の計測値を75パーセンタイルで判定します。2024年3月にFIDがINPに置き換わり、2026年10月時点もこの3指標の構成は変わっていません。この記事では、しきい値と測る範囲、Lighthouseの値と合わない理由、web-vitalsとCrUX APIでの計測コード、LCPの原因の切り分け方、SEOへの効き方の限界を公式ドキュメントにもとづいて解説します。

まとめ：Core Web Vitalsの3指標と合格判定・計測手段の要点

合格の条件は、LCPが2.5秒以内、INPが200ミリ秒以下、CLSが0.1以下の3つを、モバイルとPCそれぞれの75パーセンタイルで満たすことです。判定に使われるのはChromeの実利用者から集めたCrUXの28日分のデータで、Lighthouseが出すラボの値ではありません。ラボの値は原因を探す道具として使い、合否はフィールドの値で見ます。

自社で測るなら、web-vitalsライブラリで実ユーザーの値を自前の集計先へ送り、CrUX APIでGoogle側の値を定期的に取ります。PageSpeed Insights APIは実データを返さなくなる予定なので、新しく組む集計はCrUX APIを使います。SEOへの効果は、関連性で並んだページの間で差が付く程度です。

Core Web Vitalsの3指標：LCP・INP・CLSが測る体験としきい値

3指標は、読み込み・操作への応答・表示の安定を1つずつ受け持ちます。

LCP・INP・CLSの良好・改善が必要・不良の境界値と判定単位

web.devのWeb Vitals解説では、3指標とも「モバイルとデスクトップに分けたページ読み込みの75パーセンタイル」が推奨値に収まれば合格とされます。つまり訪問の4分の1までは遅くても合格になり、逆に半数が速くても上位25%が遅ければ不合格です。

指標	測る体験	良好	改善が必要	不良
LCP	主要な内容の表示	2.5秒以下	4.0秒以下	4.0秒超
INP	操作への応答	200ミリ秒以下	500ミリ秒以下	500ミリ秒超
CLS	表示のずれ	0.1以下	0.25以下	0.25超

表はGoogle Search Consoleのヘルプに載る区分で、同ヘルプは不良を「低速」と表記しています。境界をなぜこの値にしたかはしきい値の定義方法を説明した公式記事に根拠がまとめられています。文書によって「2.5秒以下」と「2.5秒未満」の表記が混在しますが、実務で境界ちょうどの値を争う場面はまずありません。

LCP（最大コンテンツの描画）の対象要素とユーザー操作で計測が止まる条件

LCPは、画面に見えている範囲で最も大きい画像かテキストのまとまりが描画されるまでの時間です。LCPの公式解説が挙げる対象は、img要素、svg内のimage要素、動画のポスター画像か最初のフレーム、url()で読み込む背景画像、テキストを含むブロック要素の5種類です。

不透明度が0の要素、画面全体を覆う背景とみなされる要素、情報量の少ないプレースホルダー画像は候補から外れます。もう1つの決まりは、ユーザーがタップ・スクロール・キー入力をした時点で新しい候補の報告が止まることです。大きな画像を後から差し込むページでは、すぐスクロールされると先に出ていた見出しがLCPとして記録されます。

INPが拾う操作とFIDから替わった2024年3月以降の指標の入れ替え

INPは、ページを開いている間のクリック・タップ・キー入力に対し、次の画面が描かれるまでの遅れを測ります。INPの公式解説によると、ホバー・ズーム・スクロールは対象外で、操作が多いページでは50回ごとに最も遅い1回を除いた最悪値を採ります。操作をしないまま離脱した訪問にはINPの値が付きません。

以前この枠にあったFIDは、最初の1回の操作の待ち時間しか測っていませんでした。INPの正式採用を告知した公式ブログでは、INPが安定版の指標としてFIDに代わり、FIDに依存するツールの移行期限を2024年9月9日としています。指標は「試験運用版→保留中（最低6か月）→安定版」の順に昇格し、安定版の変更は年1回以下と決められています。

CLSのセッションウィンドウと入力後500ミリ秒以内のずれを除く規則

CLSは、ページの表示中に起きた予期しないレイアウトのずれを点数にしたものです。1回のずれの点数は「影響率×距離率」で、画面の75%を占める要素が画面の25%分動けば0.75×0.25＝0.1875になります。

CLSの公式解説では、間隔が1秒未満で続き、全体が5秒以内に収まるずれをひとまとまり（セッションウィンドウ）とし、合計が最も大きいまとまりの値をCLSとします。ユーザーの入力から500ミリ秒以内のずれはhadRecentInputが付いて除外されるので、アコーディオンを開いて下の内容が動くのは減点されません。スクロールやピンチ操作はこの除外の対象外です。

フィールドデータとラボデータ：順位に使われる値とLighthouseの差

「PageSpeed Insightsでは緑なのにGoogle Search Consoleでは低速」という食い違いの多くは、見ているデータの種類が違うことから起きます。

CrUXの28日間・75パーセンタイル・モバイルとPCの分割で決まる判定

合否に使われるのは、Chromeの利用者から集めたChrome User Experience Report（CrUX）の値です。CrUXの収集方法を説明した公式文書によると、iOS版のChrome、AndroidアプリのWebView、EdgeなどほかのChromium系ブラウザはデータを提供しません。iPhoneの利用者が多いサイトでは、計測の母数がAndroidとPCに偏ります。

値は直近28日間の累積で、モバイルとPCは別々に判定されます。修正を本番に出しても、28日分のデータが入れ替わるまで数値は少しずつしか動きません。リリース翌日に「変わらない」と判断するのは早すぎます。

LighthouseがINPを測れずTBTで代替する理由とスコアが合わない場面

Lighthouseは、決められた端末性能と回線で1回だけページを読み込むラボの計測です。操作をしないためINPは測れず、web.devのWeb Vitals解説でも代わりにTotal Blocking Time（TBT）を見るよう案内されています。TBTは利用者が実際に押すボタンの重さまでは反映しません。

利用者の端末が想定より遅い、ログイン後の画面が重い、遅れて入る広告がずれを起こす、といったサイトほど両者は食い違います。TBTやSpeed Indexの読み方はWebパフォーマンス指標の一覧と使い分け｜TTFB・FCP・TBT・Speed Indexの基準で指標ごとに整理しています。

Google Search ConsoleのURLグループと最も遅い指標で決まる判定

Google Search ConsoleのCore Web Vitalsレポートのヘルプによると、レポートは似たページをURLグループにまとめ、グループのステータスは3指標のうち最も悪いものになります。LCPとCLSが良好でもINPが改善が必要なら、そのグループは「改善が必要」です。

レポートに出るのはインデックス登録済みでデータが足りているURLだけで、データが少ないURLは上位のオリジン単位のグループにまとめられます。修正後は、問題の詳細ページで［トラッキングを開始］を押してください。28日間の監視が始まり、その間に問題が出なければ解決とみなされます。

web-vitalsライブラリで実ユーザーのLCP・INP・CLSを送信する実装

CrUXは原因の要素までは返しません。画面ごとの値と原因を見たいときは、計測コードを入れて自前で集めます。

npmで6.2系を入れてonLCP・onINP・onCLSから計測値を送るコード

Googleが公開しているweb-vitalsライブラリのリポジトリは、ブラウザの計測APIの細かな癖を吸収し、CrUXと同じ方法で値を出します。2026年10月時点のnpmの最新版は6.2.3（2026年10月5日公開）で、圧縮後は約3KBです。

npm install web-vitals@6

import {onCLS, onINP, onLCP} from 'web-vitals';

// 計測値を自社の集計先へ送る。ページを閉じる直前でも届くよう sendBeacon を優先する
function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,                    // 'LCP' | 'INP' | 'CLS'
    value: metric.value,                  // LCP・INPはミリ秒、CLSは単位なし
    rating: metric.rating,                // 'good' | 'needs-improvement' | 'poor'
    id: metric.id,                        // 同じ訪問の値を束ねるためのID
    navigationType: metric.navigationType,
    path: location.pathname,
  });
  (navigator.sendBeacon && navigator.sendBeacon('/api/vitals', body)) ||
    fetch('/api/vitals', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

集計先では、pathと端末種別ごとに75パーセンタイルを計算すれば、CrUXと同じ物差しで画面別の合否を出せます。reportAllChangesを有効にすると値が変わるたびに呼ばれますが、公式はデバッグ用と位置付けているので本番では付けません。v5.0.0（2025年5月）でonFIDは削除されたため、古いコードがFIDを送っていたら書き換えが要ります。集計基盤まで自前で持つか製品を入れるかは、リアルユーザーモニタリング（RUM）とは｜実ユーザー計測の仕組み・合成監視との違い・導入判断を実装目線で解説で比べています。

SPAの画面遷移を測るv6のソフトナビゲーション対応と集計上の注意

ReactやVue.jsのSPAは画面遷移でページを読み込み直さないため、従来は最初の画面以外のLCPが記録されず、INPとCLSは全画面分が1つの値に混ざっていました。

web-vitalsはv6.0.0（2026年7月21日）で、この「ソフトナビゲーション」の計測に対応しました。READMEによると、Chrome 151以降で各関数に{reportSoftNavs: true}を渡すと、操作・URL変更・描画の3つがそろった時点を区切りとして、遷移ごとの値を出す仕組みです。最初の画面のINPとCLSは区切りの時点で確定するので、比較期間の途中で設定を変えず、非対応ブラウザの値とも混ぜずに集計します。CrUX APIにもexperimental_largest_contentful_paint_with_softnavsなどの試験的な指標が追加されています。

CrUX APIでオリジンとURL単位のフィールド値を定期取得する手順

Googleの判定に使われる値そのものはCrUX APIで取れます。取得を自動化して推移を残せば、修正の効き目を追えます。

APIキーの発行からcurlでp75とヒストグラムを取り出すまでの手順

CrUX APIの公式リファレンスに従い、Google CloudでChrome UX Report APIを有効にしてAPIキーを発行し、URLのkeyに付けます。本文にはorigin（サイト全体）かurl（1ページ）と、formFactor（PHONE・DESKTOP・TABLET。省略時は全端末の合算）を入れます。

export CRUX_API_KEY="発行したAPIキー"

curl -s -X POST \
  "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=${CRUX_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "origin": "https://www.example.com",
    "formFactor": "PHONE",
    "metrics": ["largest_contentful_paint", "interaction_to_next_paint", "cumulative_layout_shift"]
  }' \
  | jq '{period: .record.collectionPeriod, p75: (.record.metrics | map_values(.percentiles.p75))}'

応答のpercentiles.p75が合否判定に使う値で、histogramには良好・改善が必要・不良の3区分に入った割合が入ります。LCPとINPはミリ秒の整数ですが、CLSだけは小数2桁の文字列で返るので、集計で数値として比べる前に型を変換してください。

複数URLを1分150回の上限内で取得するPythonと約2日の遅れの扱い

上限はGoogle Cloudのプロジェクトごとに1分150回で、無料のかわりに引き上げはできません。主要なURLを並べて定期実行する場合は、次のように間隔を空けて呼びます。標準ライブラリだけで動きます。

import json
import os
import time
import urllib.error
import urllib.request

ENDPOINT = ("https://chromeuxreport.googleapis.com/v1/records:queryRecord?key="
            + os.environ["CRUX_API_KEY"])
METRICS = ["largest_contentful_paint", "interaction_to_next_paint", "cumulative_layout_shift"]
URLS = [
    "https://www.example.com/",
    "https://www.example.com/products/",
]


def fetch_p75(url, form_factor="PHONE"):
    """1ページ分のp75を取得する。記録が無い場合はHTTPステータスを返す"""
    body = json.dumps({"url": url, "formFactor": form_factor, "metrics": METRICS}).encode()
    req = urllib.request.Request(ENDPOINT, data=body, headers={"Content-Type": "application/json"})
    try:
        with urllib.request.urlopen(req, timeout=30) as res:
            record = json.load(res)["record"]
    except urllib.error.HTTPError as e:
        return {"url": url, "status": e.code}
    p75 = {k: v["percentiles"]["p75"] for k, v in record["metrics"].items()}
    p75["cumulative_layout_shift"] = float(p75.get("cumulative_layout_shift", "nan"))  # CLSは文字列で返る
    return {"url": url, "period": record["collectionPeriod"], **p75}


for u in URLS:
    print(fetch_p75(u))
    time.sleep(0.5)  # 1分120回に抑え、上限の150回を超えないようにする

データは28日間のローリング集計で、毎日04:00 UTCごろ更新され、APIに出るまで約2日遅れます。collectionPeriodは対象ページが公開から28日未満でも常に28日と表示されるため、新しいページの値は期間の表示どおりには読めません。記録のないURLは、訪問数がCrUXの基準（数値は非公開）に届いていないか、noindexなどで公開扱いになっていないかを疑います。

PageSpeed Insights APIの実データ終了予定とCrUX APIへの移行

実データの取得にPageSpeed Insights API（runPagespeed）を使っている集計は、置き換えを計画しておくべきです。PageSpeed Insights APIの公式ガイドには、CrUXの実データを応答に含めるのをやめる予定であり、代わりにCrUX APIかCrUX History APIを使うよう明記されています（2025年8月28日更新時点。終了日は示されていません）。

応答では実データがloadingExperienceとoriginLoadingExperience、ラボの結果がlighthouseResultに入ります。前者を読む処理はCrUX APIへ移し、PageSpeed Insights APIからはLighthouseの診断だけを取る形に分けておけば、提供が止まっても集計は途切れません。

attributionビルドで基準超えの原因要素を特定して直す順番

数値が悪いと分かった後に必要なのは、どの要素のどの区間が遅いかです。web-vitalsのweb-vitals/attributionから読み込むと、各指標に原因の手がかりが付いて返ります。

LCPを4区間に分けてTTFB・読み込み遅延・描画遅延のどこが長いか見る手順

LCPのattributionは、時間を4つの区間に分けて返します。READMEに定義された項目名はtimeToFirstByte（サーバーの応答）、resourceLoadDelay（LCP画像の読み込みが始まるまで）、resourceLoadDuration（画像の読み込み時間）、elementRenderDelay（読み込み後に描かれるまで）です。

import {onLCP} from 'web-vitals/attribution';

// LCPの4区間と対象要素を表で出す。開発者ツールのコンソールで確認する
onLCP(({value, attribution}) => {
  console.table({
    LCP全体: value,
    対象要素: attribution.target,
    サーバー応答: attribution.timeToFirstByte,
    読み込み開始までの遅れ: attribution.resourceLoadDelay,
    読み込み時間: attribution.resourceLoadDuration,
    描画までの遅れ: attribution.elementRenderDelay,
  });
}, {reportAllChanges: true});

直す順番は、長い区間から決まります。サーバー応答が長ければキャッシュや配信元の見直しで、静的な部分はCDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説の手順でエッジに載せます。読み込み開始の遅れが長いのは、LCP画像が遅延読み込みになっているか、CSSやJavaScriptの後でしか見つからない場合がほとんどです。画像を圧縮しても縮むのは読み込み時間の区間だけなので、まず区間を見てから手を付けます。

INPを入力遅延・処理時間・表示遅延に分けて長いタスクを割る入口

INPのattributionは、操作された要素（interactionTarget）と、入力遅延・処理時間・表示遅延の3区間を返します。入力遅延が長いならその時点で別のスクリプトが動いており、処理時間が長いならイベントハンドラ自体が重く、表示遅延が長いなら描画する範囲が広すぎる、という切り分けになります。

基本の手は、長いタスクを分割して画面の更新を先に返すことです。longAnimationFrameEntriesからは原因のスクリプトのURLまでたどれます。区間ごとの直し方とFIDとの違いはINPとは？Core Web Vitalsの応答性指標の基準値と3区間・改善手順で詳しく扱っています。

CLSの原因になる寸法未指定の画像・Webフォント・後挿入の広告枠

CLSのattributionは、最も大きくずれた要素をlargestShiftTargetとして返します。CLSの公式解説が挙げる原因は、寸法が無い画像や動画、代替フォントと大きさが違うWebフォント、大きさが変わる広告や埋め込み、既存の内容の上に後から差し込まれる要素の4種類です。

画像と動画にwidthとheightを書き、描画前に枠を確保する
広告や埋め込みの枠に最小の高さを指定し、読み込み後に押し下げない
お知らせバナーは本文の上に差し込まず、上に重ねて表示する
動きを付けるときはtopやheightではなくtransformを変える

上から順に、直す手間に対して効き目が大きい項目です。寸法の指定漏れはHTMLを直すだけで済むので、最初に片付けます。

受託開発の視点で見るCore Web Vitals対策を優先すべきサイトと見送る場面

ここからは、サイトの改修を受ける立場からの判断です。対策に工数を割く価値があるかは、順位への効き方とサイトの状態で決まります。

SEOへの効き方の限界：合格しても順位が上がらない理由と線引き

Google検索とCore Web Vitalsの関係を説明した公式文書は、Core Web Vitalsをコアランキングシステムが考慮する要素の1つとしています。一方でページエクスペリエンスの公式解説は、良い結果が出ても上位表示は保証されず、SEOのためだけに満点を狙うのは有効な時間の使い方ではないと書いています。

同じ文書は、ページエクスペリエンスが平均を下回っても関連性の高いページが表示されるとも説明しています。つまり、内容で並んだ競合との間で差が付く要素であり、内容で負けている記事を合格だけで逆転させるものではありません。順位の改善が目的なら、インデックスやクロールの問題を先に潰すほうが効きます。その優先順位はテクニカルSEOとは？主要施策と優先順位つきチェックリスト【2026年版】で整理しています。

対策を優先する条件：モバイル流入が主で不良URLが流入上位にある場合

対策を先にやるべきなのは、Google Search Consoleで「低速」のURLグループが検索流入の上位ページを含み、かつ流入の大半がモバイルのサイトです。ECの商品一覧や予約フォームのように、操作の遅さが離脱と売上に直結する画面も優先します。この場合の判断材料は順位ではなく、遅い画面での離脱率とコンバージョン率です。

原因がテーマやタグマネージャー経由のスクリプトにあり、社内で回しきれないこともあります。どの画面のどの指標から直すかの洗い出しを任せたい場合は、Webコンサルティング・アクセス解析で計測の設計から改善の優先順位付けまでお受けしています。

見送る場面：CrUXに値が出ない小規模サイトとラボスコアだけの追い込み

CrUXに値が出ないほど訪問の少ないサイトでは、Google側に判定材料そのものがありません。月に数百訪問のコーポレートサイトで、Lighthouseのスコアを80点から95点に上げるための改修はやめておくべきです。その工数はコンテンツや導線に回したほうが成果につながります。

3指標とも「良好」のサイトでさらに数値を削る改修も見送ります。例外は、INPが200ミリ秒に近い画面に重い機能を足す予定がある場合で、そのときは先にweb-vitalsで画面別の値を取り始めます。

Core Web Vitalsのよくある質問：FID・スコア・計測期間の扱い

Core Web Vitalsの計測と対策について、2026年10月時点の公式ドキュメントをもとによくある質問に答えます。

LCPとは何の略で、何を測る指標ですか？

LCPはLargest Contentful Paintの略で、「最大コンテンツの描画」と訳されます。画面に見えている範囲で最も大きい画像やテキストが描かれるまでの時間を測る読み込みの指標で、2.5秒以内なら良好です。

FIDはまだ確認する必要がありますか？

確認は不要です。FIDは2024年3月にINPへ置き換えられ、Core Web Vitalsから外れました。web-vitalsライブラリでもv5.0.0でonFIDが削除されています。古い記事や社内資料で「FIDは100ミリ秒以下」と書かれていたら、INPの200ミリ秒以下の基準に読み替えてください。