Core Web Vitalsとは｜LCP・INP・CLSの基準と改善手順

Core Web Vitalsとは｜3つの指標と合格ライン

Core Web Vitalsは、ページ体験の質を「表示の速さ」「操作への反応」「表示の安定性」の3軸で数値化した指標群です。Googleの検索ランキングシステムが評価するページ体験の要素のひとつとして位置づけられています。詳細はGoogle検索セントラルのCore Web Vitals解説にまとまっています。

3つの指標が測っているもの

結論から言うと、3指標は「読み込み」「対話」「視覚的安定性」を1つずつ担当しています。

しきい値はweb.dev の Web Vitals 解説に記載されたものです。執筆時点では、この3指標がいずれも「Stable（安定）」の扱いになっています。

LCPで対象になるのは、ビューポート内で最も大きく描画された要素です。多くのサイトではヒーロー画像か見出しテキストが該当します。「ページ全体の読み込み完了」ではない点に注意してください。

INPは少し特殊です。FIDが「最初の入力に対する遅延」だけを見ていたのに対し、INPは滞在中に発生したクリック・タップ・キー入力といったインタラクションを対象に、代表的な遅延値で評価されます（操作回数が多いページでは外れ値が除外されます）。つまり、一部の重い操作がINP悪化の主因になりやすい、と考えてください。

CLSは「ずれた距離」と「ずれた面積の割合」を掛け合わせたスコアの累積です。単位がない無次元の数値なので、秒やミリ秒と同じ感覚で読まないようにしてください。

合格判定は「75パーセンタイル・28日間」で決まる

合否はページ単体の瞬間値ではなく、実ユーザーの訪問の75%がしきい値を満たしているかで判定されます。平均値ではありません。裏を返すと、遅い端末・遅い回線のユーザーが全体の25%を超えて存在すると、体感が良くても不合格になります。

Search Consoleのレポートは、Core Web Vitalsレポートのヘルプが示すとおり、直近28日間の計測値をもとにURLを「良好／改善が必要／不良」に振り分けます。ここで実務上きついのが、URLグループのステータスは、そのグループで最も悪い指標に合わせて決まるというルールです。LCPとINPが良好でもCLSが不良なら、そのグループは不良として扱われます。

修正後に「修正を検証」を開始しても、すぐに判定が変わるわけではありません。レポートは28日間のフィールドデータを前提に更新されるため、改善の反映には数週間かかると見積もっておくのが安全です。

Q. ページ単位で改善したのに、別のページまで不合格のままなのはなぜですか。

Search Consoleは似た構成のURLをグループ化して評価するため、同じテンプレートのページが一括で同じ判定になることがあります。テンプレート単位で直すのが結局いちばん早い、という結論になりやすい部分です。

ラボデータとフィールドデータの違いを先に押さえる

最初にここを押さえておくと、調査の空振りが減ります。結論は「判定はフィールド、原因調査はラボ」です。役割が違うので、数値がずれていること自体は異常ではありません。

Lighthouseが100点でもSearch Consoleで不合格になる理由

ラボデータは、固定された端末性能・回線条件でページを1回読み込んで計測した値です。対してフィールドデータは、実際のユーザーのブラウザから集めた計測値の集合で、Chrome ユーザー エクスペリエンス レポート（CrUX）として集計されています。

両者がずれる原因は、たいてい次のどれかです。

• 計測環境の差。ラボは安定した条件、実ユーザーは古い端末や混雑した回線を含む

• 操作の有無。Lighthouseはページを読み込むだけで、クリックもスクロールもしません。そのためINPはラボでは直接計測できず、代替指標（Total Blocking Time 等）で近似されます

• ログイン後やキャッシュ済みの再訪問など、ラボでは再現しにくい状態が実ユーザーには含まれる

• 集計方法の差。ラボは1回の値、フィールドは28日間の75パーセンタイル

特にINPは、「ラボで良い数値が出ても実ユーザーでは落ちる」が起きやすい指標です。INPの不合格は、フィールドデータを起点に見ないと優先順位を誤りやすいと考えてください。

ツールの使い分け

CrUXの更新粒度は、API・BigQuery・ダッシュボードのどれを参照するかで変わります。推移を追う場合は、参照手段を途中で切り替えないようにしてください。

実務では、Search ConsoleでどのURLグループが落ちているかを特定し、PageSpeed Insightsでどの指標が原因かを見て、Lighthouseや実機のDevToolsでコードのどこが原因かまで降りる、という流れが安定します。

