2026年のCore Web Vitals：本当に順位を動かすもの

現在のCore Web Vitalsが測定するもの

Core Web Vitalsは、実際の訪問者がページをどう体感しているかを示す3つの指標です。Largest Contentful Paint（LCP）は読み込みを測定し、メイン画像やテキストブロックが表示されるまでの時間を示します。Interaction to Next Paint（INP）は応答性を測定し、タップ、クリック、キー入力の後にページが目に見えて反応するまでの時間を示します。Cumulative Layout Shift（CLS）は視覚的な安定性を測定し、読み込み中にコンテンツがどれだけずれるかを示します。

訪問の75%以上が「良好」の範囲に入ればページは合格です。基準はLCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。モバイルとデスクトップは別々に評価され、ほぼ常にモバイルの方が厳しくなります。

INPは2024年3月、First Input Delay（FID）に代わってCore Web Vitalsの指標になりました。FIDは最初の操作までの遅延のみを測定していましたが、INPは訪問全体で最も遅い操作を評価します。FIDでは余裕で合格だった多くのサイトが、INPでは要改善または不良になりました。

検索順位にどの程度影響するのか

Core Web VitalsはGoogleのページエクスペリエンスシグナルの一部です。関連性より優先されることはなく、最良の回答を持つ遅いページは、内容の薄い速いページに勝ちます。影響が出るのは同程度の品質のページ同士の比較と、コンバージョンです。順位にかかわらず、訪問者は遅くて表示がずれるページから離脱します。

そのため当社では、Core Web VitalsをまずビジネスKPIとして、次にSEOの指標として扱っています。速いページほど売上や問い合わせが増え、広告費も抑えられます。

フィールドデータとラボデータ

LighthouseやPageSpeed Insightsのラボスコアは、速度を制限した端末で1回の訪問をシミュレーションしたものです。デバッグには役立ちますが、Googleが順位付けに使うのは、Chrome User Experience Report（CrUX）のフィールドデータ、つまり実際のChromeユーザーから28日間にわたって収集したデータです。

まずSearch ConsoleのCore Web Vitalsレポートで、どのURLグループがどの指標で不合格かを確認しましょう。次にPageSpeed Insightsで個別URLのフィールドデータを確認し、Chrome DevToolsのPerformanceパネルで原因を特定します。

LCPの改善

LCPの問題の多くは、サーバーの応答の遅さ、ヒーロー画像の検出の遅れ、レンダリングを妨げるCSSとフォント、単純に大きすぎる画像、の4つが原因です。

• Time to First Byteを約800 ms未満に抑えます。匿名訪問者向けのページ全体キャッシュ、CDN、高速なデータベースクエリが有効です。
• LCP画像は絶対に遅延読み込みにしないでください。fetchpriority="high" を指定し、CSSで設定している場合はプリロードします。
• 1枚の大きなJPEGではなく、srcset と sizes を使って適切なサイズのAVIFまたはWebPを配信します。
• クリティカルCSSをインライン化し、残りはブロックせずに読み込みます。フォントはセルフホストし、font-display: swap を使用します。

INPの改善

INPはほぼ常にJavaScriptの問題です。メインスレッドが50 msを超える長いタスクで占有されていると、ブラウザはそのタスクが終わるまでユーザーのタップに反応できません。

まずサードパーティのスクリプトを監査してください。チャットウィジェット、ヒートマップ、A/Bテストツール、複数のタグコンテナは、数百ミリ秒を追加することがよくあります。操作後または特定のページでのみ読み込むようにしましょう。自社のコードでは、イベントハンドラーを小さく保ち、入力ハンドラーにデバウンスを適用し、長い処理を小さな単位に分割してブラウザが合間に描画できるようにします。DOMが非常に大きい（数千要素）場合もすべての操作が遅くなり、これはページビルダーでよく見られます。

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

CLSの改善

• 画像、動画、iframeには必ず width と height（または aspect-ratio）を指定します。
• 広告、埋め込み、Cookieバナーは、読み込み時にコンテンツを押し下げるのではなく、あらかじめ表示領域を確保します。
• ページの描画後に、既存コンテンツの上へバナーやお知らせを挿入しないようにします。
• Webフォントの読み込み時にテキストが再配置されないよう、メトリクスを合わせた代替フォント（size-adjust）を使用します。

LaravelとWordPressのポイント

Laravelですぐに効果が出るのは、本番用キャッシュ（php artisan config:cache、route:cache、view:cache）、OPcache、キャッシュとセッションへのRedisの利用、そして最初の1バイトを遅らせるN+1クエリをなくすEager Loadingです。アセットはViteでビルドしてCSSとJavaScriptを圧縮・バージョン管理し、メール送信やAPI呼び出しなどの重い処理はキューに移します。

WordPressの問題の多くはプラグインが原因です。不要なプラグインを削除し、適切なページキャッシュ（LiteSpeedサーバーではLiteSpeed Cacheが非常に効果的）を使い、アップロード時に画像を最適化し、PHPはサポート対象の8.xを維持し、重いページビルダーには注意してください。

測定して、待つ

オープンソースの web-vitals ライブラリを導入し、実際のLCP、INP、CLSの値をGA4または独自のエンドポイントに送信すれば、CrUXを待たずに数日で変化を確認できます。Search Consoleのレポートは直近28日間のデータを使うため、修正後にステータスが合格になるまで約4週間かかります。新しいデータが揃ったら、Search Consoleで修正を検証してください。

自社サイトの状況をすぐに把握したい場合は、無料Webサイトチェッカーが、応答の遅さ、圧縮の未設定などのよくある原因を検出します。