ページ表示が遅い？AI検索に備えるCore Web Vitalsの確認手順

AI検索に備えて表示体験を確認する理由

Googleの「AI 機能とウェブサイト」では、AIによる概要やAIモードに表示されるためだけの追加要件や特別な最適化はなく、従来のSEOの基本が引き続き重要だと説明されています。その基本事項の一つとして、ユーザーにとって優れたページエクスペリエンスを提供することが挙げられています。

一方、Googleのページエクスペリエンスに関する公式資料では、ランキングシステムがCore Web Vitalsを使用する一方、良いスコアでも検索結果の上位表示は保証されないと説明されています。また、ページエクスペリエンスはCore Web Vitalsだけで決まるものではなく、関連性の高い有用な内容なども重要です。

これらを踏まえ、本記事ではCore Web Vitalsを「AI検索向けの裏技」ではなく、利用者が重要情報へ到達し、読み、操作できる状態を確認するための指標として扱うことを推奨します。数値を満点にすること自体を目的にせず、予約、購入、問い合わせ、料金確認など、事業上重要な行動を妨げる問題から直します。

Core Web Vitalsの3指標と基準値

Googleが公開するWeb Vitalsの公式資料では、現在のCore Web Vitalsは、読み込み、操作への応答、視覚的な安定性という3つの側面を測る指標で構成されています。良好と判断する目安は次のとおりです。

• LCP（Largest Contentful Paint）：2.5秒以内。ページ内の主要な画像や大きなテキストなどが表示されるまでの読み込み体験を測ります。
• INP（Interaction to Next Paint）：200ミリ秒以下。クリック、タップ、キー入力などに対して画面が反応するまでの操作体験を測ります。
• CLS（Cumulative Layout Shift）：0.1以下。読み込み中にボタンや文章の位置が予期せず動く度合いを測ります。

同資料では、モバイルとデスクトップを分け、ページ読み込みの75パーセンタイルで目標値を満たすかを評価すると説明されています。つまり、一度だけ速く表示できた結果ではなく、多くの利用者にとって安定して良い体験になっているかを見る考え方です。

実務上は、略称だけを管理表へ書くのではなく、「LCP＝主要内容の表示」「INP＝操作への応答」「CLS＝画面のずれ」と日本語の意味を併記すると、制作担当者以外とも問題を共有しやすくなります。

実測データと診断データの違い

フィールドデータは実際の利用状況を見る

GoogleのPageSpeed Insights公式資料によると、フィールドデータはChromeユーザーエクスペリエンスレポート（CrUX）に基づく、実際のユーザーから収集された匿名化データです。PageSpeed Insightsでは過去28日間の収集期間が示されます。十分なデータがないページでは、URL単位の結果が出ない場合や、サイト全体のオリジン単位へ切り替わる場合があります。

ラボデータは原因の切り分けに使う

同じ公式資料では、ラボデータは固定された条件でページ読み込みをシミュレーションした結果で、問題の診断に役立つ一方、実際の利用環境をそのまま表すものではないと説明されています。端末、回線、テスト時点などが異なるため、フィールドデータと数値が一致しないことがあります。

Search Consoleは傾向とURLグループを見る

Google Search ConsoleのCore Web Vitalsレポート公式ヘルプでは、実際の使用状況データをもとに、状態、指標、類似するページのURLグループ別に問題が示されると説明されています。モバイルとパソコンは別に確認でき、データ量が不足するURLはレポートに含まれない場合があります。

これらを踏まえ、本記事では、Search Consoleでサイト全体の傾向を見て、PageSpeed Insightsで重要な個別URLを確認し、ラボデータで修正候補を切り分ける使い分けを推奨します。ラボの一回の点数だけで「改善済み」と判断しないことが大切です。

小規模事業者向けの確認手順

以下はGoogleの必須手順ではなく、AI BRAND CHECK運営者による実務上の提案です。全ページを一度に調べるより、利用者と事業の双方に重要なページから着手すると整理しやすくなります。

