Core Web Vitalsとは｜表示速度を改善してSEOを強くする方法

「順位が上がらない」「サイトが重いと言われるが何を直せばいいか分からない」——その突破口がCore Web Vitals（コアウェブバイタル）、表示速度を含むページ体験の指標です。本記事はその意味、SEOへの影響、改善方法を実務目線で解説します。全体像は内部SEO対策もどうぞ。

Core Web Vitalsとは｜表示速度を含むページ体験の3指標

Core Web Vitals（コアウェブバイタル）とは、Googleが定めたユーザーの実際のページ体験を測定するための指標のことです。具体的には、ページが「速く表示されるか」「操作にすぐ反応するか」「表示が安定しているか」という3つの観点を、それぞれ数値で評価します。単にサーバーが返す速度ではなく、訪問者が体感する快適さを測るものだと考えると分かりやすいでしょう。

Googleがこの指標を重視するのは、遅く操作しづらいページがユーザーの不満と離脱に直結するからです。あるデータでは、表示が1秒から3秒に遅くなるだけで直帰率は約32%増加し、1秒から6秒では約2倍に跳ね上がるとされます。Core Web VitalsはGoogleのためというより訪問者を逃さないための指標であり、その改善はSEOと成約率の両方に効きます。

3つの指標｜LCP・INP・CLS

Core Web Vitalsは、LCP（読み込みの速さ）、INP（反応の速さ）、CLS（表示の安定性）という3つの指標で構成されます。それぞれに「良好」「改善が必要」「不良」の3段階の目安が定められており、原則としてすべての指標で「良好」を満たすことが目標になります。まずは各指標が何を測り、どの数値を目指せばよいのかを表で押さえましょう。

指標	何を測るか	良好の目安	改善が必要／不良
LCP（Largest Contentful Paint）	表示速度。ページ内で最も大きなコンテンツ（多くは画像や見出し）が表示されるまでの時間	2.5秒以内	2.5〜4.0秒＝要改善／4.0秒超＝不良
INP（Interaction to Next Paint）	反応性。クリックやタップなどの操作に対し、画面が反応するまでの時間	200ミリ秒未満	200〜500ms＝要改善／500ms超＝不良
CLS（Cumulative Layout Shift）	視覚的な安定性。読み込み中に表示要素が予期せずずれる量（レイアウトのずれ）	0.1未満	0.1〜0.25＝要改善／0.25超＝不良

3つのうち「表示速度」に最も近いのがLCPで、これが遅いと「重いサイト」という印象になります。INPは操作への反応の速さで、2024年3月にFID（First Input Delay）に代わって正式な指標となりました。CLSは、読み込み中に要素がずれて誤タップを招く「レイアウトのずれ」の大きさです。この3つは測る対象が異なるため、それぞれに応じた改善が必要だという点をまず押さえてください。

Core Web VitalsのSEOへの影響

Core Web Vitalsは、Googleが公式に認める検索順位のランキング要因の一つです。「ページエクスペリエンス」の一部として評価に組み込まれ、速く快適なページを一定程度優遇すると明言されています。ただしこれだけで順位が決まるわけではない点に注意が必要です。順位を最も左右するのは依然としてコンテンツの質や関連性であり、Core Web Vitalsは「内容が同等なら体験の良いページを優先する」というタイブレーカー（同点決着）的な役割と捉えるのが実態に近いでしょう。

影響は順位への直接効果だけではありません。速くずれの少ないページは離脱率が下がり、回遊や滞在時間が伸び、問い合わせや購入といった成約率（CVR）まで改善します。この「ユーザー行動の改善」がサイト全体の評価を押し上げるため、改善は直接・間接の両面でSEOに効くと理解するのが正確です。順位への直接的な加点がわずかでも、遅いページを放置して失う訪問者と成約の損失は小さくありません。SEO全体の進め方はSEO対策とはで体系的に解説しています。

