目次
最初に押さえるポイント コアウェブバイタルが重視される背景と全体像 3つの指標と良好とされる基準値 フィールドデータとラボデータの使い分け LCPの原因特定と最適化手順 INPの原因特定と最適化手順 CLSの原因特定と最適化手順 計測ツールと継続的な改善運用 実務で確認するチェックリスト よくある質問最初に押さえるポイント
- コアウェブバイタルはLCP2.5秒以内、INP200ミリ秒以内、CLS0.1以下を、実ユーザーの75パーセンタイルで満たすことが良好の基準です。
- 施策の正否は、実ユーザーの体験を表すフィールドデータで判断し、ラボデータは原因の切り分けと修正検証に用いると効果的です。
- LCPは読み込みを4つの段階に分解し、最大要素の発見を妨げている工程を特定してから手を打つことが近道です。
- INPは入力遅延・処理時間・表示遅延の3要素に分け、長いタスクの分割と不要なJavaScriptの削減が中心的な打ち手になります。
- CLSは画像や広告の領域確保、後から差し込まれる要素の制御、フォント切り替えの管理で大半を防げます。
コアウェブバイタルが重視される背景と全体像
コアウェブバイタルは、ウェブページの体験を読み込み・応答性・視覚的安定性の3つの観点から数値で表す指標群です。Googleはこれをページ体験の中核に据えており、検索のランキングシステムが評価しようとする良質な体験と方向性が一致すると説明しています。表示速度の改善が、ユーザー満足と検索流入の双方に関わる領域になりました。
対象となる指標は、最大要素が表示されるまでの時間を測るLCP、操作への応答性を測るINP、表示中のレイアウトのずれを測るCLSの3つです。いずれも体感に直結する要素を選んで設計されており、技術指標でありながらユーザーが感じる快適さを代弁する性格を持ちます。
重要なのは、これらが実際にサイトを訪れたユーザーの体験を集計して評価される点です。開発環境での計測値が良くても、実機やネットワーク条件の違いによって現実の数値が悪化することは珍しくありません。だからこそ、実ユーザーのデータを起点に改善を組み立てる発想が前提になります。
改善を進める際は、3指標をまとめて扱うのではなく、どの指標が基準を下回っているかを見極めてから着手します。原因も打ち手も指標ごとに異なるため、まず現状を分解して把握することが、限られた工数で成果を出すための出発点になります。やみくもに高速化を図るより、対象を絞る発想が結果的に効率的です。
3つの指標と良好とされる基準値
LCPは、ビューポート内で最も大きく描画される要素が表示されるまでの時間で、読み込みの速さの体感を表します。良好とされる基準は2.5秒以内で、4.0秒を超えると不良と判定されます。多くの場合、メインビジュアルの画像や大きな見出しテキストがこの計測対象になります。
INPは、ページ滞在中に発生したクリックやタップ、キー入力といった操作に対し、次の描画が返るまでの遅延を代表値で評価する指標です。良好の基準は200ミリ秒以内で、500ミリ秒を超えると不良になります。ページ全体を通じた応答性を見るため、単発の遅延よりも操作全体の傾向が反映されます。
CLSは、読み込みの途中で要素の位置が予期せず動くずれの大きさを累積した値です。良好とされる基準は0.1以下で、0.25を超えると不良と判定されます。ボタンを押そうとした瞬間に位置がずれて誤操作するような、視覚的な不安定さを数値化したものです。
これらの基準は、いずれも実ユーザーの計測値を集計し、75パーセンタイルの値で判定される点に注意が必要です。全訪問の4分の3で基準を満たして初めて良好と評価されるため、一部の高速な環境だけで達成できても、全体としては未達となる場合があります。
コアウェブバイタル3指標の評価基準
各指標が測る対象と、良好・要改善・不良の境界値を整理しています。判定は実ユーザーの75パーセンタイルで行われます。
| 指標 | 測る対象 | 良好 | 不良 |
|---|---|---|---|
| LCP | 最大要素の表示までの時間 | 2.5秒以内 | 4.0秒超 |
| INP | 操作への応答の遅延 | 200ミリ秒以内 | 500ミリ秒超 |
| CLS | レイアウトのずれの累積 | 0.1以下 | 0.25超 |
| 判定方法 | 全指標共通 | 75パーセンタイルで評価 | 一部環境のみの達成は不可 |
フィールドデータとラボデータの使い分け
改善の判断材料には、性格の異なる2種類のデータがあります。フィールドデータは実際にサイトを訪れたユーザーの計測値を集めたもので、検索評価の基準にもなる現実の体験を表します。ラボデータは管理された環境で疑似的に計測した値で、条件をそろえて繰り返し検証できる点に強みがあります。
フィールドデータの代表が、実際のChromeユーザーの体験を集計したChrome User Experience Report、通称CrUXです。世界中の実ブラウザから収集されるため、実機やネットワークの多様性が反映されます。一定の訪問数があるサイトが対象で、これがコアウェブバイタルの公式な評価のもとになります。
一方、ラボデータは原因の切り分けと修正の検証に適しています。同じ条件で何度でも計測できるため、ある変更が指標を改善したかどうかを開発段階で確認できます。ただし計測環境が固定されるため、その値がそのまま実ユーザーの体験と一致するとは限らない点に注意が必要です。
実務では、フィールドデータで現状の良否を判断し、悪化している指標についてラボデータで原因を掘り下げ、修正後にラボで効果を確認してから本番に反映し、最終的にフィールドデータの改善を待って成否を見届ける流れが基本になります。両者を役割分担させることが効率的な改善につながります。
フィールドデータとラボデータの違い
2種類のデータの特徴と適した用途を比較しています。改善判断と原因特定で使い分けることが前提になります。
| 観点 | フィールドデータ | ラボデータ |
|---|---|---|
| 計測対象 | 実際の訪問ユーザー | 管理された疑似環境 |
| 代表的な情報源 | CrUX | Lighthouse |
| 強み | 現実の体験を反映 | 条件をそろえ再現可能 |
| 主な用途 | 良否の判断と検索評価 | 原因特定と修正検証 |
| 注意点 | 反映に時間がかかる | 実体験と一致しない場合あり |
LCPの原因特定と最適化手順
LCPの改善は、表示までの時間を4つの段階に分解することから始めます。最初のバイト到達までのTTFB、リソース読み込みが始まるまでの読み込み遅延、リソース自体の読み込み時間、そして要素が描画されるまでのレンダリング遅延です。どの段階が時間を占めているかを特定すれば、効果の大きい打ち手が見えてきます。
理想的なページでは、TTFBとリソース読み込み時間でLCPの大半を占め、2つの遅延はそれぞれ全体の1割未満に抑えられているとされます。逆に言えば、読み込み遅延やレンダリング遅延が大きい場合は、リソースの発見や描画を妨げる要因が潜んでいる可能性が高いと判断できます。
具体的な打ち手としては、LCP要素となる画像を優先的に読み込むよう指定し、発見を早めることが効果的です。あわせて、表示をブロックするCSSやJavaScriptを削減し、サーバー応答を速めるためのキャッシュや配信の見直しを進めます。最大要素が遅延なく早期に発見・描画される状態を目指します。
画像の最適化も重要です。適切な形式への変換や圧縮、表示サイズに合わせた配信によって、リソースの読み込み時間そのものを短縮できます。これらの施策は読み込み遅延と読み込み時間の双方に効くため、LCPが不良の場合にまず検討すべき効果の大きい領域になります。
LCPを構成する4つの段階と打ち手
読み込みを段階に分け、各段階で時間が長い場合の代表的な改善策を整理しています。
| 段階 | 意味 | 主な打ち手 |
|---|---|---|
| TTFB | 最初のバイト到達までの時間 | キャッシュ・配信網・サーバー応答の改善 |
| 読み込み遅延 | LCPリソース取得開始までの待ち | 優先読み込み指定とブロック要素の削減 |
| 読み込み時間 | リソース自体の取得時間 | 画像の圧縮・形式変換・適正サイズ配信 |
| レンダリング遅延 | 取得後に描画されるまでの待ち | 描画を妨げるCSS・JavaScriptの軽量化 |
INPの原因特定と最適化手順
INPは、1回の操作にかかる遅延を入力遅延・処理時間・表示遅延の3要素に分けて捉えます。入力遅延は操作の開始からイベント処理が始まるまで、処理時間はイベントのコールバックが走り終わるまで、表示遅延は処理結果を含む次のフレームが描画されるまでの時間です。この3つの合計が操作全体の遅延になります。
応答性が悪い原因の多くは、メインスレッドを長時間占有する処理にあります。重いJavaScriptが連続して実行されると、ユーザーの操作に対する反応が後回しになり、入力遅延と処理時間がともに伸びます。まずは実行に時間のかかる長いタスクを洗い出すことが原因特定の起点になります。
中心的な打ち手は、長い処理を細かく分割し、合間にブラウザへ制御を返して描画や入力処理を割り込ませることです。これにより、操作への反応を待たせずに済みます。あわせて、不要なJavaScriptの削減やサードパーティスクリプトの見直しで、メインスレッドの負荷そのものを下げます。
表示遅延への対策としては、DOMの規模を抑え、画面外の要素の描画を後回しにする手法が有効です。要素が多いほど描画コストが増えるため、構造の肥大化を防ぐことが応答性の維持につながります。これらを組み合わせ、3要素の合計を200ミリ秒以内に収めることを目指します。
INPを構成する3要素と打ち手
操作の遅延を3要素に分け、それぞれを短縮するための代表的な対策を整理しています。
| 要素 | 意味 | 主な打ち手 |
|---|---|---|
| 入力遅延 | 操作開始から処理開始までの待ち | 長いタスクの分割とスクリプト削減 |
| 処理時間 | イベント処理が終わるまでの時間 | 処理の分割と不要な計算の除去 |
| 表示遅延 | 結果が描画されるまでの待ち | DOMの軽量化と画面外要素の描画後回し |
| 共通の負荷源 | メインスレッドの占有 | サードパーティスクリプトの見直し |
| 目標値 | 3要素の合計遅延 | 200ミリ秒以内に収める |
CLSの原因特定と最適化手順
CLSの主な原因は、表示領域があらかじめ確保されていない要素にあります。寸法を指定していない画像、サイズが動的に変わる広告や埋め込み、読み込み後に差し込まれるバナーやフォーム、そしてフォントの切り替えによる文字の再配置が、代表的な4つの要因として挙げられます。これらを順に潰すことが改善の基本になります。
画像については、幅と高さの属性を必ず指定し、ブラウザが読み込み前に領域を確保できるようにします。あわせてアスペクト比や最小高さをCSSで指定しておくと、画像や動画の読み込みによって後続の要素が押し下げられるずれを防げます。最も着手しやすく効果の出やすい対策です。
広告や埋め込みコンテンツは、レイアウトのずれに大きく寄与する要因とされています。表示される領域をあらかじめ確保しておき、実際の中身が後から入ってきても周囲が動かないようにします。動的に差し込むコンテンツは、既存の要素を押しのけない画面下部などに配置する工夫も有効です。
フォントの切り替えも見落とされがちな要因です。代替フォントからウェブフォントへ切り替わる際に文字の見た目が変わり、行が再配置されてずれが生じます。フォントの読み込み方法を調整し、レイアウトに影響しにくい切り替えにすることで、文字回りのずれを抑えられます。
CLSの主な原因と対策
レイアウトのずれを引き起こす代表的な4要因と、それぞれの基本的な対策を整理しています。
| 原因 | 起きる現象 | 主な対策 |
|---|---|---|
| 寸法未指定の画像 | 読み込みで後続要素がずれる | 幅・高さの指定とアスペクト比の確保 |
| 広告・埋め込み | 中身が入ると周囲が動く | 表示領域を事前に確保する |
| 後から差し込む要素 | 既存要素が押し下げられる | 下部配置と領域の事前確保 |
| フォントの切り替え | 文字の再配置で行がずれる | 読み込み方法の調整 |
計測ツールと継続的な改善運用
改善を継続するには、計測の体制を整えることが欠かせません。実ユーザーの状況はSearch Consoleのレポートで指標ごとの良否とURLの分布を確認でき、個別ページの診断にはPageSpeed Insightsが役立ちます。フィールドとラボの両方の値を一画面で確認できるため、現状把握と原因の当たりづけを同時に進められます。
開発段階での検証には、ラボ計測のLighthouseを用います。修正前後で同じ条件の計測を繰り返すことで、ある変更が指標を改善したかを定量的に確認できます。ただしINPのように実際の操作を要する指標は、ラボだけでは把握しきれないため、最終判断はフィールドデータに委ねる前提で運用します。
改善は一度きりで終わらせず、運用に組み込むことが重要です。新しい機能の追加や外部スクリプトの導入によって指標が悪化することは珍しくありません。リリースのたびに計測し、悪化が起きていないかを確認する仕組みを設けておくと、せっかくの改善が後退するのを防げます。
数値は反映までに時間がかかる点も理解しておきます。フィールドデータは過去一定期間の集計値で更新されるため、修正の効果が指標に表れるまでには日数を要します。短期の変動に一喜一憂せず、期間を区切って前後を比較し、傾向で判断する姿勢が安定した運用につながります。
計測ツールと役割の整理
コアウェブバイタルの計測に使う主なツールと、それぞれの役割を整理しています。
| ツール | データ種別 | 主な役割 |
|---|---|---|
| Search Console | フィールド | サイト全体の良否とURL分布の把握 |
| PageSpeed Insights | 両方 | 個別ページの診断と原因の当たりづけ |
| Lighthouse | ラボ | 修正前後の効果検証 |
| CrUX | フィールド | 実ユーザー体験の集計データの参照 |
実務で確認するチェックリスト
- LCP・INP・CLSのうち、どの指標が良好の基準を下回っているかをフィールドデータで把握したか
- 改善対象のURLグループを特定し、共通する原因の仮説を立てたか
- LCPは4つの段階に分解し、時間を占めている工程を特定したか
- INPは長いタスクを洗い出し、処理の分割と不要なJavaScriptの削減を検討したか
- CLSは画像の寸法指定と広告・埋め込みの領域確保を実施したか
- 修正の効果をラボ計測で検証してから本番へ反映したか
- リリースごとに計測し、指標の悪化が起きていないか確認する運用を整えたか
よくある質問
コアウェブバイタルとは何ですか?
ウェブページのユーザー体験を、読み込み・応答性・視覚的安定性の3つの観点から数値で評価するGoogleの指標群です。具体的にはLCP・INP・CLSの3指標で構成され、実際にサイトを訪れたユーザーの計測値をもとに良否が判定されます。検索のランキングシステムが評価する良質な体験とも方向性が一致するとされています。
良好とされる基準値はどのくらいですか?
LCPは2.5秒以内、INPは200ミリ秒以内、CLSは0.1以下が良好の基準です。いずれも実ユーザーの計測値を集計し、75パーセンタイルの値で判定されます。全訪問の4分の3で基準を満たして初めて良好と評価されるため、一部の高速な環境だけで達成しても全体では未達となる場合があります。
FIDがINPに置き換わったと聞きましたが、何が変わりましたか?
従来の応答性指標であったFIDに代わり、現在はINPがコアウェブバイタルの指標として採用されています。FIDが最初の操作の入力遅延だけを見ていたのに対し、INPはページ滞在中の操作全体を対象に、入力から描画までの遅延を代表値で評価します。これにより、より実態に近い応答性を測れるようになりました。
フィールドデータとラボデータはどう使い分けますか?
フィールドデータは実ユーザーの体験を表すため、指標の良否を判断し成否を見届ける用途に使います。ラボデータは条件をそろえて繰り返し計測できるため、原因の切り分けと修正の検証に適しています。実務では、フィールドで現状を把握し、ラボで原因を掘り下げて修正を検証する流れが基本になります。
どの指標から改善に着手すべきですか?
まずフィールドデータを確認し、良好の基準を下回っている指標から着手するのが効率的です。3指標をまとめて扱うのではなく、未達の指標に絞って原因を分解します。原因も打ち手も指標ごとに異なるため、現状を分解して把握してから優先順位をつけることが、限られた工数で成果を出す前提になります。
コアウェブバイタルは検索順位にどの程度影響しますか?
コアウェブバイタルはページ体験の評価要素のひとつで、検索のランキングシステムが評価する良質な体験と方向性が一致するとされています。ただし、これだけで順位が大きく決まるわけではなく、コンテンツの関連性や品質が前提です。同程度の内容であれば体験の良いページが有利になりうる、という位置づけで捉えるのが適切です。
改善してもすぐに数値に反映されないのはなぜですか?
フィールドデータが過去一定期間の集計値として更新される仕組みのためです。修正を反映しても、その効果が指標に表れるまでには日数を要します。短期の変動に一喜一憂せず、期間を区切って前後を比較し、傾向で判断する姿勢が必要です。開発段階での効果はラボ計測で先に確認できます。
一度改善すれば再び計測する必要はありませんか?
継続的な計測が必要です。新しい機能の追加や外部スクリプトの導入によって、改善した指標が再び悪化することは珍しくありません。リリースのたびに計測し、悪化が起きていないかを確認する仕組みを設けておくことで、せっかくの改善が後退するのを防げます。改善は一度きりではなく運用に組み込むべき取り組みです。
この記事に出てくる用語
意味や計算式は用語集で確認できます。