自前のRUMを入れると、「どの要素がLCPになっているか」「どのイベントハンドラがINPを押し上げているか」まで取れるようになります。既存の監視基盤があるなら、そこに寄せるのが運用コスト的に無難です。監視SaaSの比較はNew Relicとは｜オブザーバビリティの基本・Datadogとの違い・案件動向で整理しています。

LCPの改善手順

LCPの改善は、感覚で画像を圧縮する前に内訳へ分解するのが近道です。

LCPを4つの内訳に分解する

web.dev のLCP最適化ガイドは、LCPを4区間に分け、理想的な時間配分の目安を示しています。

同ガイドが指摘しているとおり、LCPの大部分は「HTMLとLCPリソースを読み込んでいる時間」であるべきです。どちらも読み込んでいない空白の時間が、そのまま改善余地になります。まずこの4区間の実測値を出し、割合から外れている区間を叩くのが効率的です。

内訳別の打ち手

• TTFBが長い: キャッシュ戦略とCDNの見直しが中心になります。動的生成のページなら、静的化やエッジキャッシュで大きく縮むケースがあります。CDNの選定はCloudflareとは｜CDN・セキュリティ・Workersの特徴と案件動向が参考になります

• 読み込み遅延が長い: LCP要素がHTMLから発見されにくい状態です。CSSの背景画像やJavaScriptで差し込む画像はプリロードスキャナから見えません。img要素に置き換えるか、preloadで先出しします

• 読み込み時間が長い: 画像フォーマット（WebP・AVIF）、適切なサイズ配信、優先度の指定で縮めます。ファーストビューの主要なLCP画像に限って fetchpriority="high" を付けます。多くの画像に付けると優先度の差がなくなり逆効果になります

• レンダリング遅延が長い: レンダリングをブロックするCSSやJavaScriptが原因です。クリティカルCSSの分離、非同期読み込み、フォント読み込み方式（font-display）の見直しが効きます

よくあるのが、遅延読み込み（lazy loading）をページ全体に一括適用してしまい、ファーストビューの画像まで後回しになっているパターンです。LCP要素だけは遅延読み込みの対象から外してください。

INPの改善手順

INPは「JavaScriptが重い」で片づけず、3区間に分けると打ち手が決まります。

INPを3つの内訳に分解する

web.dev のINP最適化ガイドは、操作の遅延を次の3つに分解しています。

1. 入力遅延: 操作が発生してから、イベントコールバックが動き始めるまで。メインスレッドが他の処理で塞がっていると伸びます

2. 処理時間: イベントコールバックが最後まで走り切るまでの時間

3. 表示遅延: 操作結果を含む次のフレームをブラウザが描画するまでの時間

区間によって原因がまったく違います。入力遅延が長いならページ読み込み時のスクリプト評価やサードパーティタグ、処理時間が長いなら自前のハンドラ、表示遅延が長いならDOMの規模やレンダリングコストを疑います。

区間別の打ち手

入力遅延には、読み込み時の長いタスクを減らすことが効きます。バンドル分割、不要なポリフィルの削除、サードパーティスクリプトの遅延実行が基本線です。タグマネージャー、チャットウィジェット、ヒートマップ、A/Bテストツールは、初回描画前に動く必要がないものがほとんどです。

処理時間は、長いタスクを分割してメインスレッドを明け渡すのが定石です。目安として1つのタスクを50ミリ秒未満に抑えると、その間に入った操作が待たされにくくなります。実装としては、処理の途中で scheduler.yield() や setTimeout を挟んでタスクを切る方法があります。さらに、画面更新に直結しない処理は、requestIdleCallback などで後回しにすることを検討します（実行タイミングはブラウザ任せになるため、遅延が許容できる処理に限ります）。

加えて、視覚的な反応だけ先に返す設計が有効です。クリック直後にUIの状態だけ更新し、重い集計やAPI呼び出しは次のフレーム以降に回すと、INPの数値も体感も同時に良くなります。

表示遅延には、DOMサイズの削減とレンダリング範囲の限定が効きます。CSSの content-visibility を使うと、ビューポートに近づくまで描画処理を遅らせられます。無限スクロールや巨大なテーブルを持つ画面では、仮想スクロールの導入を検討する価値があります。

レイアウトスラッシング（スタイルの読み取りと書き込みを交互に繰り返して強制同期レイアウトを起こす状態）も、処理時間と表示遅延の両方を押し上げます。読み取りと書き込みをまとめる形に直してください。

Q. SPAの画面遷移はINPに含まれますか。

クリックから次の描画までが1回のインタラクションとして計測されるため、遷移直後の描画が重ければINPに乗ります。遷移時はスケルトンなどを即座に出し、本体のレンダリングを後続フレームに回す構成が有利です。