もう一点、Core Web Vitalsはモバイル（スマートフォン）での体験が特に重視される点です。Googleは評価基準をモバイル版に置く「モバイルファーストインデックス」を採用し、多くのサイトでアクセスの過半数がスマートフォン経由です。パソコンで速くても、スマートフォンでは通信環境や端末性能の制約で大きく遅くなることは珍しくありません。改善ではまずモバイルのスコアを基準に判断することが重要です。裏を返せば、モバイルで快適なページはそれだけで多くの競合に差をつけられます。

自サイトのCore Web Vitalsを測る方法

改善の前に、まず自サイトの現在地を正しく測ることが出発点です。感覚で判断せず、無料ツールで数値化します。記録しておけば改善後の変化を客観的に検証でき、社内やクライアントへの説明もしやすくなります。ここでは実務で使う3つのツール——PageSpeed Insights・Search Console・Lighthouse——の役割と使い方を整理します。いずれもGoogleが提供・連携する無料ツールで、専門知識がなくてもスコア確認までは行えます。

PageSpeed Insights（まず使うべき基本ツール）

最も手軽で、最初に使うべきなのがGoogle公式の無料ツールPageSpeed Insightsです。使い方は簡単で、ツールのページを開き、調べたいページのURLを入力して「分析」ボタンを押すだけ。数十秒で、モバイルとパソコンそれぞれのスコア（0〜100点）と、LCP・INP・CLSの実測値、そして「改善できる項目」の具体的なリストが表示されます。

重要なのは、結果に2種類のデータが表示される点です。実際の訪問者の体験を集計した「フィールドデータ（実測値）」と、その場で疑似測定する「ラボデータ」です。合否判定に使われるのはフィールドデータで、過去28日間の実ユーザーの記録に基づきます。ラボデータは改善の手がかりを得る参考値、と役割を分けて見るのがコツです。

Search Console（サイト全体をまとめて把握）

個別ページではなくサイト全体のCore Web Vitalsの状況を把握したいときは、Google Search Consoleの「ウェブに関する主な指標（Core Web Vitals）」レポートを使います。ここでは、サイト内のURLが「良好」「改善が必要」「不良」のどれに分類されるかがモバイル・PC別にまとめて表示され、問題のあるページ群をURLのまとまり単位で発見できます。「どのページから手をつけるべきか」を判断する起点として最適です。Search Consoleの基本的な使い方はSEOチェックのやり方でも触れています。

Lighthouse（開発者向けの詳細診断）

より踏み込んだ診断をしたい場合は、Chromeブラウザに標準搭載されているLighthouseを使います。ページ上で検証ツール（デベロッパーツール）を開き、Lighthouseタブから測定すると、パフォーマンスの詳細な内訳と改善提案がレポートとして得られます。エンジニアが原因を切り分ける際に有効なツールです。3つのツールの使い分けは次の通りです。

ツール	主な用途	見られるもの	使いどころ
PageSpeed Insights	個別ページの測定	スコア・LCP/INP/CLS実測値・改善項目	まず現状把握。改善の入口として最適
Search Console	サイト全体の把握	良好／要改善／不良のURL数と分布	どのページ群から着手するか判断する
Lighthouse	詳細な原因診断	パフォーマンスの内訳・技術的提案	エンジニアが原因を深掘りする

実務の流れとしては、Search Consoleで問題のあるページ群を見つけ→PageSpeed Insightsで個別に測定し→改善後に再測定してスコアの変化を確認する、という順序が基本です。改善は「測って、直して、また測る」の繰り返しであり、最初に必ず数値を記録しておくことが後の効果検証を可能にします。

LCP（表示速度）の改善策

3指標のなかで、最も「重さ」に直結し、改善効果も大きいのがLCPです。LCP要素の大半は画像であり、あるデータではLCP要素の75%以上が画像だとされています。つまり画像の最適化が、表示速度改善の最重要ポイントです。LCPを遅くしている主な原因と対策を表で整理します。

