Core Web Vitals：SEOとページ体験への影響

Core Web Vitalsが測るもの

Core Web Vitalsはユーザー視点のパフォーマンス指標で、ページの実際の使用感に関する「読み込み」「インタラクティブ性」「視覚的安定性」の3点を表します。実務では、主要コンテンツがどれだけ早く表示されるか、ユーザー入力にどれだけ応答するか、レイアウトのズレが体験を妨げないかを評価するために使います。

Largest Contentful Paint (LCP)

LCPはビューポート内で最も大きな可視要素がページ読み込み中にレンダリングを終えるタイミングを測ります。多くの場合ヒーロー画像やファーストビューのテキストブロック、大きな動画のポスターフレームです。LCPは体感速度に関する指標で、意味のある最大のコンテンツが素早く出ればページは速く感じられます。

Interaction to Next Paint (INP)

INPはフィールド指標で、ユーザー操作の応答遅延を測りレスポンス性を評価します。旧来のFIDが最初のインタラクションだけを見ていたのに対し、INPは多数の操作を集約してインタラクティブ性の全体像を示します。長いメインスレッドタスクや遅いイベントハンドラがページを重く感じさせる箇所を浮き彫りにします。

Cumulative Layout Shift (CLS)

CLSはページライフサイクル中に発生する予期せぬレイアウト移動を測ります。個々のレイアウトシフトを集計して、どれだけ可視コンテンツが移動したか、どれだけ体験を妨げたかをスコア化します。画像や広告、埋め込みに対して余白を確保した安定したレイアウトはCLSを低く保ち、不快なリフローを減らします。

Core Web VitalsとSEOの関係

Core Web VitalsはGoogleのページ体験シグナルの一部です。ランキングやコンテンツの表示に使われる多くのシグナルのうちの一つであり、検索エンジンは順位付けやコンテンツ表示の判断にこれらを利用します。改善によりユーザーの摩擦が減りエンゲージメントが向上してページの価値を高められますが、Core Web Vitalsだけで順位が保証されるわけではありません。逆に非常に悪いスコアは、類似の関連性シグナルの場合に競争力を下げる可能性があります。

クローリング（ボットの発見と取得）、インデックス化（Googleが何を保存するか）、ランキング（結果の並び）の3つを区別して理解してください。Core Web Vitalsはページ体験に影響し、それを通じてランキングに寄与しますが、URLがクロール・インデックスされるかを決定するものではありません。運用面の留意点として、2024年7月以降、SearchはデフォルトでGooglebot Smartphoneでクロールされ、2024年初頭に従来のキャッシュページが削除されています — いずれもモバイル表示と現在のライブコンテンツが体験シグナルの算出と表示に中心的であることを意味します。

フィールド vs ラボ測定 — 使い分け

診断と修正検証にはフィールド（実ユーザー）データとラボ（合成）データの両方が必要です。フィールドは多様なデバイスとネットワークでの実際のユーザー体験を示し、ラボは制御下で再現可能なデバッグ用スナップショットを提供します。

フィールドツール

サイトレベルの傾向を見るには Google Search Console のCore Web Vitalsレポート（サイト所有が必要）、URLごとのフィールド要約は PageSpeed Insights、集計された実ユーザーデータは Chrome UX Report (CrUX) を使います。カスタム収集する場合は web-vitals ライブラリで計測を組み込み、デバイスや国、接続タイプでセグメント化するために分析ツールやAPMへ送ってください。

ラボツール

トレースベースのデバッグには Lighthouse（DevTools内またはCLI）と Chrome DevToolsのPerformanceパネルを使います。ラボ実行で長時間タスクを再現し、メインスレッドを調査し、ウォーターフォールタイミングを取得してレンダーブロッキング資源を特定します。

よくある原因と実務的な対策

LCP：原因と対策

典型的な原因：サーバー応答の遅さ、レンダーブロッキングなCSS/JavaScript、最適化されていない大きな画像、意味ある描画を遅らせるクライアントサイドレンダリング、最大可視要素の読み込みを遅らせるリソース優先度の設定。

実務的対策：キャッシュとCDN配置でTTFBを改善する。ファーストビュー向けの重要なCSSをインラインで提供し、非クリティカルCSSは遅延する。rel=preloadや適切なリソース優先度でLCPリソースを優先化する。画像は圧縮・リサイズし、モダンフォーマットとレスポンシブなsrcsetを使用する。クライアントレンダリングで主要コンテンツが遅れるページはサーバーサイドレンダリングやハイブリッドレンダリングを検討する。

INP：原因と対策

典型的な原因：長い JavaScript タスクがメインスレッドをブロックすること、ユーザー操作中の重い同期処理、初期化コードを実行する大きなバンドル、最適化されていないイベントハンドラ。

実務的対策：コードを小さなチャンクに分割して不要スクリプトを遅延させる。Web Workerでメインスレッド外に処理を移す。初回入力まで大きな初期化を延期する。イベントハンドラは最小限の作業に留め、重い処理は requestIdleCallback や setTimeout でスケジュールする。read–write–read のようなレイアウトスラッシングパターンを避ける。

