Core Web Vitals に合格する方法：ステップバイステップ (2026年)

Core Web Vitals に合格するための最短ルート

あなたは Core Web Vitals の改善が必要なことをご存知でしょう。Google Search Console が赤やオレンジの警告を表示していたり、クライアントから質問されたり、あるいは PageSpeed Insights で悪い結果が出たりしたのかもしれません。このページでは、サイトを不合格から合格へと最速で導くために私が使用しているワークフローを紹介します。

私はこのワークフローを使って、数十万ページに及ぶサイトの Core Web Vitals 合格を支援してきました。WordPress、Shopify、カスタムビルドなど、あらゆるプラットフォームで機能します。修正する順番が重要です。まずは基盤を修正し、そこから外側に向かって作業を進めます。そうしないと、より根本的な問題によってかき消されてしまう最適化に時間を無駄にすることになります。

現在のウェブの状況

2025年の Web Almanac (2025年7月の CrUX データに基づく) によると、3つの Core Web Vitals すべてに合格しているのは、モバイルウェブサイトの48%、デスクトップウェブサイトの56%です。これは2024年のモバイル44%から改善していますが、依然としてモバイルウェブの半分以上が不合格であることを意味しています。

指標別の内訳 (モバイルで「良好」と評価されたオリジンの割合)：

出典：2025 Web Almanac (HTTP Archive、2025年7月の CrUX データ)。監視対象サイト全体の CoreDash RUM データでも同様の分布が見られます。

LCP がボトルネックです。77%が INP に合格し、81%が CLS に合格していますが、LCP に合格しているのはわずか62%です。これが全体の合格率を48%まで引き下げている原因です。そのため、以下のワークフローでは TTFB と LCP を最優先しています。

CoreDash の集計データも同じことを物語っています。このワークフロー (TTFB → LCP → INP → CLS の順) を正確に実施したサイトにおいて、CrUX で「不合格」から「3つの指標すべてで合格」するまでの平均期間は4〜6週間でした。実装に1〜2週間かかり、さらにその改善が CrUX の28日間のローリングウィンドウに反映されるまでに2〜4週間かかります。TTFB を修正せずに JavaScript の最適化に直行したサイトは、基盤が不安定なため、合格するまでに2〜3倍の時間がかかりました。

ステップ1：現状を評価する

何かを変更する前に、どの指標がどのページで不合格になっているかを正確に把握してください。これをスキップして推測で進めると、間違った箇所を修正して時間を無駄にすることになります。

Google Search Console を確認する

Search Console プロパティに移動し、「エクスペリエンス」の下にある Core Web Vitals レポートを開きます。ここには以下の情報が表示されます：

• 「良好」「改善が必要」「不良」と評価された URL の数
• 不合格となっている特定の指標 (LCP、INP、または CLS)
• 同じ問題を共有する URL グループ (例：すべての製品ページが INP で不合格になっているなど)

Search Console は、28日間のローリングウィンドウにわたる Chrome ユーザーの実際のフィールドデータを使用します。これは Google がランキングに使用するデータです。Lighthouse の結果がどうであれ、Search Console で合格と表示されていれば、合格です。

主要なページで PageSpeed Insights を実行する

各ページタイプ (ホームページ、ブログ記事、製品ページ、カテゴリー/コレクションページ) の URL を少なくとも1つテストします。PageSpeed Insights は、フィールドデータ (利用可能な場合) と、具体的な診断を伴うラボデータの両方を提供します。

まずは フィールドデータセクション (「実際のユーザーの環境で評価する」というラベル) を見てください。3つの指標すべてが緑色であれば、そのページは合格です。フィールドデータが利用できない場合は、そのページに CrUX データに十分なトラフィックがありません。その場合、Google はオリジンレベルまたは URL グループのデータを使用することがあります。

RUM (Real User Monitoring) をセットアップする

Search Console と CrUX には28日間のローリングウィンドウがあるため、改善が反映されるまでに数週間かかります。変更の即時的な影響を確認するには、CoreDash のような RUM (Real User Monitoring) ソリューションをセットアップします。RUM は、すべてのページ、すべてのデバイス、すべての国のリアルタイムのフィールドデータを提供するため、次の修正に進む前に、各修正が機能していることを検証できます。

ステップ2：最初に修正する指標を特定する

複数の指標が不合格になっている場合は、以下の順序で修正します：

TTFB はそれ自体が Core Web Vitals ではありませんが、TTFB のすべてのミリ秒は、LCP と FCP に直接加算されます。TTFB が800msのページは、ブラウザがレンダリングを開始する前に、すでに2.5秒の LCP 予算の3分の1を消費していることになります。CrUX における TTFB の「良好」のしきい値は800msですが、TTFB の改善は直接ペイントの指標に転化されるため、早ければ早いほど良いです。詳細は Time to First Byte ガイド をご覧ください。

ステップ3：基盤を修正する (TTFB)

