日本語
サイトをチェック

Core Web Vitals が不合格？LCP・INP・CLS の直し方

SEOgrinder 編集部 · 公開日 · 読了時間 約12分

結論： 「Core Web Vitals が不合格」とは、3つの指標のうち少なくとも1つが、実際の訪問者のデータで基準を満たしていないということです。LCP（読み込み）は2.5秒以内、INP（応答性）は200ミリ秒以内、CLS（視覚的な安定性）は0.1以下が基準で、いずれも75パーセンタイルで測ります。弱い指標は、ラボのスコアではなく、実際の訪問者のフィールドデータで探し、まずその1つを直します。Google は、ランキングシステムが Core Web Vitals を使っていると述べていますが、良い数値が上位表示を保証するわけではありません。

「Core Web Vitals が不合格」とはどういう意味か

Core Web Vitals は、Google の Web Vitals の取り組みのうち、すべてのウェブページに当てはまる部分です。web.dev は、体験の側面ごとに1つずつ、3つの指標を挙げています。

指標測るもの良好な値
LCP（Largest Contentful Paint）読み込み：表示領域内で最大の画像、テキストブロック、動画が表示されるタイミング2.5 秒以内
INP（Interaction to Next Paint）応答性：クリック、タップ、キー入力に、ページが目に見えて反応するまでの速さ200 ミリ秒以内
CLS（Cumulative Layout Shift）視覚的な安定性：ページを使っている間に、見えているコンテンツがどれだけ動き回るか0.1 以下

値は、ページ読み込みの75パーセンタイルで、モバイルとデスクトップを別々に評価します。平たく言えば、4回の訪問のうち3回で値が良好でなければならず、モバイルとデスクトップには、それぞれ別の判定が出ます。web.dev は、3つすべての指標で、75パーセンタイルの目標を満たしたページを、ツールが合格と数えるよう求めています。つまり、赤い指標が1つあれば、不合格になります。

基準線の細かい点があります。web.dev は、INP と CLS を「以下」と書いていますが、Google の検索のドキュメントは「200 ミリ秒未満」「0.1 未満」と書いています。基準線をはっきり下回ることを目指せば、この違いは問題になりません。

知っておくべき変更が1つあります。INP は、2024年3月に、Core Web Vitals として First Input Delay（FID）に代わりました。web.dev の告知にあるとおりです。FID をまだ挙げているガイドは、古くなっています。この記事で挙げたページは、すべて2026年11月4日に読みました。web.dev の概要ページの最終更新は、2024年10月31日です。

Core Web Vitals は Google の順位に影響するか

Google によれば影響しますが、重みは示していません。Google のページエクスペリエンスのページには、“Core Web Vitals are used by our ranking systems.”（Core Web Vitals は、当社のランキングシステムで使われている）とあります。Google は、検索で成功するために良い値を勧めており、ページエクスペリエンスには単一のシグナルはない、とも書いています。

同じページは、限界についても同じくらいはっきり書いています。Search Console の Core Web Vitals レポートやサードパーティのツールで良い結果が出ても、それは “doesn't guarantee that your pages will rank at the top of Google Search results”（ページが Google 検索結果の上位に表示されることを保証するものではない）とされています。SEO のためだけに満点を追い求めるのは、時間の使い方として最善ではないかもしれない、とも書かれています。ページエクスペリエンスが悪くても、Google は常に、最も関連性の高いコンテンツを表示しようとします。

Google が公開していないのは、指標の重みです。そのため、私たちも数値は挙げません。以下は私たちの解釈であって、Google の発言ではありません。基準値は、訪問者に対する品質のラインとして扱い、3つすべてを「良好」に入れてから、時間をコンテンツに戻しましょう。Google のコアランキングシステムは、一般にコンテンツをページ単位で評価します。そのため、重要なページの種類ごとに確認してください。

ラボデータとフィールドデータ：Core Web Vitals で重視されるのはどちらか

評価の基になるのは、実際の訪問を測ったフィールドデータです。Google の Chrome User Experience Report（CrUX）が、実際の Chrome ユーザーからそれを集めていて、PageSpeed Insights と Search Console の Core Web Vitals レポートがそれを表示します。web.dev によれば、CrUX のレポートは28日間を対象とします。