原因	改善策	目安・ポイント
画像が重い	画像を圧縮し、次世代フォーマット（WebPなど）に変換する。表示サイズに合わせてリサイズする	圧縮と形式変換だけで大きく改善する例が多い
サーバー応答が遅い	サーバーのスペック見直し・プランのアップグレード、プログラムの最適化。表示速度に強いサーバーを選ぶ	TTFB（最初の応答）は0.8秒以内が理想
キャッシュが効いていない	ブラウザキャッシュ・サーバーキャッシュを設定し、再訪問時の読み込みを高速化する	再訪ユーザーの体感速度が大きく向上
不要なJS・CSSが多い	使っていないコードを削除・圧縮し、読み込みを後回し（遅延）にする。重要なCSSは先読みする	表示をブロックする要素を減らす
メイン画像に遅延読み込み	最初に見える画像（LCP要素）には遅延読み込みをかけない。逆に先読みを設定する	一律のLazy LoadはLCPを悪化させる

特に注意したいのが、表最下段の「メイン画像への遅延読み込み」です。Lazy Loadをサイト全体に一括適用すると、最初に表示されるメイン画像にまで遅延がかかり、かえってLCPが悪化します。遅延読み込みは「画面外の画像」に限って使うのが鉄則です。着手順は、効果の大きい画像の圧縮・フォーマット変換→サーバーとキャッシュ→不要コードの整理、が効率的です。

INP（反応性）の改善策

INPは、ユーザーがボタンをクリックしたりフォームに入力したりしたときに、画面が反応するまでの速さを測る指標です。反応が鈍いページは「固まった」「押しても動かない」というストレスを与えます。INP悪化の根本原因は、多くの場合JavaScriptがブラウザの処理（メインスレッド）を長時間占有していることにあります。改善の基本方針は「メインスレッドを空ける」ことで、具体策は次の通りです。

改善策	内容	効果
長い処理を分割する	時間のかかるJavaScript処理を小さな単位に区切り、合間にブラウザが操作へ反応できる余地をつくる	操作への反応が途切れにくくなる
不要なJSを削減・遅延	使っていないスクリプトを削除し、すぐ必要でないものは読み込みを後回しにする	メインスレッドの負荷そのものを減らす
外部スクリプトの見直し	広告・解析・チャットなど第三者提供のタグを棚卸しし、不要なものを外す	気づきにくい重さの原因を除去できる
CSSで実装できる処理はCSSに	アニメーションなどJavaScriptで書いている演出をCSSに置き換える	スクリプトの実行量を減らせる
重い処理を裏側に逃がす	計算量の多い処理をWeb Workerなど別の仕組みに移し、表示を担う処理を軽くする	操作反応を邪魔しなくなる

INPの改善は技術的な要素が強く、原因の特定にはエンジニアの関与が必要になる場面が多い領域です。まず取り組みやすいのは外部スクリプトの棚卸しで、過去に導入したまま使っていない広告タグや解析タグが反応を鈍らせているケースは少なくありません。「本当に必要なタグだけ残す」だけでも、体感の反応速度は改善します。

もう一つ、INPはフォームやボタン、絞り込みなど「操作の多いページ」ほど問題が表面化しやすい点です。記事を読むだけのページは良好に出やすい一方、商品検索やカート、予約フォームなどインタラクションの多いページでは、反応の遅さがそのまま離脱と機会損失につながります。「ユーザーがよく操作する重要ページ」を優先してINPを点検すると、投じた工数が成果に結びつきやすくなります。反応の鈍さはそのページのスクリプト量に比例するため、「本当に必要な機能か」を一つずつ見直すのが近道です。

CLS（レイアウトのずれ）の改善策

CLSは、ページの読み込み中に表示要素が予期せず動く「レイアウトのずれ」の大きさを測る指標です。記事を読もうとした瞬間に画像が読み込まれて文章が下にずれたり、押そうとしたボタンが広告の表示で動いて誤タップしたり——こうした不快な体験がCLSの悪化として数値に表れます。Web全体で見ると、CLS問題の約40%はサイズ未指定の画像が原因とされており、対策は比較的シンプルです。

ずれの原因	改善策	ポイント
画像のサイズ未指定	すべての画像・動画・埋め込み枠に幅（width）と高さ（height）を明示する	ブラウザが事前に表示領域を確保でき、ずれを防げる
広告・埋め込みの後読み	広告枠やSNS埋め込みなど後から表示される要素に、あらかじめ固定の表示領域を確保する	プレースホルダーで場所を先に押さえる
Webフォントの遅延	フォント読み込み時の切り替えでずれが出ないよう、表示方法（font-display）を調整する	文字の描画による揺れを抑える
アニメーションのずれ	位置やサイズを変える演出は、レイアウトを崩さない方法（transform）で実装する	周囲の要素を押しのけない動かし方にする

