Webサイトの表示スピードや操作のしやすさが、ユーザー体験(UX)やSEOにとって重要であることは、今や常識となりつつあります。
Googleはこうした「使いやすさ」や「速さ」を評価するための指標として、コアウェブバイタル(Core Web Vitals)を導入しました。
このコアウェブバイタルは、
- LCP(Largest Contentful Paint)
- INP(Interaction to Next Paint)
- CLS(Cumulative Layout Shift)
の3つの指標から構成され、2024年にはFID(First Input Delay)に代わってINPが正式な評価指標として採用されるなど、現在も進化を続けています。
これらの指標を理解し、改善に取り組むことは、検索順位の向上だけでなく、訪問者の離脱防止やコンバージョン率の改善にもつながります。
この記事では、コアウェブバイタルの3つの指標について、それぞれの意味や測定基準、改善方法をわかりやすく解説します。
Webサイトのパフォーマンス改善に取り組みたい方は、ぜひ参考にしてください。
参考:Google検索セントラルブログ INPをCore Web Vitalsに導入
コアウェブバイタルとは?
コアウェブバイタル(Core Web Vitals)とは、Googleがユーザー体験を評価するために定めたウェブサイトの表示速度や操作性、視覚的な安定性に関する3つの指標です。
具体的には以下の3つが該当します。
- LCP(Largest Contentful Paint)
- ページの主要コンテンツが表示されるまでの時間
- INP(Interaction to Next Paint)
- ユーザー操作に対するサイトの応答速度
- CLS(Cumulative Layout Shift)
- ページ内の視覚的なズレの起こりにくさ
Googleはこれらを「ユーザー中心のパフォーマンス指標」と位置づけ、検索順位にも一定の影響を与えるシグナルとして扱っています。
ウェブバイタルとコアウェブバイタルの違い
ウェブバイタル(Web Vitals)はGoogleが提示するパフォーマンス測定の枠組み全体を指します。
その中でも特に重要で、すべてのWebサイト運営者が意識すべき指標として位置づけられているのが、Core Web Vitals(コアウェブバイタル)です。
つまり、コアウェブバイタルはウェブバイタルの中核にあたる3つの指標といえます。
なぜ重要なのか?検索順位との関係
Googleは2021年から、コアウェブバイタルを含む「ページエクスペリエンス」の評価を検索順位の一要素として正式に導入しました。
この評価は、コンテンツの質やリンクの評価といった従来のランキング要因に加えて「ユーザーがストレスなく利用できるサイトかどうか」という観点を加味するものです。
そのため、たとえ優れたコンテンツを持っていても、読み込みが遅い・操作に反応しない・レイアウトが崩れるといった問題がある場合、ユーザー体験の面でマイナス評価につながる可能性があります。
参考:Google検索セントラルブログ ページエクスペリエンスによるランキング方式の変更
2024年のアップデート「FID」から「INP」へ
これまでコアウェブバイタルの一つとされていたFID(First Input Delay)は、2024年3月をもってINP(Interaction to Next Paint)に置き換えられました。
これは、より正確にユーザーの体感速度を測定するための変更です。
INPは、ページ読み込み後のすべてのユーザー操作を対象に、最も応答に時間がかかった操作を測定することで、実際の使いやすさを反映しやすくなっています。
このように、コアウェブバイタルは単なる速度指標ではなく、GoogleがUX(ユーザーエクスペリエンス)をどのように評価しているかを示す、最新かつ実践的な基準です。
参考:Google検索セントラルブログ INPをCore Web Vitalsに導入
LCP(Largest Contentful Paint)とは?
LCP(Largest Contentful Paint)とは、ページを読み込んだ際に、画面上で最も大きな主要コンテンツが表示されるまでにかかった時間を計測する指標です。
主に「視覚的な読み込みの速さ」を評価するもので、ユーザーが「ページが表示された」と感じるまでのスピードを測るのに役立ちます。
たとえば、記事ページであれば見出しや本文、画像などが該当し、ECサイトであれば商品画像や価格情報が該当することが多いです。
参考:Largest Contentful Paint | Lighthouse | Chrome for Developers
理想的なLCPの値は?
Googleが推奨するLCPの基準は以下の通りです。
- 良好(Good)
- 2.5秒以内
- 改善が必要(Needs improvement)
- 2.5秒~4.0秒
- 不良(Poor)
- 4.0秒以上
この基準は、ページが「ファーストビューでどれだけ速く表示されるか」を測るものです。
2.5秒を超えると、ユーザーが「読み込みが遅い」と感じ、離脱の原因になりやすくなります。
LCPの計測対象となる要素
LCPでは、以下のようなビューポート内の最大要素が自動的に選ばれ、表示時間が計測されます。
- 画像要素(<img>タグ、背景画像など)
- <video>のポスターフレーム
- テキストブロック(例:大きな見出しや段落)
ただし、表示された瞬間の状態で最大と判断される要素が選ばれるため、ページの構成によっては意図しない要素が計測対象になることもあります。
LCPが悪化する主な原因
LCPの数値が悪化する原因は、ページの構造や読み込み処理に関係しています。
主な原因は次のとおりです。
- 画像の読み込みに時間がかかっている(容量が大きい、最適化されていない)
- サーバーの応答が遅い(初期表示までに時間がかかる)
- レンダリングをブロックするCSSやJavaScriptがある
- フォントの読み込みが遅く、テキストが表示されない(FOIT/FOUT)
LCPを改善する方法(例)
LCPを改善するためには、以下のような具体的対策が有効です。
- 1.画像を最適化する
- WebP形式やAVIFなどの軽量フォーマットを活用する※1
- 適切なサイズ・解像度に圧縮する
- 2.LazyLoadの使用を最適化する
- ファーストビュー内の画像や要素は遅延読み込みにしないように設定する
- 3.レンダリングブロックリソースを削減する
- 不要なJavaScriptやCSSの読み込みを減らし、async や defer を適切に使う
- 4.サーバー応答時間の短縮(TTFB改善)
- キャッシュの活用、データベース処理の見直し、より高速なホスティング環境の検討
- 5.CDNを導入する
- コンテンツ配信ネットワーク(CDN)を使うことで、地理的に近いサーバーから素早くコンテンツを届けられる
LCPの改善は、ユーザーにとっての「ページ表示の速さ」に直結するため、体感的なパフォーマンス向上にもっとも効果的な領域です。
SEOの観点でもユーザー体験の観点でも、優先度高く取り組むべき指標といえるでしょう。
※1.WebPやAVIF導入時の注意点とデメリット
WebPやAVIFは、JPEGやPNGに比べてファイルサイズを大幅に削減できるため、LCP改善の手段として非常に有効です。
ただし、以下のようなデメリットや実装上の注意点も存在します。
- ブラウザやツールとの互換性に注意が必要
- 多くのブラウザはWebPやAVIFに対応していますが、一部の古いブラウザや独自エンジンを使用しているアプリでは非対応の場合があります。
対策としては、HTMLの<picture>要素を使ってフォールバック画像を用意するなどの対応が必要です。 - Google Search Consoleで「クロール済み – インデックス未登録」が発生するケースがある
- 特に、WebP形式に変換した画像をHTMLに直接埋め込んでいる場合、Googlebotがコンテンツの重複や読み込みエラーと判断することがあり、インデックスされない問題が報告されています。
- AVIFはさらに対応環境が限定されている
- AVIFはWebPよりもさらに高圧縮ですが、対応ブラウザが限られているため、より慎重な実装が求められます。
こうした問題を避けるためにも、次世代画像フォーマットを導入する際は、以下の点を確認すると安心です。
- HTMLで<picture>タグや<img srcset>属性を使って、複数フォーマットを適切に指定する
- CDNや変換ツールの挙動を事前に検証する
- Search Consoleでインデックス状況をこまめに確認し、想定外の動作がないか注意する
参考:
Largest Contentful Paint(LCP) | Articles | web.dev
Largest Contentful Paint を最適化する | Articles | web.dev
ウェブフォントの読み込み時にテキストが表示されたままにする | Lighthouse | Chrome for Developers
INP(Interaction to Next Paint)とは?
INP(Interaction to Next Paint)とは、ユーザーがWebページ上で何らかの操作を行った際、その操作に対する画面の反応が表示されるまでの待ち時間を計測する指標です。
2024年3月に、それまで使用されていたFID(First Input Delay)に代わって、正式にCore Web Vitalsの評価対象となりました。
なぜINPが導入されたのか?
従来のFIDは「最初の操作に対する遅延時間」だけを測定していたため、ページ読み込み後の他の操作に関するレスポンスの遅さは評価の対象外でした。
しかし実際には、ユーザーがページを利用する間に行う複数回のクリックや入力などがスムーズに反応するかが、使いやすさを大きく左右します。
そのためINPでは、ページ滞在中に行われたすべてのユーザー操作のうち、最も応答時間の長かった操作をもとに評価します。
これにより、ページ全体のインタラクション(やり取り)の質をより正確に測れるようになりました。
INPの理想値と評価基準
Googleが定めるINPの評価基準は以下の通りです。
- 良好(Good)
- 200ミリ秒以下
- 改善が必要(Needs improvement)
- 200~500ミリ秒
- 不良(Poor)
- 500ミリ秒超
ここで言う「応答時間」とは、ユーザーの操作(クリックやタップ、キー入力など)が発生してから、次の画面更新(paint)が完了するまでの合計時間を指します。
INPに影響する操作とは?
INPでは、以下のようなインタラクションが対象となります。
- ボタンやリンクのクリック/タップ
- 入力フォームの選択や文字入力
- メニュー展開、モーダル表示などのUI操作
INPが悪化する主な原因
INPの数値が悪化する主な要因は、以下の通りです。
- JavaScriptの処理負荷が高く、メインスレッドが占有されている
- ユーザー操作に紐づくイベントリスナー(指定された処理)の実行が遅い
- アニメーションやトランジション(変化)が重く、描画が遅延する
- サードパーティ製スクリプト(広告・ウィジェットなど)の影響
とくに、クリック後に多くの処理を伴うボタン(例:バリデーション、API通信、動的描画など)は、INPに大きな影響を与えます。
INPを改善する方法(例)
INPを改善するには、ユーザーの操作に素早く反応できる設計が求められます。
代表的な対策は以下の通りです。
- 1.JavaScriptの最適化
- 長時間実行される処理を細分化して、requestIdleCallbackやsetTimeoutで分割実行
- 使用していないライブラリやプラグインの削除
- 2.イベントリスナーの処理を軽量にする
- clickイベントなどで処理を詰め込みすぎない
- 必要な箇所だけにリスナーをバインドする
- 3.UI描画の負荷を軽減
- アニメーションはGPU支援されるCSSトランスフォーム中心に設計
- DOM操作やレイアウト変更を最小限にする
- 4.Webワーカーの活用
- 重い計算処理はWebワーカーで非同期に処理し、メインスレッドをブロックしない
INPは「ユーザーが実際に操作したときの体感速度」を反映する指標であり、使いやすさの評価に直結します。
ページ表示が速くても、操作にストレスがあれば離脱につながるため、LCPやCLSと並んで非常に重要な改善対象といえるでしょう。
参考:
Interaction to Next Paint(INP) | Articles | web.dev
次のペイントに対するインタラクションを最適化する | Articles | web.dev
INP の修正に関する Economic Times のクエスト | web.dev
イベント移譲(Event delegation)
CSS and JavaScript animation performance – Performance | MDN
大規模で複雑なレイアウトとレイアウトのスラッシングを回避する | Articles | web.dev
Webワーカーを使用してブラウザのメインスレッド以外でJavaScript を実行する | Articles | web.dev
CLS(Cumulative Layout Shift)とは?
CLS(Cumulative Layout Shift)は、ページの読み込み中や操作中に発生する予期しないレイアウトのズレ(レイアウトシフト)の合計値を測定する指標です。
ユーザーがページを読んでいる最中に、ボタンや文章、画像などの位置が突然移動してしまうと、操作ミスや読みづらさといった悪いユーザー体験につながります。
たとえば、ボタンを押そうとした瞬間に広告が読み込まれてボタンの位置がズレるようなケースが該当します。
CLSの評価基準
CLSは「回数」ではなく、シフトの大きさ × 発生頻度で評価されます。
Googleが定める基準は以下の通りです。
- 良好(Good)
- 0.1以下
- 改善が必要(Needs improvement)
- 0.1~0.25
- 不良(Poor)
- 0.25以上
CLSスコアはページ全体で発生したレイアウトのずれを加算して算出されるため、小さなズレが何度も起こる場合も評価が悪化する原因になります。
CLSが発生しやすい場面と要因
CLSが悪化するのは、主に以下のようなケースです。
- 画像や動画にサイズ指定(width・height)がされていない
→読み込み後にサイズが確定し、周囲のレイアウトを押し下げる - 広告や埋め込みコンテンツのサイズが動的に変化する
→読み込み時と表示時で高さが変わり、全体がズレる - Webフォント読み込み時のFOIT(Flash of Invisible Text)やFOUT(Flash of Unstyled Text)
→フォントが後から反映され、テキストサイズが変化してズレが生じる - JavaScriptやCSSで動的に要素が挿入・削除される
→DOMの再構築によって不安定な描画が発生する
CLSを防ぐための改善策
CLSの改善は、ページを構成する要素の「安定性」と「予測可能性」を保つことが基本です。
以下のような対策が効果的です。
- 1.画像・動画・iframeにはサイズ属性を明示する
- <img width=”600″ height=”400″>のように、表示領域を確保する
- CSSでaspect-ratioを活用して高さを確保することも有効
- 2.広告枠や埋め込みコンテンツの領域をあらかじめ確保する
- スケルトンUIなどでレイアウトの位置を事前に固定しておく
- 3.Webフォントの読み込みを最適化する
- font-display:swapを使用して非同期でフォントを読み込む
- 初期表示にシステムフォントを使用し、後から置き換える
- 4.JavaScriptで動的に要素を挿入する際は注意
- 挿入位置に十分なスペースを確保する
- 5.プリロードや優先順位制御を活用する
- 重要な要素(例:メインビジュアルなど)を優先的に読み込むことで、ズレの要因を早期に排除
CLSは、見た目には些細な問題のように思えるかもしれませんが、操作ミスやストレスにつながりやすい問題であり、特にモバイル環境では影響が顕著です。
ユーザーが安心して操作できる安定したレイアウトは、Webサイトの信頼性やユーザー体験を支える重要な要素といえるでしょう。
参考:
Cumulative Layout Shift(CLS) | Articles | web.dev
Webフォント使用時のレンダリングのチラつきが気になるので直したいときの対処法
Cumulative Layout Shift の最適化 | Articles | web.dev
より良いユーザー体験を求めて "Skeleton UI" について深掘りする
重要なアセットをプリロードして読み込み速度を改善する | Articles | web.dev
コアウェブバイタル対策のロードマップ【測定から改善まで】
コアウェブバイタル(LCP・INP・CLS)は、Webサイトの「快適さ」を測るための重要な指標です。
ページの表示速度、操作への応答性、見た目の安定性を示し、優れたユーザー体験(UX)の提供やGoogle検索での評価向上に欠かせません。
このガイドでは、現状分析から具体的な改善策まで、体系的なアプローチを分かりやすく解説します。
まずは自サイトの課題を特定し、一つずつ着実に改善を進めていきましょう。
1.現状の計測と問題点の特定
まず、現在のコアウェブバイタルのスコアを把握する必要があります。
以下の無料ツールを活用することで、問題箇所が可視化できます。
- Google PageSpeed Insights
- 各指標のスコアや改善提案を確認可能(モバイル/PC別)
- Google Lighthouse(DevTools/Chrome拡張機能)
- ローカル環境での詳細なパフォーマンス解析に有効
- Google Search Console(エクスペリエンスレポート)
Webサイト表示速度を改善する無料ツール5選
Webサイトの表示速度、遅くなっていませんか?
Webサイトの表示速度が遅いと、訪問者はすぐに離脱してしまいます。
本記事では、Webサイトの表示速度を改善するために役立つ無料ツールを5つ厳選してご紹介します。
2.指標別の主な改善方法まとめ
- LCP(読み込み速度)の改善施策
- メインビジュアルなどの読み込みを最適化(preloadタグの活用)
- 不要なJavaScriptやCSSの削除・縮小(minify)
- サーバーやCMSのレスポンス高速化(キャッシュ、CDN、レンダリング改善)
- 画像の軽量化とフォーマット変換(※WebPの注意点は前述)
- INP(操作応答性)の改善施策
- 長時間かかる処理を非同期化(Web Worker、setTimeoutなど)
- JavaScriptの実行タイミングと優先順位の整理
- イベントリスナーの最適化(重い処理は分離・遅延実行)
- サードパーティ製ウィジェット・タグマネージャの影響検証と制限
- CLS(視覚安定性)の改善施策
- 画像やiframeのサイズ指定の明示(width・height属性)
- フォント読み込み時の描画の揺れを防ぐ(font-display: swap)
- 動的コンテンツや広告エリアの事前スペース確保
- アニメーション・トランジションの設計見直しとGPU活用
3.使用技術やCMS別の最適化ポイント
Webサイトの構築方法(CMS/フレームワーク/ホスティング環境など)により、最適化ポイントも変わります。
使用技術例 | 最適化ポイント |
---|---|
WordPress | キャッシュプラグイン(例:WP Rocket、LiteSpeed Cache)の活用 画像圧縮系プラグイン(例:EWWW、ShortPixel)との併用 |
静的サイト(HTML/CSS) | 不要ファイルの削除、CDNでの配信、高速なホスティング環境 |
JavaScriptフレームワーク (Next.js、Reactなど) | SSR(サーバーサイドレンダリング)やISR(段階的な静的サイト生成)の活用、画像最適化コンポーネントの使用、バンドルサイズ削減 |
Shopify/WixなどSaaS型CMS | サードパーティアプリの整理、画像の圧縮、テンプレート最適化 |
表示速度対策 ホームページ作成後の落とし穴!
表示速度を計測する「Google PageSpeed Insights」は点数へ目がいきやすいですが、この点数はあまり気にしなくても結構です。
あきらかに表示速度改善に繋がる修正(自身でアクセスして体感で分かるレベル)をしても、改善前より点数が低くなることが多々あります。
4.優先順位とPDCAサイクルの回し方
コアウェブバイタルの改善は一度きりの作業ではなく、継続的な改善(チューニング)が必要です。
以下の流れを繰り返しながら、定期的に見直していきましょう。
- スコアを測定・分析
- 改善対象を特定し、優先順位を設定
- 実装・テスト(ABテストや段階的導入も有効)
- 効果を再測定して評価・記録
- 新たな課題が出たら再改善
とくに「INP」などはユーザー行動に依存するため、実測データ(Search Consoleのフィールドデータ)を重視しつつ、改善後の影響を長期で追うことが重要です。
参考:
Web Vitals | Articles | web.dev
Google ツールを使用した Core Web Vitals のワークフロー | Articles | web.dev
WordPress Playground と WebAssembly でブラウザ内の WordPress エクスペリエンスを構築 | Articles | web.dev
Components: Image
まとめ
コアウェブバイタルは「ユーザーにとって快適かどうか」を測定するための具体的な指標です。
検索順位への影響だけでなく、CVR(コンバージョン率)や直帰率にも直結する重要なUX要素といえます。
一つひとつの施策は小さくても、積み重ねることでサイト全体の質は大きく向上します。
最終的には、検索エンジンにも、そして何より訪問ユーザーにも「使いやすい」と感じてもらえるWebサイト運営を目指しましょう。
Google Lighthouseの使い方と評価項目の紹介
Google Lighthouse(ライトハウス)は、ウェブサイトのパフォーマンスやユーザー体験を評価するためのツールです。
特に、ウェブ開発者やSEO専門家にとって重要なツールであり、サイトの改善点を明確にするために利用されます。