1. 重要URLを3〜5件選ぶ：トップ、主力サービス、料金、予約・購入、問い合わせ直前のページを候補にします。
2. Search Consoleで全体傾向を見る：モバイルとパソコンを分け、「低速」「改善が必要」のURLグループと該当指標を記録します。
3. PageSpeed Insightsで個別URLを見る：フィールドデータがあるか、URL単位かオリジン単位かを確認し、ラボデータの改善案と混同しないようにします。
4. 実機で主要操作を試す：スマートフォンでページを開き、メニュー、予約ボタン、フォーム、絞り込みなどを操作します。数値と実際の困りごとを対応させます。
5. 変更を一まとまりずつ記録する：対象URL、指標、変更内容、実施日、担当者を残します。複数の大きな変更を同時に行うと、どの対応が影響したか判断しにくくなります。
6. 公開直後と実測データ更新後に確認する：公開直後は表示崩れやラボ診断を確認し、フィールドデータは集計期間を考慮して後日確認します。

指標別の改善候補と優先順位

次の項目は、原因を確定するものではなく、担当者へ確認するための候補です。テーマ、プラグイン、外部サービス、端末によって原因は異なります。バックアップと検証環境を用意し、影響範囲を確認してから変更してください。

LCPが課題の場合

• 最初に大きく表示される画像のファイルサイズ、形式、表示寸法が適切か
• 主要画像や見出しの表示を不要なスクリプトやCSSが遅らせていないか
• サーバー応答、キャッシュ、配信経路に遅延がないか

INPが課題の場合

• 予約、地図、チャット、広告、アクセス解析など外部スクリプトを過剰に読み込んでいないか
• クリック後に重い処理が連続し、画面更新を待たせていないか
• 使っていない機能やプラグインのJavaScriptが残っていないか

CLSが課題の場合

• 画像、動画、地図、埋め込み枠に表示領域が事前に確保されているか
• 読み込み後に告知やバナーを既存コンテンツの上へ差し込んでいないか
• Webフォントの切り替えで文章の幅や高さが大きく変わっていないか

実務上は、「悪い指標」だけでなく「その問題がどの重要行動を妨げるか」で優先順位を決めることを推奨します。たとえば、予約ボタンが移動して押し間違えやすい問題は、閲覧数の少ない参考ページのわずかな読み込み遅延より先に確認する、という考え方です。

よくある確認ミス

• ラボスコア100だけを目標にする：Google公式資料でも、良いCore Web Vitalsが上位表示を保証するわけではないと説明されています。利用者の課題と事業上の重要度を優先します。
• トップページだけ測る：検索やAI機能から料金・商品・サービスなどの下層ページへ直接到達する場合があります。重要なページ種類を分けて確認します。
• モバイルとパソコンを混ぜる：公式ツールはデバイス別に情報を示します。片方だけ良好でも、もう片方の問題は残り得ます。
• データ不足を合格とみなす：結果が表示されないことは、良好であることを意味しません。実機確認とラボ診断を補助的に使います。
• 改善案をすべて機械的に実行する：機能や計測を止めると事業運用に影響することがあります。目的、影響範囲、代替手段を確認してから実施します。

公開前後のチェックリスト

• トップ、主力サービス、料金、予約・購入、問い合わせ前の重要URLを選んだ
• Search Consoleをモバイルとパソコンに分けて確認した
• PageSpeed Insightsのフィールドデータとラボデータを区別した
• LCP、INP、CLSのうち、どの指標がどのページで課題か記録した
• 主要画像、外部スクリプト、埋め込み、フォント、レイアウトずれを実機で確認した
• 変更前後のURL、指標、実施日、担当者を記録した
• フォーム、予約、購入、電話などの主要機能が修正後も動作する
• 数値改善を検索順位やAI表示の保証として表現していない

Core Web Vitalsは一度測って終わる項目ではありません。テーマ、プラグイン、画像、計測タグ、予約サービスなどを変更したときに再確認すると、原因となった変更を追いやすくなります。確認頻度はサイトの更新量と重要度に合わせて決めてください。