Core Web Vitalsとページ速度の最適化：2026年版完全ガイド

Core Web Vitalsとは何か？

Core Web Vitalsとは、Googleがウェブページの実際のユーザー体験を測定するために使用する3つの重要指標です。

2021年にランキング要因として採用され、2026年現在もその重要性は増し続けています。Googleはアップデートのたびにユーザー体験をより重視する方向へと向かっています。

これらの指標は「テクニカルSEO」だけの問題ではありません。コンバージョン率にも直接影響します。ページが遅ければ、潜在顧客は競合サイトへと流れてしまいます。

3つのコア指標

LCP — Largest Contentful Paint

ページのメインコンテンツが表示されるまでの時間を計測します。

ユーザーがページを開いたとき、最大のコンテンツ要素（ヒーロー画像、大きなテキストブロック、動画など）が実際に表示されるまでどれくらいかかるかを示します。

評価	時間
良好	≤ 2.5秒
要改善	2.5 〜 4秒
不良	> 4秒

LCPを悪化させる要因：

サーバー応答時間（TTFB）が遅い
レンダリングをブロックするCSSとJavaScript
読み込みが遅い画像と動画
クライアントサイドレンダリングの遅延

INP — Interaction to Next Paint

ページがユーザーの操作にどれだけ素早く反応するかを測定します。

INPは2024年にFID（First Input Delay）と置き換わりました。FIDが最初の操作だけを計測していたのに対し、INPはクリック・タップ・キーボード入力を含むあらゆる操作をカバーします。

評価	時間
良好	≤ 200 ms
要改善	200 〜 500 ms
不良	> 500 ms

INPを悪化させる要因：

長時間実行されるJavaScriptタスク
重いサードパーティスクリプト
メインスレッドをブロックする処理
過度に大きなDOMサイズ

CLS — Cumulative Layout Shift

ページ読み込み中に発生する予期しないレイアウトのズレを測定します。

経験があるでしょう。ボタンをクリックしようとした瞬間にページが突然動いて、まったく別の場所をクリックしてしまう。それがCLSの問題です。

評価	スコア
良好	≤ 0.1
要改善	0.1 〜 0.25
不良	> 0.25

CLSを悪化させる要因：

サイズが指定されていない画像や動画
動的に挿入されるコンテンツ（広告、バナーなど）
遅延読み込みのウェブフォント
サイズ未指定のiframe

Core Web Vitalsの計測方法

ラボデータ（シミュレーション）

Google PageSpeed Insights： ラボデータとフィールドデータの両方を提供
Lighthouse： Chrome DevToolsに組み込まれているツール
WebPageTest： 詳細なウォーターフォール分析

ラボデータは制御された環境で計測されます。実際のユーザー体験を完全に反映するわけではありませんが、問題の特定に最適です。

フィールドデータ（実際のユーザー）

Google Search Console： CWVレポートは実際のユーザーデータをもとにしています
Chrome UX Report（CrUX）： Chromeユーザーから収集した匿名データ
PageSpeed Insights： 「このURLのフィールドデータ」セクション

Googleはランキングにフィールドデータを使用します。ラボスコアが優秀でも、フィールドデータが悪ければ順位には影響します。

LCPの最適化

サーバー応答時間（TTFB）の短縮

サーバー応答時間はLCPの基盤です。

CDNの活用： ユーザーに最も近いサーバーからコンテンツを配信する
サーバーサイドキャッシュ： データベースクエリとページ出力をキャッシュする
HTTP/2またはHTTP/3の使用： リソースの並列読み込みを可能にする
TTFBの目標： 800 ms未満

画像の最適化

ほとんどのページでLCP要素となるのが画像です。

WebPまたはAVIFの使用 — JPEGより25〜50%軽量
レスポンシブ画像： srcsetとsizes属性を使ってデバイスに適したサイズを配信する
遅延読み込み： スクロールしないと見えない画像にloading="lazy"を追加する
LCP画像のプリロード： <link rel="preload" as="image" href="hero.webp">
CDN経由での配信： Imgix、Cloudinary、Cloudflare Imagesなどを利用する

レンダリングブロックリソースの排除

CSSとJavaScriptファイルがページのレンダリングを妨げることがあります。

クリティカルCSSをインライン化： ファーストビューのスタイルを<style>タグに直接記述する
CSSの非同期読み込み： media="print" onload="this.media='all'"
JavaScriptをdeferまたはasyncに： <script defer>
未使用CSSの削除： PurgeCSS等のツールを活用する

フォントの最適化

ウェブフォントはLCPに大きく影響することがあります。

font-display: swapを使用 — ウェブフォントが読み込まれるまでシステムフォントを表示する
フォントファイルをプリロード：<link rel="preload" as="font" type="font/woff2">
実際に使用する文字サブセットだけを読み込む
可能な場合はシステムフォントを検討する

INPの最適化

長いJavaScriptタスクの分割

ブラウザのメインスレッドが50msを超えるタスクで占有されると、ユーザー操作に応答できなくなります。

大きなJavaScriptバンドルをコード分割する
requestIdleCallbackやscheduler.yield()で長いタスクを分割する
Web Workersに処理を移す： メインスレッドとは独立して動くバックグラウンド処理

サードパーティスクリプトの監査

アナリティクス、広告、ライブチャット、ソーシャル埋め込み — これらはすべてメインスレッドの時間を奪い合います。

すべてのスクリプトの影響を計測する
必須でないものは削除する
残りのスクリプトはdeferまたは動的インポートで読み込む
ファサードパターンを活用する — 例えばYouTube埋め込みをすぐ読み込まず、サムネイル画像を代わりに表示する