CLS対策の中心は、「表示される要素の場所を、読み込み前にあらかじめ確保しておく」という考え方に尽きます。とりわけ画像への幅・高さ指定は効果が大きく、既存サイトで属性が抜けている画像を補うだけで数値が改善する例が多く報告されています。3指標のなかでは比較的少ない工数で「良好」に近づけやすいのがCLSです。

盲点になりやすいのが、ページ上部に後から差し込まれる要素です。お知らせバーやクッキー同意の通知、キャンペーンの告知帯が読み込み後に現れると、本文全体が下へ押し下げられ、大きなレイアウトのずれとして計測されます。こうした要素は最初から表示領域を確保するか、本文を押し下げない形（重ねて表示など）で実装するのが定石です。CLSは軽視されがちですが、読もうとした瞬間に文章がずれる体験は大きなストレスとなり、誤タップによる離脱すら招く——数値以上に使い心地を左右する指標だと捉えておきましょう。

WordPressでの高速化のポイント

多くの中小企業サイトはWordPressで構築されており、Core Web Vitalsの改善もWordPress上で行うことになります。WordPressは拡張性が高い反面、プラグインの入れすぎやテーマの重さで速度が落ちやすいという特性があります。基本の勘所は、①高速化プラグイン（キャッシュ・画像最適化）を適切に導入する、②使っていないプラグインを削除する、③軽量なテーマを選ぶ、④画像を自動でWebP変換・圧縮する、という4点です。

注意したいのは、高速化プラグインをやみくもに複数入れると設定が競合し、かえって不安定になることです。「キャッシュ系は1つに絞る」「機能が重複するプラグインは入れない」といった整理が重要になります。また、多機能なテーマや、装飾目的で多数のプラグインを積み重ねたサイトは、それ自体が速度低下の温床です。「本当に使っている機能だけを残し、装飾より軽さを優先する」という引き算の発想が、WordPress高速化では効いてきます。WordPress特有の高速化・SEO設定の詳細はWordPressのSEO対策で個別に解説しているため、CMSがWordPressの方はあわせてご覧ください。本記事では、CMSを問わず共通する速度改善の考え方に絞って続けます。

改善の優先順位｜影響の大きさ×工数で決める

Core Web Vitalsの改善項目は多岐にわたるため、すべてを一度にやろうとすると手が止まります。限られた時間で成果を出すには、「効果の大きさ」と「かかる工数」の掛け算で優先順位をつけるのが鉄則です。一般的な優先順位の考え方を整理します。

優先度	取り組む内容	効果／工数
最優先	画像の圧縮・WebP変換・サイズ指定（LCPとCLSに同時に効く）	効果：大／工数：小
優先	キャッシュ設定、不要プラグイン・不要タグの削除	効果：中〜大／工数：小〜中
中	不要なJS・CSSの削減、遅延読み込みの適切な設定	効果：中／工数：中
後回しでよい	サーバー移転、JavaScriptの本格的なリファクタ（INP改善）	効果：大／工数：大

優先順位を誤ると、工数の大きいサーバー移転やコード改修に真っ先に手を出して疲弊し、肝心の画像対策が後回しになりがちです。まず着手すべきは効果が大きく工数の小さい「画像の最適化」で、LCP（表示速度）とCLS（ずれ）の両方に効くうえ、圧縮・変換・サイズ指定は少ない手間で実施できます。次にキャッシュ設定と不要要素の削除。サーバー移転やJavaScriptの大規模な作り替えは効果は大きいものの工数と専門性が要るため、手軽な施策でスコアを底上げしてから検討するのが現実的です。「軽い施策で7〜8割改善し、残りを専門的に詰める」順序が、費用対効果の高い進め方です。

【ワークスルー】遅いページを測定→改善→スコア改善まで