CLS：原因と対策

典型的な原因：width/height がない画像や iframe、予約スペースなしで注入される広告や埋め込み、レイアウトを切り替える Web フォント、既存コンテンツ上への DOM 挿入。

実務的対策：画像や iframe には常に width と height 属性（または CSS の aspect-ratio）を入れる。広告や動的コンテンツ用に CSS コンテナでスペースを確保する。font-display: swap や optional を使い不可視テキスト期間を避ける。既存コンテンツの上に挿入する場合は必ずスペースを予約する。レイアウトに影響するプロパティのアニメーションではなく、transform ベースのアニメーションを優先する。

作業の優先順位付けと実装

まずはCore Web Vitalsが悪くかつトラフィックが多いページをトリアージしてください。サイトレベルのSearch Consoleデータでフィールド指標が悪いURL群を見つけ、代表的なURLをラボツールでデバッグします。対象ページごとに短い修正計画を作り、クイックウィン（画像圧縮、rel=preloadでのLCP優先、非クリティカルJSの遅延）、中程度の作業（コードスプリッティング、SSR）、大規模投資（アーキテクチャ変更やUX再設計）に分けてリスト化します。

修正をデプロイしたら定義した検証ウィンドウで実ユーザーメトリクス（RUM）を収集し、パーセンタイルやデバイス別セグメントで比較します。ページ体験は多くのランキングシグナルの一つに過ぎないため、Core Web Vitals改善は反復的なプログラムとして扱い、測定→影響の大きい項目を優先して修正→ユーザー行動と順位を監視→反復、を繰り返してください。

検証とトラブルシューティングのチェックリスト

Core Web Vitalsの問題を検証し修正を確認する際は、以下のチェックリストに従ってください：

1. サイトレベルの傾向：所有がある前提で Google Search Console の Core Web Vitals レポートを確認し、'poor' または 'needs improvement' と表示される URL 群を探す。

2. URLごとのフィールドスナップショット：PageSpeed Insights を実行して特定URLのフィールドとラボデータを確認し、CrUXのフィールドデータや診断提案をレビューする。

3. ラボで再現：シークレットの DevTools セッションで Lighthouse を実行し、Performance トレースを調べる。Performanceパネルで長時間タスクやメインスレッドの活動を見る。

4. 対象RUMの収集：web-vitals ライブラリでページに計測を組み込み、測定値を分析ツールへ送る。クイックキャプチャ用のモジュールスニペット例：

<script type="module">import {getCLS, getLCP, getINP} from 'https://unpkg.com/web-vitals?module';getCLS(r => console.log('CLS', r));getLCP(r => console.log('LCP', r));getINP(r => console.log('INP', r));</script>

5. デバイスの整合性を確認：Googleがモバイル表示をインデックス化とページ体験の主要基準に使うため、モバイル向けHTMLが同等のコンテンツを返しているか、レスポンシブ画像・CSS・重要リソースがスマートフォンのビューポートに最適化されているかを検証する。

6. サードパーティの影響を切り分ける：ラボ実行でサードパーティスクリプト（広告、分析、ウィジェット）あり／なしでページを読み込み、LCP、INP、CLSへの影響を計測する。過度な長時間タスクや予期せぬレイアウトシフトを生むプロバイダは置き換えるか遅延読み込みする。

よくある間違いと診断の落とし穴

• ラボスコアをそのままフィールドの実態と見なすこと。ラボ実行はデバッグに不可欠ですが単一のデバイス/ネットワークプロファイルをシミュレートするためユーザーベースを代表しない場合があります。必ずフィールドRUMで検証してください。

• デスクトップだけを最適化すること。Googleは主にモバイルレンダリングでページ体験を評価するため、重要なユーザージャーニーで異なるデバイス比率が示されない限りモバイル体験を優先する必要があります。

• 単一指標の過剰最適化。改善はユーザーのニーズを尊重すべきです：CLS低下のためにフォントを極端に遅延させると可読性が損なわれる可能性がありますし、INPを下げるために重要なスクリプトを削除すると機能が壊れることがあります。実験を使い、エンゲージメントやコンバージョンなどCore Web Vitals以外のユーザーメトリクスも測定してください。

• ランダムな変動を無視すること。フィールドデータにはノイズが含まれ、地域やキャリア、デバイス差でパーセンタイルが変動します。RUMは意味のあるコホートでセグメント化して実際の退行を特定してください。

トレードオフを受け入れるべき時

一部のページは本質的にCPUやネットワークコストを要する複雑なインタラクティブ体験を提供します。機能が製品のコアであり測定可能なユーザーバリューを生むなら、そのトレードオフをドキュメント化し、その他の部分を徹底的に最適化してユーザー行動を監視してください。機能を丸ごと削除するよりも、その機能のコストを下げる修正（インクリメンタルハイドレーション、パーシャルハイドレーション、重いコードを遅延バンドルに分離するなど）を優先します。

FAQ