CLSの改善手順

CLSは原因のパターンが比較的限られているため、他の2指標より対処方針を立てやすい傾向があります。ただし広告配信や同意バナーのように、他部門の管轄が絡むと技術だけでは閉じません。

ずれを起こす典型的な原因

• 幅と高さが指定されていない画像・動画・iframe。読み込み後に領域が確保されて周囲が押し下げられる

• 広告・埋め込み・レコメンドなど、後から挿入される可変サイズの要素

• Webフォントの切り替え。代替フォントから本来のフォントに置き換わるときに行の高さや文字幅が変わる

• クライアント側で差し込まれるバナー・お知らせ・同意ダイアログ

• ユーザー操作を伴わないアニメーションで、レイアウトに影響するプロパティ（width・top など）を動かしている

打ち手

img要素には width と height を明示し、CSS側で aspect-ratio を使って比率を保持します。これだけで画像由来のずれはほぼ消えます。

後から挿入される要素には、min-height で先に場所を確保します。サイズが可変なら、取りうる最大高さではなく実測の中央値付近を確保しておくと、ずれの量を抑えつつ無駄な余白も減らせます。

フォントは font-display の挙動を把握したうえで、代替フォントのメトリクス調整（size-adjust、ascent-override 等）でずれ幅を詰めます。

アニメーションは transform と opacity に寄せます。この2つはレイアウトを再計算しないため、CLSには原則として計上されません。

なお、クリックやタップなどの操作に続いて短時間のうちに発生した一部のレイアウト変化は、CLSの対象外として扱われます（スクロールはここでいう操作に含まれません）。アコーディオンの開閉やモーダル表示のように、ユーザーが予期しているずれを無理に潰す必要はありません。

指標別の早見表と実践チェックリスト

症状から原因と打ち手を引けるようにまとめた表です。調査の入り口として使ってください。

デプロイ前後のチェックリストは次のとおりです。

1. Search Consoleで対象URLグループと、落ちている指標を特定した

2. PageSpeed Insightsでフィールドとラボの両方を確認し、乖離の有無を見た

3. 指標を内訳（LCPは4区間、INPは3区間）に分解し、どこが支配的かを数値で確認した

4. 修正前の数値を記録した（後で効果を説明するため）

5. LCP要素が遅延読み込みの対象に入っていないか確認した

6. 新規に追加したサードパーティスクリプトが、初回描画前に実行されていないか確認した

7. 変更後にLighthouseをCIで回し、他ページの回帰が起きていないか確認した

8. リリース後、少なくとも数週間〜28日程度は観測を継続する計画になっている

CIでの継続計測はGitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説の仕組みに乗せると、ページ追加のたびに手で測り直す必要がなくなります。

環境別につまずきやすいポイント

同じ指標でも、採用している構成によって詰まる場所が変わります。

SSR・SSG系フレームワーク

Next.jsやNuxtのようなフレームワークは、画像最適化やコード分割の仕組みを持っているため、LCPとCLSは比較的整えやすい構成です。一方で、ハイドレーション（サーバーで描画したHTMLにクライアント側でイベントを紐づける処理）が重いと入力遅延が伸びてINPが落ちるという形で跳ね返ります。見た目はすぐ出るのに押しても反応しない、という状態がこれです。

対策は、クライアント側で動かすコンポーネントを絞ることです。静的な部分までクライアントコンポーネントにしていないか、棚卸しする価値があります。構成の詳細はNext.jsとは？React基盤のフレームワークの特徴・できること・年収・将来性をフリーランス視点で解説、JavaScriptの配信量を抑える設計思想についてはAstroとは｜静的サイトジェネレーターの特徴・Next.jsとの違い・将来性を解説が参考になります。ホスティング側の配信・キャッシュ設定はVercelとは？特徴・Next.js連携・料金・案件動向をフリーランス視点で解説で触れています。

CMS・SPAで起きやすいこと

CMS系サイトでは、プラグインやタグが積み上がってスクリプトが肥大している状態が多く見られます。この場合、コードを書く前に何が読み込まれているかの棚卸しをするほうが効果が大きくなります。使われていないタグを1つ外すだけでINPが改善することもあります。

CSR中心のSPAでは、初期HTMLがほぼ空のためLCPが構造的に不利になります。重要な部分だけサーバーレンダリングに寄せる、あるいはスケルトンではなく実データを含むHTMLを先に返す方針を検討します。Reactの基礎はReactとは？初心者向け入門解説｜できること・人気の理由までにまとめています。大規模サイトで複数チームが同じページに乗り入れている場合、責任分界の設計自体が論点になります。その観点はマイクロフロントエンドとは｜分割方式・採用判断・運用コストと見送る基準で扱っています。

