Search Consoleを開いたら「ウェブに関する主な指標」が赤く表示されていた。
そんな経験はないでしょうか。
Core Web Vitalsは、サイトの使い心地を数値化したGoogleの指標です。
略語が並ぶため難しく見えますが、見ているのは3つだけです。
この記事では、各指標の意味と公式の基準、そして具体的な改善方法を整理します。
Core Web Vitalsは、ページの使い心地を測るためにGoogleが定めた3つの指標です。
いずれも、実際にサイトを使ったときにユーザーが感じるストレスを数値化したものです。
Core Web Vitalsは、ページエクスペリエンスを構成するシグナルのひとつとして検索の評価に関わっています。
ただし、これだけで順位が決まるわけではありません。
Googleは、コンテンツの品質が高いページは、この指標のスコアが低くても上位に表示されうるとしています。
補助的なシグナルという位置づけです。
また、3指標すべてが「良好」に到達したあと、さらに数値を伸ばしても追加の恩恵が得られるわけではありません。
つまり、目指すべきは満点ではなく基準を満たすことです。
コンテンツの質が拮抗している場面での差別化要因、と捉えるのが実態に近い理解になります。

各指標には「良好」「改善が必要」「不良」を分ける閾値が定められています。
ページの読み込みが始まってから、画面内で最も大きな要素が表示されるまでの時間です。
大きな画像や見出し、記事本文などが対象になります。
ユーザーが「ページが表示された」と感じる瞬間に最も近い指標です。
良好の基準は2.5秒以内。
4.0秒を超えると「不良」と判定されます。
ボタンをクリックした、フォームに入力したといった操作に対して、画面が反応するまでの速さです。
良好の基準は200ミリ秒以内。
500ミリ秒を超えると「不良」と判定されます。
INPは、2024年3月にFID(First Input Delay)に代わって導入されました。
FIDは「最初の操作」に対する反応だけを測っていました。
INPは、ページを開いてから離れるまでのすべての操作を対象にします。
解説記事によってはFIDのまま書かれているものもあります。
情報を参照する際は、いつの時点のものかを確認してください。
ページの読み込み中に、表示位置が予期せずずれる量を測る指標です。
読んでいたテキストが下にずれる、押そうとしたボタンが動く。
こうした体験を数値化しています。
良好の基準は0.1以下。
0.25を超えると「不良」と判定されます。
ここは見落とされがちな点です。
これらの基準は、全アクセスのうち75%がその値を満たしているかで判定されます。
平均値ではありません。
また、モバイルとデスクトップは別々に評価されます。
「自分の環境では速いのに不良と出る」という場合、回線やデバイスの遅い環境からのアクセスが足を引っ張っている可能性があります。
参照:Web Vitals(web.dev)/ウェブに関する主な指標のしきい値の定義方法(web.dev、いずれも2026年8月時点)

「ウェブに関する主な指標」レポートで、サイト全体の状況を確認できます。
モバイルとデスクトップそれぞれについて、「良好」「改善が必要」「不良」のURL数が表示されます。
まずここを見て、どの程度の規模の問題なのかを把握してください。
URLを入力すると、そのページのスコアと具体的な改善提案が表示されます。
個別ページの原因を掘り下げたいときに使います。
ブラウザに組み込まれている診断機能です。
開発中やテスト環境での確認に向いています。
制作会社に改善を依頼する際、具体的な指摘の根拠として使えます。
この2つを混同すると、判断を誤ります。
Search Consoleが示すのはフィールドデータです。
Lighthouseはラボデータです。
順位評価に使われるのはフィールドデータです。
Lighthouseのスコアが良くても、Search Consoleが「不良」と出ることはあります。
改善の判断はフィールドデータで、原因の特定はラボデータで。
この使い分けを押さえてください。
あわせて読みたい:Search Consoleの使い方
「不良」と出ても、慌てなくて大丈夫です
原因の多くは、画像とスクリプトに集中しています。
どこから手をつけるかの判断が、最も重要です。
LUPINAは計測から改善の実装までご一緒します。
ご相談は無料です。しつこい営業は行いません。

