コアウェブバイタル：LCP、INP、CLSの解説と改善方法
· 12分で読めます
目次
コアウェブバイタルは、ウェブ上のユーザーエクスペリエンスを測定するためのGoogleの公式指標です。2021年6月にランキング要因となって以来、開発者、SEO担当者、サイト所有者がページパフォーマンスにアプローチする方法を根本的に変革してきました。この包括的なガイドでは、各指標を分解し、スコアが低くなる原因を説明し、すぐに実装できる具体的で実行可能な修正方法を提供します。
eコマースサイト、コンテンツプラットフォーム、SaaSアプリケーションのいずれを最適化する場合でも、コアウェブバイタルの理解と改善はもはやオプションではありません。検索の可視性とユーザー満足度の両方にとって不可欠です。
コアウェブバイタルとは？
コアウェブバイタル（CWV）は、Googleが優れたユーザーエクスペリエンスを提供するために不可欠と考える3つの特定の指標のセットです。これらは、ユーザーがウェブサイトをどのように認識し、どのようにインタラクションするかに直接影響を与えるページパフォーマンスの3つの重要な側面を測定します。
3つのコアウェブバイタルは以下の通りです：
- 最大コンテンツの描画（LCP） — 最大の可視コンテンツ要素がレンダリングされるタイミングを追跡することで、読み込みパフォーマンスを測定します
- 次のペイントまでのインタラクション（INP） — ページがすべてのユーザーインタラクションにどれだけ迅速に応答するかを評価することで、インタラクティブ性を測定します
- 累積レイアウトシフト（CLS） — ページ読み込み中の予期しないレイアウトシフトを定量化することで、視覚的安定性を測定します
制御された環境で実行される合成ラボテストとは異なり、Googleはクロームユーザーエクスペリエンスレポート（CrUX）を通じて実際のChromeユーザーからの実世界のデータを使用してコアウェブバイタルを評価します。つまり、開発環境だけでなく、さまざまなネットワーク条件下で実際のデバイスを使用する実際のユーザーに対して、サイトが良好に機能する必要があります。
プロのヒント：Googleは、各指標について、ページ訪問の75%が「良好」のしきい値を満たすことを要求しています。単一の完璧なテストスコアでは不十分です。ユーザーベース全体で一貫したパフォーマンスが必要です。
コアウェブバイタルの進化
コアウェブバイタルは静的ではありません。Googleは当初、インタラクティブ性の指標として初回入力遅延（FID）を含めていましたが、2024年3月に次のペイントまでのインタラクション（INP）に置き換えました。この変更は、測定しやすいものではなく、ユーザーにとって実際に重要なものを測定するというGoogleのコミットメントを反映しています。
FIDからINPへの移行は重要でした。なぜなら、FIDは最初のインタラクションのみを測定していたのに対し、INPはページライフサイクル全体のすべてのインタラクションを評価するからです。これにより、応答性のより包括的なビューが提供され、ユーザーのフラストレーションとより良く相関します。
コアウェブバイタルがSEOとビジネスに重要な理由
コアウェブバイタルは、モバイルフレンドリー性、HTTPSセキュリティ、邪魔な広告の不在も含むGoogleのページエクスペリエンスシグナルの一部です。コンテンツの関連性と権威性が依然としてランキングを支配していますが、CWVはタイブレーカーとして機能します。2つのページが同等に関連性がある場合、パフォーマンスが優れている方が勝ちます。
しかし、影響は検索ランキングをはるかに超えて広がります。パフォーマンスは収益に直接影響します：
| 指標の改善 | ビジネスへの影響 | 出典 |
|---|---|---|
| すべてのCWVしきい値をクリア | ページ離脱が24%減少 | Google/SOASTA調査 |
| LCPを100ms改善 | コンバージョン率が1.7%増加 | Deloitte Digital |
| CLSを0.1改善 | 直帰率が3.2%減少 | Akamai調査 |
| INPを200ms改善 | エンゲージメントが5.8%増加 | クロームユーザーエクスペリエンスレポート |
実世界のケーススタディがこれらの影響を実証しています。VodafoneがLCPを31%改善したとき、売上が8%増加しました。Yahoo JapanがCLSを0.2削減したとき、セッション時間が15%増加しました。これらは限界的な利益ではなく、ビジネスを変革する改善です。
モバイルファーストの現実
Googleのモバイルファーストインデックスにより、モバイルのコアウェブバイタルスコアが最も重要です。モバイルデバイスは通常、デスクトップコンピューターよりもプロセッサが遅く、メモリが少なく、ネットワーク条件がより変動しやすいため、最適化がより困難ですが、より重要でもあります。
モバイルユーザーも寛容ではありません。Googleの調査によると、モバイルユーザーの53%が、読み込みに3秒以上かかるサイトを放棄します。コアウェブバイタルの低さは、これらの離脱率に直接寄与します。
最大コンテンツの描画（LCP）
最大コンテンツの描画は、ビューポート内で最大の可視コンテンツ要素がレンダリングされるまでにかかる時間を測定します。これは通常、ヒーロー画像、ビデオサムネイル、大きなテキストブロック、または背景画像です。LCPは最も直感的なコアウェブバイタルです。なぜなら、「このページはいつ読み込まれたか？」というユーザーの認識と直接相関するからです。
LCPのしきい値
| 評価 | LCP時間 | ユーザーエクスペリエンス |
|---|---|---|
| 良好 | ≤ 2.5秒 | 高速、レスポンシブ、プロフェッショナル |
| 改善が必要 | 2.5 - 4.0秒 | 許容範囲だが遅延が目立つ |
| 不良 | > 4.0秒 | イライラする、離脱する可能性が高い |
LCPとしてカウントされる要素は？
ページ上のすべての要素がLCP要素になる資格があるわけではありません。これらの要素タイプのみが考慮されます：
<img>要素<svg>内の<image>要素- ポスター画像を持つ
<video>要素 - CSSの
url()を介して読み込まれた背景画像を持つ要素 - テキストノードを含むブロックレベル要素
LCP要素は、ページの読み込み中に変化する可能性があります。最初はテキスト見出しかもしれませんが、ヒーロー画像が読み込まれると、それが新しいLCP要素になります。最終的なLCPは、ユーザーがページとインタラクションを開始するか、離れるときに記録されます。
一般的なLCPの問題と解決策
問題1：サーバー応答時間が遅い
最初のバイトまでの時間（TTFB）が遅い場合、他のすべてが影響を受けます。ブラウザはHTMLドキュメントを受信するまでレンダリングを開始できません。
解決策：
- コンテンツ配信ネットワーク（CDN）を使用して、ユーザーに近い場所からコンテンツを配信する
- RedisまたはMemcachedでサーバーサイドキャッシングを実装する
- データベースクエリを最適化し、適切なインデックスを追加する
- 多重化とヘッダー圧縮のためにHTTP/2またはHTTP/3を使用する
- Cloudflare WorkersやVercel Edge Functionsなどのエッジコンピューティングソリューションを検討する
問題2：レンダリングをブロックするリソース
<head>内のCSSおよびJavaScriptファイルは、ダウンロードおよび処理されるまでレンダリングをブロックします。
解決策：
- スクロールせずに見える範囲のコンテンツ用に、クリティカルCSSをHTMLに直接インライン化する
media="print" onload="this.media='all'"を使用して、非クリティカルCSSを遅延させる- スクリプトタグに
asyncまたはdefer属性を追加する - PurgeCSSなどのツールで未使用のCSSとJavaScriptを削除する
- コード分割で大きなバンドルを小さなチャンクに分割する
クイックヒント：当社のページスピードアナライザーを使用して、レンダリングをブロックするリソースを特定し、サイトに特化した推奨事項を取得してください。
問題3：大きな画像ファイル
最適化されていない画像は、最も一般的なLCPの原因です。5MBのヒーロー画像はLCPスコアを破壊します。
解決策：
- WebPやAVIFなどの最新フォーマットを使用して画像を圧縮する（JPEGより70〜90%小さい）
srcsetおよびsizes属性でレスポンシブ画像を実装する- 画像を自動的に最適化およびリサイズする画像CDNを使用する
- LCP画像に
fetchpriority="high"を追加して、ダウンロードを優先する <link rel="preload" as="image">でLCP画像をプリロードする
問題4：クライアントサイドレンダリング
LCP要素がJavaScriptによってレンダリングされる場合、ユーザーはコンテンツを見る前にJSのダウンロード、解析、実行を待つ必要があります。
解決策：
- サーバーサイドレンダリング（SSR）または静的サイト生成（SSG）を使用する
- React Server Componentsまたは類似の技術でストリーミングSSRを実装する
- プログレッシブエンハンスメントを使用する—基本バージョンをサーバーサイドでレンダリングし、JavaScriptで強化する
- JavaScript実行時間を削減するために部分的なハイドレーションを検討する
高度なLCP最適化
すでに2.5秒のしきい値を満たしているサイトの場合、これらの高度なテクニックにより、トップパフォーマンス層に押し上げることができます：
リソースヒント：重要なサードパーティのオリジンに対して<link rel="preconnect">を使用して、早期に接続を確立します。重要度の低いオリジンには<link rel="dns-prefetch">を使用します。
優先度ヒント：fetchpriority属性は、どのリソースが最も重要かをブラウザに伝えます。LCP画像にfetchpriority="high"を設定し、スクロールせずに見えない範囲の画像にfetchpriority="low"を設定します。
103 Early Hints：このHTTPステータスコードにより、サーバーはメインレスポンスの準備が整う前にプリロードヒントを送信でき、ブラウザが重要なリソースのダウンロードを先行して開始できます。
次のペイントまでのインタラクション（INP）
次のペイントまでのインタラクションは、ページライフサイクル全体を通じてユーザーインタラクションに対するページの応答性を測定します。最初のインタラクションのみを測定していた前身のFIDとは異なり、INPはすべてのクリック、タップ、キーボード押下を評価して、インタラクティブ性の包括的なビューを提供します。
INPは、ユーザーがインタラクションを開始してから、ブラウザがそのインタラクションの視覚的結果を示す次のフレームをペイントするまでの時間を測定します。これには、入力遅延、処理時間、プレゼンテーション遅延が含まれます。
INPのしきい値
| 評価 | INP時間 | ユーザーエクスペリエンス |
|---|---|---|
| 良好 | ≤ 200ミリ秒 | 即座、レスポンシブなフィードバック |
| 改善が必要 | 200 - 500ミリ秒 | 目立つが許容できる遅延 |
| 不良 | > 500ミリ秒 | 鈍い、応答しない、壊れている |
INPコンポーネントの理解
INPは3つのフェーズで構成されます：
- 入力遅延：ユーザーアクションからイベントハンドラーの実行開始までの時間（メインスレッドが利用可能である必要があります）
- 処理時間：イベントハンドラーと関連するJavaScriptの実行に費やされる時間
- プレゼンテーション遅延：ハンドラーの完了からブラウザが次のフレームをペイントするまでの時間