ラボデータは、管理された環境でページを1回読み込んで得られます。デバイス1台、ネットワーク1つ、場所1か所です。原因を見つけたり、公開前に修正をテストしたりするには最適ですが、LCP のガイドは、“lab tests alone may not be entirely representative”（ラボテストだけでは、完全に代表的とは限らない）と注意しています。両者が食い違うときは、まず実際のユーザーデータに集中するよう、LCP のガイドが述べています。食い違うのには、もっともな理由があります。

  • LCP の要素が違うことがある。 ラボの実行では、いつも同じ要素が見つかります。実際の訪問では、画面サイズが違ったり、ログイン後のコンテンツがあったり、A/B テストがあったりします。
  • INP には実際の人が必要。 Lighthouse などのラボツールは、誰もクリックしないままページを読み込むので、INP を測れません。ラボでの代わりは、Total Blocking Time（TBT）です。TBT を改善すると、INP も改善することがあります。
  • CLS は読み込み後も数え続ける。 ラボの実行で見えるのは、ほとんど読み込みの途中だけです。実際の訪問では、訪問者のスクロール中に現れるコンテンツも、レイアウトをずらすことがあります。
  • キャッシュは実際の訪問者を助ける。 ラボテストは、たいてい空のキャッシュから始まります。再訪した訪問者や、戻る・進むのキャッシュ（bfcache）では、ページがより速く読み込まれます。

数値を読む手順は、次の4つです。

  1. PageSpeed Insights でアドレスを実行する。 英語表示では、“Discover what your real users are experiencing” のセクションにフィールドデータが、“Diagnose performance issues” にラボの実行結果があります。
  2. 見ているものを確認する。 モバイルとデスクトップ、単一の URL とオリジン全体を切り替えます。ある URL のデータが少なすぎる場合、PageSpeed Insights は、代わりにオリジンのデータを表示します。
  3. 75パーセンタイルで基準線を超えている指標を見つける。 それが、不合格の指標です。訪問が少なすぎると、フィールドデータはありません。その場合は、ラボの値を使い、web.dev の小さな web-vitals ライブラリで、自分の訪問者を測ります。
  4. その指標のラボ診断を開き、 原因を確かめて、まずその1点を直します。

LCP の直し方：最大の要素の表示が遅い

LCP は、表示領域内で最大の画像、テキストブロック、動画が描画されるタイミングを報告します。web.dev の LCP のガイドは、その時間を、合計が LCP になる4つの部分に分けています。サーバーの応答（TTFB）、ブラウザーが LCP のリソースの読み込みを始めるまでの遅延、そのリソースの読み込みにかかる時間、そして要素が描画されるまでの遅延です。何かを変える前に、最も大きい部分を見つけてください。1つの部分を縮めても、時間がほかの部分に移るだけのことがあるからです。圧縮した画像は、スクリプトが読み込まれるまで要素が隠れたままなら、役に立ちません。

Chrome チームの最も効果的な修正のリストには、次のものが含まれています。

  1. LCP の画像を見つけやすくし、優先度を与える。 src または srcset を持つ通常の <img> を使い、JavaScript が必要な data-src は使いません。ページをブラウザー内だけで組み立てるより、サーバー側レンダリングを選びます。fetchpriority="high" を追加し、この1つの画像から loading="lazy" を外します。
  2. サーバーの応答を短くする。 コンテンツを訪問者の近くから配信し、キャッシュします。たいていは CDN を使います。

同じタグが LCP を扱い、サイズの指定を通じて CLS も扱います。

<!-- メイン画像：HTML 内に置き、優先度は高く、lazy にせず、サイズを指定する -->
<img src="/img/hero.webp" width="1200" height="630" alt="短い説明" fetchpriority="high">

<!-- ページの下のほうの画像：ここでは遅延読み込みで問題ない -->
<img src="/img/team.webp" width="600" height="400" alt="短い説明" loading="lazy">

INP の直し方：ページの反応が遅い

INP は、訪問中のすべてのクリック、タップ、キー入力を観測し、おおよそ最も遅いものを報告します（インタラクションが非常に多いページでは、外れ値は無視されます）。ホバーとスクロールは数えません。INP のガイドによれば、各インタラクションは3つの部分からなります。入力の遅延、イベントハンドラーが実行される時間、そして次のフレームが表示されるまでの遅延です。原因として多いのは、JavaScript がメインスレッドを占有していることです。Chrome チームの主な修正は、次のとおりです。

  1. 長いタスクを分割する。 50ミリ秒を超えるタスクは、メインスレッドをブロックします。制御をこまめに返します。ブラウザーが対応していれば scheduler.yield() を、従来の方法としては setTimeout を使います。
  2. 配信する JavaScript を減らす。 Chrome DevTools のカバレッジツールで未使用のコードを見つけ、最初は不要なコードを分割し、タグマネージャーの古いタグを整理します。
  3. 大きなレンダリングの更新を避ける。 DOM を小さく保ち、強制レイアウトを避け、画面外のコンテンツには CSS containment を使います。