DOMサイズの縮小

DOMが肥大化すると、あらゆる操作が遅くなります。

DOM要素数は1,500を超えないようにする
ネストの深さは32レベル以内に抑える
不要なラッパーdivを削除する
長いリストには仮想スクロールを使用 — ビューポート内の要素だけをレンダリングする

CLSの最適化

画像・動画への明示的なサイズ指定

すべての<img>と<video>要素にwidthとheight属性を追加してください。

<img src="photo.webp" width="800" height="600" alt="説明文">

画像が読み込まれる前にブラウザがスペースを確保するため、レイアウトのズレが発生しません。

モダンなアプローチとして、CSSのaspect-ratioプロパティを使用する方法もあります。

広告と動的コンテンツ

広告はCLSの最大の敵です。

min-heightを使って広告スロットの固定スペースを確保する
広告が表示されていない場合もコンテナが崩れないようにする
スティッキー広告の配置を優先する

フォントのズレを防ぐ

ウェブフォントが読み込まれると、テキストのサイズが変わってレイアウトがズレることがあります。

font-display: swapまたはoptionalを使用する
size-adjustを使ってフォールバックシステムフォントのメトリクスに合わせる
<head>内でフォントをプリロードする

ページ速度の一般的な最適化

キャッシュ戦略

適切なキャッシュ設定は、リピートアクセス時の速度を劇的に向上させます。

ブラウザキャッシュ： Cache-Controlヘッダーを適切に設定する
Service Worker： オフラインアクセスと細かいキャッシュ制御を可能にする
CDNキャッシュ： エッジサーバーで静的アセットをキャッシュする

CSS・JS・画像などの静的アセットには長期キャッシュ（1年）を。HTMLには短期または無キャッシュを設定します。

HTTPリクエストの削減

HTTPリクエストはすべてレイテンシの原因になります。

CSSとJavaScriptファイルをバンドルする
個別画像の代わりにSVGアイコンセットを使用する
不要なサードパーティリクエストを削除する
dns-prefetchとpreconnectでDNS解決時間を短縮する

圧縮

GzipまたはBrotli圧縮を使用 — ファイルサイズを60〜80%削減
BrotliはGzipより15〜20%優れた圧縮率
サーバー設定で圧縮を有効にする

モダンな画像フォーマット

フォーマット	利点
WebP	JPEGより25〜35%軽量、ブラウザサポートも広い
AVIF	WebPより約20%軽量、サポートが拡大中
SVG	ベクター形式、無限にスケール可能、ファイルサイズが小さい

各画像フォーマットに対するフォールバック戦略を構築しましょう。

パフォーマンスバジェット

ページ速度を守る最も確実な方法は、最初からパフォーマンスバジェットを設定することです。

パフォーマンスバジェットの例：

ページ総サイズ：< 1.5 MB
JavaScript：< 300 KB（圧縮後）
画像：< 500 KB
LCP：< 2秒
INP：< 150 ms
HTTPリクエスト数：< 50

このバジェットをCI/CDパイプラインに組み込み、超過するデプロイをブロックしましょう。

モバイルパフォーマンス

モバイルデバイスはデスクトップに比べてプロセッサが遅く、ネットワーク接続も不安定です。

Googleはモバイルファーストインデックスを採用しています。モバイルのパフォーマンスが低ければ、デスクトップの順位にも影響します。

3G接続でテストする
Chrome DevToolsのスロットリングを使ってローエンドデバイスでテストする
AMPやパフォーマンス重視のフレームワークを検討する

Core Web VitalsとSEO

GoogleはCWVをランキングシグナルとして使用していますが、実際にはどのような意味があるのでしょうか？

CWVだけで1位を獲得することはできません。しかし、コンテンツの質とバックリンクプロフィールが同等の2ページがあった場合、CWVが決定打になることがあります。

間接的な効果も同様に重要です：

速いページ → 直帰率の低下
優れたUX → エンゲージメントの向上
エンゲージメントの向上 → ユーザーシグナルの強化
ユーザーシグナルの強化 → 順位の改善

このドミノ効果によって、CWVは単純なランキング要因以上の価値を持ちます。

Eコマースとページ速度

Eコマースサイトでは、ページ速度は収益に直結します。

速度が1%改善 → コンバージョンが平均約2%向上
3秒以上かかるページ → 訪問者の53%が離脱
モバイルのコンバージョン率はデスクトップの約半分 — 速度改善でこのギャップを縮められる

CWVの継続的なモニタリング

一度最適化するだけでは不十分です。新しいコンテンツ、プラグイン、アップデートによってパフォーマンスが低下することがあります。

継続的なモニタリングツール：

Google Search Console — CWVレポート
PageSpeed Insights — ページ単位の分析
Web Vitals Chrome拡張機能 — リアルタイム計測
Lighthouse CI — パイプラインでの自動テスト

テクニカルSEOの問題を手動で追跡するのは時間がかかり、見落としも発生しやすいです。DexterGPTはサイトを自動クロールし、CWVやページ速度の問題を検出して、実行可能な改善提案を提供します。

まとめ

Core Web Vitalsとページ速度は、SEOのテクニカルな基盤を形成します。

LCP・INP・CLSを最適化することで、ユーザー体験と検索順位の両方が向上し、コンバージョンにも直接・測定可能な影響をもたらします。

パフォーマンス改善は一度きりのタスクではありません。継続的なプロセスです。計測し、最適化し、また計測する。このサイクルを止めてはなりません。

テクニカルSEOチェックリストでは、ページ速度以外のすべての項目を網羅的に解説しています。