ここまでの考え方を、1本の流れで実演します。ある中小企業のサービス紹介ページが「モバイルで表示が遅い」と指摘された状態から、Core Web Vitalsを改善してSEO評価を取り戻すまでを追います（数値は一般的な水準の目安です）。

フェーズ	やったこと	結果
①測定（1週目）	PageSpeed Insightsで測定。モバイルスコア42点、LCP4.8秒（不良）、CLS0.28（不良）、INPは良好。Search Consoleでも同系ページ群が「不良」判定	主因は「重いメイン画像」と「サイズ未指定画像」と特定
②画像最適化（2週目）	メイン画像を圧縮しWebPに変換。全画像に幅・高さを指定。メイン画像の遅延読み込みを解除し先読みに変更	LCP4.8秒→2.3秒、CLS0.28→0.05に改善
③キャッシュ・軽量化（3週目）	キャッシュを設定。使っていない古いプラグインと解析タグ2つを削除。不要CSSを整理	再訪問時の体感速度が向上、スコアがさらに上昇
④再測定（4週目）	PageSpeed Insightsで再測定。フィールドデータの反映を待って合否を確認	モバイルスコア42点→88点。3指標すべて「良好」
⑤効果（1〜2ヶ月後）	表示が速くなり離脱率が低下。回遊と滞在時間が改善し、Search Consoleの判定も「良好」に	直帰率が下がり、問い合わせ数が改善

この例で効いたのは、いきなり難しいJavaScript改修に走らず、「画像」という効果の大きいポイントから着手したことです。圧縮・変換・サイズ指定というシンプルな対策だけでLCPとCLSが同時に「良好」へ到達し、スコアの大半が改善しました。難所のINPは元々良好で後回しにでき、少ない工数で最大の効果を得られたのです。「測って原因を特定し、効果の大きい順に直す」——この基本を守るだけで、専門知識が十分でなくても多くのサイトは短期間で改善できます。

AI×人でCore Web Vitalsを継続的に改善する

ここまで読んで、「やることは分かったが、測定・改善・再測定を継続するのは大変だ」と感じた方も多いはずです。実際、Core Web Vitalsは一度直せば終わりではなく、記事の追加や機能の変更のたびに悪化しうるため、継続的な監視と改善が欠かせません。ここで役立つのがAIと人の役割分担です。

当社は、自社で運営するメディア事業において、この継続改善のプロセスにAI活用を組み込んできました。具体的には、スコアの定点測定、改善項目の洗い出し、画像の圧縮・変換といった定型作業、レポート化など「量が多く手順が決まった工程」をAIと自動化で下処理し、どの施策を優先するかの判断、サーバー・テーマ構成の設計、原因の切り分けといった「判断と専門性が問われる工程」を人が担う——この分担を業務フローとして設計しました。その結果、自社メディア運営で月686時間分の業務削減を実現しています。

重要なのは、Core Web Vitalsの改善は「単発の施工」ではなく「運用」だという点です。AIは測定・下処理・監視の高速化には絶大な効果を発揮しますが、優先順位づけや原因究明といった判断の質は人が握るべきです。この「AIで効率化しつつ、判断は人が担保する」設計を、当社ではそのままクライアントの内部SEO対策・表示速度改善の支援に応用しています。「サイトが重いと言われるが手が回らない」「どこから直せばいいか分からない」という方は、お気軽にご相談ください。

まとめ

Core Web Vitalsとは、LCP（表示速度）・INP（反応性）・CLS（レイアウトのずれ）でページ体験を数値化したGoogleの指標であり、検索順位のランキング要因の一つです。ただし単独で順位を決めるものではなく、コンテンツの質を土台にした上で、離脱率やCVRの改善を通じて直接・間接にSEOを底上げします。改善はまずPageSpeed Insightsで測定し、効果の大きい画像の最適化から着手して、キャッシュや不要要素の整理へと進めるのが費用対効果の高い順序です。当社は自社メディアで月686時間の削減を実現したAI×人の運用設計で、測定から改善・継続監視までを伴走します。表示速度でSEOを強くしたい方は、お気軽にご相談ください。