よくある失敗と対策

ラボの数値だけで「改善した」と報告する

Lighthouseのスコアが上がっても、合否を決めるのはフィールドデータです。報告の時点で「ラボでは改善、フィールドへの反映は28日窓の入れ替わり後に確認」と分けて伝えておくと、後から説明が食い違いません。これは技術的な問題というより、期待値調整の問題です。

反映を待てずに変更を重ねる

28日窓で集計されている以上、デプロイ翌日に数値が動かないのは当然です。ここで焦って別の変更を重ねると、どの変更が効いたのか分からなくなります。変更は区切って入れ、各リリースの日付を記録しておいてください。

スコアを追ってUXを壊す

CLSを下げるために大きな余白を常時確保する、INPのために機能を削る、といった対応は本末転倒になりやすい部分です。Core Web Vitalsはユーザー体験の代理指標であって、目的そのものではありません。数値と体感が食い違ったときは、体感側を優先して原因を洗い直すほうが結果的に早く着地します。

フリーランスエンジニアがCore Web Vitals改善を案件として受けるとき

結論として、公開案件を見る限りでは、Core Web Vitals改善は単独案件として募集されるより、フロントエンド改修・サイトリニューアル・SEO施策の要件の一部として記載されるケースが見られます。案件名で探すより、フロントエンド改善や表示速度改善といった文脈でも探したほうが、見つかる可能性があります。

スコープと成果定義を先に合意する

ここが最大の注意点です。Core Web Vitalsは自分の書いたコード以外の要因で落ちることが珍しくありません。広告タグ、計測タグ、サーバーの応答速度、他チームが追加したスクリプトなど、自分の権限外が原因のケースがあります。

そのため、契約前に次の点を確認しておくと揉めにくくなります。

• 成果の定義を「合格ステータスの達成」にするか、「指定した指標の数値改善」にするか

• サードパーティタグの削除・遅延実行に手を入れる権限があるか

• サーバー・CDN設定の変更権限があるか、別チームの管轄か

• 判定の反映に4週間以上かかる前提が、契約期間に織り込まれているか

• 計測の基準をどのツールの数値に置くか（Search Console／PageSpeed Insights／自前RUM）

特に4点目は見落とされがちです。1か月契約で「合格させる」を成果にすると、計測窓が入れ替わる前に契約が終わるという事態が起こり得ます。

単価の考え方と案件の探し方

パフォーマンス改善は、計測設計から原因特定、実装、効果検証までを一人で回せると評価されやすい傾向があります。フロントエンド実装だけでなく、CDNやサーバー側のキャッシュ、計測基盤まで触れると担当範囲が広がります。

フロントエンド領域の単価レンジや、経験年数による違いはフロントエンドエンジニアのフリーランス単価相場｜経験別・技術別レンジと動向で整理しています。単価の上げ方を体系的に押さえたい場合は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？もあわせてご覧ください。自分の経験でどのくらいの単価を狙えるか確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。実際の募集内容はフリコンの案件一覧から確認できます。

まとめ

Core Web Vitalsは、LCP 2.5秒以下・INP 200ミリ秒以下・CLS 0.1以下を実ユーザーの75パーセンタイルで満たすかどうかで判定される指標で、改善の出発点はラボ計測ではなくフィールドデータです。

• 合格ラインは3指標すべてを75パーセンタイルで満たすこと。1つでも不良なら不合格扱いになる

• 判定はフィールドデータ、原因調査はラボデータ。役割を分けて使う

• LCPは4区間、INPは3区間に分解してから打ち手を選ぶ。推測で画像圧縮やバンドル削減に走らない

• CLSは原因パターンが限られるため、領域の事前確保で機械的に潰せる

• 着手順はLCP、CLS、INPの順が進めやすい。INPは工数が読みにくいため最後に回す

• Search Consoleの判定は28日窓で集計される。効果の確認には数週間〜28日程度を見込む

• 案件として受ける場合は、権限範囲と成果定義、契約期間と計測窓の関係を事前に合意しておく

次のステップとしては、Search Consoleで落ちているURLグループを1つ特定し、PageSpeed Insightsで内訳を出すところから始めてください。原因が数値で見えた時点で、打ち手はほぼ決まります。

参照した一次情報は次のとおりです。

• Web Vitals（web.dev）

• Optimize Largest Contentful Paint（web.dev）

• Optimize Interaction to Next Paint（web.dev）

• Core Web Vitalsレポート（Search Consoleヘルプ）

• Core Web Vitals と Google 検索の検索結果（Google検索セントラル）