Time to First Byte が常に400msを超えている場合は、ここから始めます。一般的な問題は以下の通りです：

• ホスティングが遅い：サーバーレベルのキャッシングを備えた高品質なホスティングにアップグレードします。WordPress のマネージドホスト (Kinsta、SiteGround、Cloudways) や Shopify の組み込みインフラストラクチャはこれを処理します。
• ページキャッシングがない：サーバーがリクエストごとに HTML を再生成しないように、CMS が完全にレンダリングされた HTML をキャッシュしていることを確認します。
• CDN がない：訪問者に近いエッジロケーションからページを配信するために CDN をセットアップします (Cloudflare は無料です)。Cloudflare 構成ガイド を参照してください。
• リダイレクト：リダイレクトのたびにラウンドトリップが追加されます。不要なリダイレクトチェーンを排除します。
• バックエンドが遅い：最適化されていないデータベースクエリ、多すぎる WordPress プラグイン、または重いサーバーサイド処理。クエリ監視ツールを使用してボトルネックを特定します。

目標：ほとんどの訪問者に対して TTFB を200ms未満にすること。少なくとも400ms未満にします。

ステップ4：LCP を修正する

TTFB が安定したら、Largest Contentful Paint を修正します。プロセスは以下の通りです：

LCP 要素を特定する

不合格になっているページを PageSpeed Insights で実行し、「診断」セクションで「最大コンテンツの描画要素 (Largest Contentful Paint element)」を見つけます。通常は、ヒーロー画像、アイキャッチ画像、または大きなテキストブロックです。

LCP が画像の場合

1. ブラウザが HTML 内でそれを見つけられることを確認する。画像の URL は、JavaScript によって読み込まれたり data-src 属性の背後に隠されたりするのではなく、通常の <img src=""> タグ内になければなりません。ブラウザの HTML パーサーが画像 URL を認識できない場合、早期に読み込みを開始することはできません。2025 Web Almanac によると、ウェブサイトの7%が依然としてこのように LCP 画像を隠しています。
2. <img> タグに fetchpriority="high" を追加する。これにより、帯域幅を競合している他のリソースよりもこの画像を優先するようブラウザに指示します。これがないと、ブラウザはスタイルシート、スクリプト、その他の画像を先にダウンロードする可能性があります。Google フライトでの Google のテスト では、この1つの変更で LCP が2.6秒から1.9秒に改善しました。
3. loading="lazy" を削除する。遅延読み込み (lazy loading) は、画像がビューポートに近づくまでリクエストを遅延させます。LCP 画像の場合、その遅延はそのまま LCP スコアに反映されます。
4. ファイルサイズを最適化する。WebP または AVIF に変換します。srcset と sizes を使用して、ビューポートに適した寸法の画像を提供します。
5. 画像が HTML 内にない場合 (CSS バックグラウンド画像、JavaScript 経由で読み込まれる画像、または <img> タグを変更できないページの場合)：プリロードを追加します。<head> 内で <link rel="preload" as="image" href="..." fetchpriority="high"> を使用します。プリロードは、HTML ソースに画像が表示されていない場合でも、ブラウザに画像を早期に発見させます。通常の <img> タグ内にすでにある画像の場合、パーサーがそれらをすでに見つけているため、通常はプリロードは不要です。

LCP がテキストの場合

1. レンダリングをブロックする CSS を排除する。クリティカル CSS を生成してインライン化し、ブラウザが外部スタイルシートを待たずにテキストをレンダリングできるようにします。
2. フォントの読み込みを最適化する。フォントをセルフホストし、主要なフォントファイルをプリロードして、テキストがレンダリングされるまでの時間を短縮します。
3. レンダリングをブロックする JavaScript を最小限に抑える。HTML パーサーをブロックしないように、クリティカルでない JavaScript を遅延 (defer) させます。

ステップ5：INP を修正する

LCP が合格したら、Interaction to Next Paint に取り組みます。INP は、ユーザーのインタラクション中に JavaScript がメインスレッドをブロックした場合に不合格になります。

ボトルネックを見つける

Chrome DevTools を開き、「パフォーマンス (Performance)」パネルに移動して、自分がページを操作している様子を記録します。ロングタスク (long tasks) (50ms を超えるタスク。赤いバーで表示されます) を探します。これらが、ブラウザがクリックに反応するのを妨げる原因です。

通常、メインスレッドをブロックするものは以下の通りです：

• メインスレッドの時間を競合するサードパーティスクリプト (アナリティクス、広告、チャットウィジェット、マーケティングタグ)
• ページ読み込み中に実行される、フレームワーク、ページビルダー、またはプラグインからの巨大な JavaScript バンドル
• クリックやキー入力の応答として過剰な処理を行う最適化されていないイベントハンドラ

修正の優先順位