LCPが遅い原因の多くは画像です。
ただし注意点があります。
ファーストビューの画像に遅延読み込みを設定すると、LCPは逆に悪化します。
画面上部の主要な画像は、優先的に読み込ませてください。
不要なコードを削除し、ファイルを圧縮します。
そのうえで、表示に必要なものを優先的に読み込み、それ以外は後回しにする設定を行います。
WordPressの場合、使っていないプラグインが読み込みを重くしているケースが少なくありません。
まずプラグインの棚卸しから着手すると、効果が出やすくなります。
サーバーの反応が遅ければ、どれだけ画像を軽くしても限界があります。
共用サーバーの低価格プランを使っている場合、上位プランへの変更だけで改善することもあります。
ブラウザは、画面の描画もJavaScriptの実行も「メインスレッド」という1本の処理で行っています。
ここが重い処理で塞がっていると、クリックしても反応できません。
時間のかかる処理は分割し、途中でユーザーの操作に応答できるようにします。
一度に大量のJavaScriptを実行すると、その間ページは操作を受け付けられません。
不要な処理を削り、実行を分散させることで応答性が改善します。
広告、アクセス解析、チャットツール、SNS埋め込み。
これらの外部スクリプトは、積み重なるとINPに大きく影響します。
まず本当に必要なものだけを残すという判断をしてください。
そのうえで、残すものは非同期または遅延読み込みに設定します。
「昔入れたまま使っていないタグ」が残っていることは、実際によくあります。
CLSの最大の原因はこれです。
サイズが指定されていないと、ブラウザは読み込むまで必要な領域が分かりません。
結果、表示された瞬間にレイアウトが押し下げられます。
<img> タグに width と height を記述してください。
広告枠についても、あらかじめ領域を確保しておきます。
Webフォントの読み込みが遅れると、まず標準フォントで表示され、後から切り替わる際に文字の大きさや位置が変わります。
CSSの font-display プロパティで、この挙動を制御できます。
Cookie同意バナー、お知らせ、遅れて表示されるウィジェット。
これらが既存の内容を押し下げる形で表示されると、CLSが発生します。
CSSの min-height などで、あらかじめ領域を確保しておいてください。

すべてを同時に改善する必要はありません。
すでに2.5秒を切っているページをさらに速くする労力より、4.0秒を超えているページを基準内に入れるほうが、体験にも数値にも効きます。
多くのサイトで、モバイルのほうが数値は厳しくなります。
アクセスの構成比を確認したうえで、比率が高いほうから着手してください。
技術的に難しい施策から入る必要はありません。
画像の圧縮と、使っていないプラグインの削除。
この2つだけで改善するケースは多くあります。
自社で対応できない領域は、制作会社への依頼になります。
その際、PageSpeed InsightsやLighthouseの結果を添えて依頼してください。
「サイトが重い」と伝えるより、具体的な指標と該当URLを示すほうが、話が早く進みます。

Core Web Vitalsで見ているのは、読み込みの速さ、操作への反応、表示の安定性の3つです。
基準は、LCPが2.5秒以内、INPが200ミリ秒以内、CLSが0.1以下。
満点を目指す必要はなく、この基準を満たせば十分です。
また、これだけで順位が決まるわけではありません。
コンテンツの質が前提にあったうえでの、補助的な要素だと捉えてください。
まずはSearch Consoleの「ウェブに関する主な指標」を開き、「不良」と判定されているURLがあるかを確認してみてください。
そこが出発点になります。
Contact
まだ届いていない価値を、
共に見つけ、共に創り、共に届ける。
LUPINAは、市場調査・戦略設計・サイト制作・記事制作・運用・計測までを社内で一貫して手がけています。技術的な改善から、コンテンツの成果まで通して支援します。
Results
検索経由のサイト流入
前年比 281%
対策キーワードの10位以内比率
18% → 47%
※不動産業界のクライアント/2025年3月〜2026年3月の実績
ご相談・お見積りは無料です。サービス内容はこちら