CLS の直し方：レイアウトがずれる

CLS には単位がありません。見えているコンテンツがどれだけ動いたかと、どれだけ遠くへ動いたかを組み合わせた値です。実際の訪問では、訪問全体にわたって数えますが、ユーザーの操作から500ミリ秒以内に起きたずれは除外されます。web.dev の CLS のガイドは、よくある原因を挙げています。サイズを指定していない画像、広告、サイズを指定していない埋め込みや iframe、動的に挿入されるコンテンツ、そしてウェブフォントです。効果のある対策は、次のとおりです。

  • スペースを確保する。 画像と動画に width と height を指定するか、CSS の aspect-ratio プロパティを使います。サイズが分からないコンテンツには、初期値のゼロより、適切な min-height のほうが役に立ちます。
  • transform でアニメーションさせる。 top、left、margin をアニメーションさせると、レイアウトがずれます。スライドして現れる Cookie バナーが、典型的な例です。
  • 戻る・進むのキャッシュを働かせる。 これは、描画が完了したページを復元します。よくある妨げは、no-store のキャッシュ指示と、unload イベントのリスナーです。
  • ウェブフォントを扱う。 font-display: optional、size-adjust で寸法を合わせた代替フォント、重要なフォントの先読みは、いずれもフォントに起因するずれを減らします。

SEOgrinder が Core Web Vitals をチェックする方法

SEOgrinder は私たちのツールで、私たちが開発しています。SEOgrinder に公開アドレスを入力すると、速度の数値は Google PageSpeed Insights から取得され、モバイルとデスクトップの両方が表示されます。「Core Web Vitals」カードは、LCP と CLS を Lighthouse のラボの実行から、INP を実際の訪問者から表示し、別のボックスには、過去28日間の実際のユーザーデータが表示されます。Google がそのページのデータを十分に持っていない場合、レポートは推測せずに、そのことを伝えます。「モバイルの実際の訪問者はコンテンツの表示まで … 待っています」のようなタスクは、指標、値、対処を示します。LCP に影響するサーバーの応答の遅さには、専用のタスク「サーバーの応答が遅いです」があります。

制限もあります。SEOgrinder は Google の数値を読み取るもので、自分自身での実ユーザーの計測の代わりにはなりません。順位は測りません。速度計測の Google の1日あたりの割り当てを使い切っている場合、レポートにはその部分が含まれません。

よくあるミス

  • ラボのスコアだけを信用する。 ラボのスコアは INP を測れず、訪問者の体験とは違って見えることがあります。まず、実際の訪問者の値から始めましょう。
  • デバイスを1つしか確認しない。 モバイルとデスクトップは、別々に評価されます。
  • メイン画像を lazy 読み込みにする。 LCP の画像に loading="lazy" を付けると、遅延が増えます。
  • 画像のサイズを書かない。 width と height がないと、ブラウザーはスペースを確保できません。
  • LCP の間違った部分を直す。 画像を圧縮するのは、内訳を見て読み込み時間が問題だと分かってからにします。
  • すぐに結果が出ると期待する。 フィールドデータは28日間を対象とするので、変化は少しずつです。修正の直後はラボの実行結果を、そのあとの数週間は実際の訪問者の数値を確認しましょう。

よくある質問

Core Web Vitals で、良いスコアとはどのくらいですか？

単一のスコアはありません。75パーセンタイルで、LCP が 2.5 秒以内、INP が 200 ミリ秒以内、CLS が 0.1 以下なら、ページは合格です。Lighthouse でおなじみの0から100の数字は、ラボの値で、別のものです。

PageSpeed Insights に、自分のサイトの実際のユーザーデータが表示されないのはなぜですか？

たいていは、CrUX が報告するには訪問が少なすぎるためです。その場合、web.dev は、実際の訪問者の独自の計測を追加することを勧めています。それまでは、ラボの値をもとに作業してください。

満点は必要ですか？

いいえ。目標は、合格することです。Google 自身も、SEO のためだけに満点を追い求めるのは、時間の使い方として最善ではないかもしれないと述べています。

次のステップ

いちばん重要なページを SEOgrinder にかけ、「Core Web Vitals」カードを開いて、まず実際の訪問者の値を見てください。不合格になっている指標を1つ直し、「再チェック」を押して、ラボの値を読みます。全体像は、SEOチェックリストの記事にあります。

あわせて読みたい

ブログのほかの記事