1. サードパーティスクリプトを遅らせる。チャット、アナリティクス、ソーシャル、マーケティングの各スクリプトは、ページの読み込み中ではなく、最初のユーザーインタラクションの後に読み込まれるべきです。
2. クリティカルでないファーストパーティの JavaScript を遅延させる。ページがインタラクティブになる前に実行する必要のないスクリプトには、defer または async を使用します。
3. ロングタスクを分割する。自身のコードに50msを超える処理を行う関数がある場合は、メインスレッドを明け渡し (yielding)、一連の処理の間にブラウザがユーザー入力に応答できるようにします。モダンな方法は scheduler.yield() です (Chrome 129以降および Edge でサポート)。より幅広いブラウザに対応させる場合は、処理を Promise 内の setTimeout(resolve, 0) でラップするフォールバックを使用します：

   async function yieldToMain() {
     if ('scheduler' in window && 'yield' in scheduler) {
       return scheduler.yield();
     }
     return new Promise(resolve => setTimeout(resolve, 0));
   }

4. 使用されていない JavaScript を削除する。Chrome DevTools の「カバレッジ (Coverage)」タブを使用して、読み込まれているものの実行されていない JavaScript を特定します。それを削除するか、条件付きで読み込むようにします。

完全な INP 最適化戦略については、INP 最適化ガイド をご覧ください。

ステップ6：CLS を修正する

多くの場合、CLS は最も簡単に修正できる指標です。最も一般的な原因と解決策は以下の通りです：

寸法の指定がない画像

すべての <img> タグには、明示的な width と height 属性が必要です。これらがないと、ブラウザはどれだけのスペースを確保すべきか分からず、画像が読み込まれたときにコンテンツが移動 (シフト) します。これは世界中で CLS の原因の第1位です。CLS ガイド をご覧ください。

Web フォントの入れ替え

Web フォントが読み込まれてフォールバックフォントと置き換わる際、テキストが再配置され、周囲の要素が移動することがあります。解決策：フォントをセルフホストし、font-display: optional を使用するか、CSS の size-adjust プロパティを使用してフォールバックフォントのメトリクスを Web フォントに合わせます。

動的に挿入されるコンテンツ

読み込み後にコンテンツを押し下げる Cookie バナー、通知バー、広告枠、ポップアップなど。解決策：CSS の min-height でこれらの要素のスペースを確保するか、周囲のレイアウトに影響を与えない方法で読み込みます (例：インライン挿入ではなくオーバーレイ)。

ステップ7：フィールドデータで検証する

修正を実装した後は、Lighthouse だけでなく、現実世界で機能することを検証する必要があります。

• 即時検証：CoreDash などの RUM ツールを使用して、リアルタイムのフィールドデータを確認します。変更は数時間以内に反映されるはずです。
• CrUX の検証：Chrome User Experience Report (CrUX) は28日間のローリングウィンドウを使用します。改善が CrUX データに完全に反映されるまでに2〜4週間かかることを想定してください。
• Search Console の検証：Search Console の Core Web Vitals レポートは CrUX に基づいて更新されます。CrUX で改善が見られれば、Search Console もそれに続きます。

このタイムラグがあるため、RUM は不可欠です。RUM がなければ、変更が実際に機能したかどうかを数週間後まで確認することができません。

ステップ8：監視と維持

パフォーマンスは後退します。新しいプラグイン、テーマの更新、またはサードパーティスクリプトの導入により、あなたの努力が無駄になる可能性があります。継続的な監視を設定してください：

• Search Console の Core Web Vitals レポートを毎週確認する
• CoreDash を使用して、アラート付きの継続的なリアルタイム監視を行う
• 大幅な変更 (新しいプラグイン、テーマの更新、新しいサードパーティスクリプト) を行うたびに、PageSpeed Insights で再テストする
• サードパーティスクリプトを四半期ごとに監査する。不要になったものはすべて削除する。

確認すべきすべての項目の完全なリファレンスについては、Ultimate Core Web Vitals Checklist をご利用ください。

クイックウィン：最も大きな影響を与える修正

5つのことしか行う時間がない場合、これらがすべてのプラットフォームにおいて最も影響の大きい修正です：

これらの影響範囲は、最適化プロジェクト全体における CoreDash のリアルユーザーモニタリングデータに基づいています。実際の改善度合いは、開始時点の状態、ホスティング、トラフィックプロファイルによって異なります。スコアが非常に悪い状態 (LCP が5秒以上) からスタートしたサイトは、さらに大きな改善を見ることがよくあります。すでにしきい値に近いサイトでは、絶対的な改善幅は小さいかもしれませんが、不合格と合格の分かれ目になる可能性があります。

2025 Web Almanac のデータも、これらの優先順位を裏付けています。モバイルにおける Core Web Vitals の合格率は、ホームページが45%であるのに対し、セカンダリページは56%です。この差は、ホームページには動的コンテンツ、大きなヒーロー画像、サードパーティスクリプトが多く含まれる傾向があるためです。ホームページが不合格で内部ページが合格している場合は、LCP と INP の最適化の労力をホームページテンプレートに集中させてください。