Core Web Vitals改善の完全ガイド｜LCP・CLS・INP別の対策と測定方法

3つの指標を正確に理解する——LCP・CLS・INPの定義と閾値

Core Web Vitalsを構成する3つの指標は、それぞれ異なる体験上の問題を測定しています。改善施策を正しく優先するには、各指標が「何を・どう測っているか」と「なぜ悪化するか」をセットで理解しておく必要があります。

LCP（Largest Contentful Paint）——最大コンテンツの描画速度

LCPは、ページ内で最も面積の大きい画像またはテキストブロックが画面に描画されるまでの時間を測定します。ファーストビューで最初に目に入るメインビジュアルや見出し文字がLCPの対象になるケースがほとんどです。

主な悪化パターン

• ヒーロー画像のファイルサイズが大きく、サーバーからの転送に時間がかかっている
• 画像に loading="lazy" が設定されており、優先読み込みが遅れている
• レンダリングをブロックするCSSやJavaScriptが、描画の開始を遅らせている
• サーバーの初期応答（TTFB：Time to First Byte）自体が遅い

CLS（Cumulative Layout Shift）——レイアウトのずれ量

CLSは、ページ読み込み中に要素が予期せず移動した量の累積スコアを測定します。数値が大きいほど、読んでいたテキストがずれたり、押すつもりのないボタンをタップしてしまうといった体験上の問題が発生しやすくなります。

主な悪化パターン

• 画像やiframeにwidth・heightが指定されておらず、読み込み後にレイアウトが崩れる
• 後から挿入される広告バナーが周囲のコンテンツを押し下げる
• Webフォントの読み込み完了時にテキストの高さが変わり、直下の要素がずれる

INP（Interaction to Next Paint）——操作応答の体感速度

INPは、クリック・タップ・キー入力といったユーザー操作に対して、ブラウザが次の画面更新を完了するまでの時間を測定します。2024年3月にFID（First Input Delay）から置き換わった指標で、単発の初回操作だけでなく、ページ滞在中のすべての操作を対象としている点が特徴です。

主な悪化パターン

• JavaScriptのメインスレッドが重い処理を長時間占有し、操作への応答が詰まっている
• サードパーティスクリプト（チャットツール・タグマネージャーなど）が応答を遅らせている
• イベントハンドラー内で大量のDOM操作や再計算が発生している

3指標の合格基準と優先度の考え方

Googleが定める合格基準は以下のとおりです。

3指標すべてをGoodにすることが理想ですが、改善リソースが限られる場合はLCPを最初に優先するケースが多いです。LCPはページの第一印象に直結し、スコアが悪化しているサイトでも画像最適化やサーバー応答改善といった施策で比較的早く改善効果が出やすい傾向があります。CLSはスコアが高いと直帰率に悪影響が出やすく、INPはSPA（シングルページアプリケーション）構成のサイトで顕在化しやすいため、サイトの構造に応じて対処の順序を判断することが実務上の現実解になります。

Core Web VitalsがSEOの評価基準になった背景

ページ体験アップデートとCore Web Vitalsの関係

Googleは2021年6月、「ページ体験アップデート」を段階的に展開し、Core Web Vitals（コアウェブバイタル）を正式なランキング要因として組み込みました。それ以前のSEO評価は、コンテンツの質や被リンクの数・質が中心でした。しかしGoogleは、検索結果に表示されるページをユーザーが実際に開いたとき、どのような体験が得られるかをも評価基準に含めるべきと判断したのです。

この判断の背景には、モバイル利用の急拡大があります。表示が遅い・ボタンの位置がずれる・操作に反応しないといった体験は、ユーザーの直帰率を押し上げ、結果としてGoogleが目指す「検索体験の品質向上」を損なうものでした。Core Web Vitalsは、そうした体験の良否を数値で測るための代理変数として設計されており、単なる「ページ表示速度のSEO影響」を測る指標にとどまりません。

具体的には、LCP（Largest Contentful Paint：最大コンテンツ描画）・CLS（Cumulative Layout Shift：累積レイアウトシフト）・INP（Interaction to Next Paint：次のペイントまでのインタラクション）の3指標が、それぞれ読み込み速度・視覚的安定性・操作応答性を定量化しています。これら3つが揃うことで、ユーザーが体感するページ品質を多角的に捉えられる仕組みになっています。

FIDからINPへ——2024年の指標改定で何が変わったか

2024年3月、GoogleはFID（First Input Delay：初回入力遅延）をINP（Interaction to Next Paint）に置き換えました。この変更は、Core Web Vitals対策において見落とせないアップデートです。

FIDが計測していたのは、ユーザーが最初に操作したときの「遅延時間の発生有無」だけでした。一方INPは、ページ滞在中のすべての操作に対して、次の画面描画が完了するまでの時間を測定します。フォーム入力・メニュー展開・ボタンクリックなど、繰り返し発生するインタラクション全体の応答性を評価するため、実際のユーザー体験により近い指標といえます。

INPの合格水準は200ミリ秒以下とされており、JavaScriptの実行時間やメインスレッドの負荷が直接スコアに影響します。FID対応で完了と判断していたサイトも、INPの観点では改善余地が残っているケースが少なくありません。Core Web Vitals対策を今改めて見直すべき理由は、この指標改定にもあります。

測定ツールの選び方と使い方——ラボデータとフィールドデータの違いを踏まえて

ラボデータとフィールドデータ——数値が違う理由と正しい読み方

Core Web Vitalsを測定する前に、まず押さえておくべき前提があります。同じページを測定しても、ツールによってスコアが大きく異なるケースが少なくありません。その原因の多くは、ラボデータとフィールドデータの違いにあります。

ラボデータは、Lighthouseのような計測エンジンが一定の条件下でシミュレーションした結果です。デバイス性能・通信速度・キャッシュ状態などが固定されているため、再現性は高い一方、実際のユーザー環境とは乖離が生じます。

フィールドデータは、実際にそのページを訪問したユーザーのブラウザから収集した計測値です。Googleが「CrUX（Chrome UX Report）」として集計しており、SEOの評価に直接使われているのはこちらです。

つまり、PageSpeed InsightsでスコアがたとえGreenでも、実ユーザーの体感が悪ければSEO上の評価は改善されません。改善の優先順位を判断する際は、フィールドデータを主軸に置くことが重要です。

PageSpeed Insights——スコアの見方と改善ヒントの活用法

PageSpeed Insightsは、ラボデータとフィールドデータの両方を1画面で確認できる点が特徴です。URLを入力するだけで結果が得られるため、初期診断に適しています。

• 画面上部のフィールドデータ（実ユーザー）：LCP・CLS・INPの実績値が表示されます。Googleの評価に直結するため、まずここを確認します。
• 画面中部のラボデータ（Lighthouseスコア）：100点満点のスコアが表示されますが、あくまで参考値として扱います。
• 「診断」セクションの改善ヒント：具体的な改善候補がリストアップされます。「レンダーブロッキングリソースの排除」「未使用のJavaScriptの削減」など、優先度とともに確認できます。

Google Search Console「ウェブに関する主な指標」レポートの使い方

Google Search Consoleの「ウェブに関する主な指標」レポートは、サイト全体のフィールドデータをまとめて把握するのに適しています。特定のURLではなく、URLグループ単位で「良好・改善が必要・低速」に分類されるため、問題のあるページを一覧で特定できます。

まず全体像をこのレポートで把握し、問題のあるURLをPageSpeed Insightsで個別に深掘りするという流れが、実務上の標準的な進め方です。

Chrome DevTools・Lighthouse——ローカル環境での詳細診断

Chrome DevToolsとLighthouseは、開発・修正作業中にその場で効果を確認したい場面で活用します。外部ツールと異なり、ローカル環境や認証が必要なページでも計測できることが利点です。

DevToolsの「Performance」タブでは、LCPの対象要素やレイアウトシフトが発生したタイミングをタイムライン上で可視化できます。Lighthouseは「ネットワークスロットリング」を有効にして計測することで、低速回線のユーザー環境に近い条件でのスコアを確認できます。

各ツールの用途をまとめると、以下のように整理できます。

• サイト全体の問題把握：Google Search Console
• 特定URLの初期診断：PageSpeed Insights
• 修正効果の即時確認・詳細調査：Chrome DevTools・Lighthouse

3つの指標を正確に理解する——LCP・CLS・INPの定義と閾値

Core Web Vitalsを構成する3つの指標は、それぞれ異なる体験の質を測定しています。定義と閾値を正確に把握しておくことで、計測結果を見たときに「どの体験が損なわれているか」をすぐに特定できるようになります。

LCP（Largest Contentful Paint）——最大コンテンツの描画速度

LCPは、ページ内で最も面積の大きいコンテンツ要素（画像・見出しテキスト・動画のサムネイルなど）が画面に描画されるまでの時間を計測します。ユーザーが「ページが読み込まれた」と感じるタイミングに最も近い指標です。

合格基準：2.5秒以内がGood、4.0秒超はPoor。

LCPが悪化する代表的な原因は以下のとおりです。

• ファーストビューに配置した大きな画像が最適化されていない（高解像度・非圧縮のまま配信している）
• サーバーの応答が遅く、HTMLの取得自体に時間がかかっている
• LCP要素の読み込みをブロックするCSSやJavaScriptがレンダリングを遅延させている
• フォントの遅延読み込みにより、テキスト系のLCP要素の表示が後回しになっている

CLS（Cumulative Layout Shift）——レイアウトのずれ量

CLSは、ページの読み込み中に要素が予期せず移動した量を累積して数値化したものです。広告バナーが表示された瞬間にボタンがずれてタップミスが起きる、といった体験がスコアに直結します。

合格基準：0.1以下がGood、0.25超はPoor。

CLSが悪化する代表的な原因は以下のとおりです。

• 画像やiframeにwidth・heightの属性指定がなく、読み込み後にレイアウトが崩れる
• 非同期で読み込まれる広告・埋め込みコンテンツが後から領域を押し広げる
• Webフォントの読み込み完了時にテキストのサイズが変わり、周辺要素がずれる
• ユーザー操作とは無関係なアニメーションが要素を移動させている

INP（Interaction to Next Paint）——操作応答の体感速度

INPは、ページ滞在中のすべてのユーザー操作（クリック・タップ・キーボード入力）に対する応答時間を計測し、その中で最も遅い応答に近い値を代表値とします。2024年3月にFID（First Input Delay）の後継として正式採用されました。

合格基準：200ミリ秒以下がGood、500ミリ秒超はPoor。

INPが悪化する代表的な原因は以下のとおりです。

• JavaScriptの処理が重く、メインスレッドが長時間ブロックされている
• サードパーティスクリプト（タグマネージャー・チャットツールなど）が操作タイミングで実行される
• クリックイベントのハンドラーに不必要な同期処理が含まれている
• DOMの要素数が多すぎて、画面の再描画コストが高くなっている

3指標の合格基準と優先度の考え方

3指標の閾値を一覧で確認しておきます。

• LCP：Good 2.5秒以内 ／ Needs Improvement 2.5〜4.0秒 ／ Poor 4.0秒超
• CLS：Good 0.1以下 ／ Needs Improvement 0.1〜0.25 ／ Poor 0.25超
• INP：Good 200ms以下 ／ Needs Improvement 200〜500ms ／ Poor 500ms超

Googleのページエクスペリエンス評価では、3指標すべてがGoodであることが理想とされています。改善の優先順位を決める際は、まずPoorになっている指標から着手するのが合理的です。複数の指標が同時にPoorの場合は、ユーザーの離脱に直結しやすいLCPとINPを先に対処するケースが多くなります。

LCP改善の具体的な方法——描画速度を縮める7つのアプローチ

LCP（Largest Contentful Paint）のスコアを改善するには、「ヒーロー画像を圧縮する」だけでは不十分です。LCPの描画が遅れる原因は複数あり、それぞれに対応策が異なります。以下では、原因の特定から実装判断まで、7つのアプローチに整理して解説します。

① LCP要素の特定方法——DevToolsでヒーロー画像を確認する

まず「何がLCP要素になっているか」を確認することが出発点です。ChromeのDevToolsを開き、「Performance」タブで記録を開始してページを読み込むと、タイムライン上にLCPマーカーが表示されます。該当フレームを選択すると、LCPとして判定された要素（多くの場合はヒーロー画像や大きな見出しテキスト）がハイライトされます。

PageSpeed InsightsやSearch Consoleの「ウェブに関する主な指標」レポートでも同様の確認が可能ですが、DevToolsはローカル環境でのデバッグに向いており、変更後の即時検証に役立ちます。LCP要素を特定しないまま対策を進めると、効果の薄い箇所に工数をかける結果になるため、この手順を省略しないようにしてください。

② 画像最適化——WebP変換・サイズ指定・遅延読み込みの使い分け

LCP要素が画像の場合、ファイル形式・サイズ・読み込み方式の3点を見直します。

• WebP変換：JPEGやPNGと比較してファイルサイズを20〜30%削減できるケースが多く、主要ブラウザでの対応も完了しています。
• width・height属性の明示：HTMLに実寸を記述することでブラウザがレイアウトを事前計算でき、描画の遅れを防ぎます。
• loading=”lazy”の扱い：LCP要素にlazyを付与すると、ブラウザが意図的に読み込みを遅らせるためスコアが悪化します。ファーストビューの画像にはloading=”eager”（または属性なし）を使用してください。

WordPressではプラグイン（Imagify、ShortPixelなど）でWebP変換と圧縮を自動化できます。HTMLベース環境では<picture>タグでWebPとフォールバック形式を併記する方法が一般的です。

③ fetchpriorityとpreloadによるリソース優先度の制御

ブラウザはページ読み込み時にリソースの優先度を自動判定しますが、LCP画像が正しく高優先度として扱われないケースがあります。この場合、2つの方法で明示的に優先度を制御できます。

• fetchpriority=”high”：imgタグに付与することで、ブラウザにこの画像を優先して取得するよう指示します。LCP要素が確定している場合は積極的に使用を検討してください。
• preload：<link rel="preload" as="image">をheadに記述することで、HTMLの解析完了を待たずに画像の取得を開始できます。CSS背景画像としてLCP要素が設定されている場合に特に効果的です。

WordPressでは、使用しているテーマやページビルダーによってheadへの直接記述が制限されているケースもあります。その場合はwp_headフックを利用するか、対応プラグインを検討する必要があります。

④ レンダーブロッキングCSSとJavaScriptの排除

ブラウザはHTMLを解析する際、CSSとJavaScriptの処理が完了するまで描画を停止します。これがLCPの遅延につながります。対応策は以下の通りです。

• JavaScriptへのdefer・async付与：描画に不要なスクリプトはdefer属性を付与し、HTMLの解析をブロックさせないようにします。
• クリティカルCSSのインライン化：ファーストビューの描画に必要なCSSのみをheadにインラインで記述し、残りは非同期で読み込む構成にすることで、レンダーブロッキングを回避できます。

WordPressではWP RocketやFlyingPressなどのキャッシュ・最適化プラグインがこれらの処理を設定画面から制御できます。ただし設定を誤るとレイアウト崩れが発生するため、適用後の表示確認は必須です。

⑤ サーバー応答速度（TTFB）の改善とCDNの活用

TTFB（Time to First Byte）はブラウザがリクエストを送信してから最初の1バイトを受信するまでの時間です。TTFBが長いとLCPの起点が遅れるため、200ms以内を目安に改善を検討します。

主な対応策は2つです。まずサーバーサイドのキャッシュ設定を見直し、動的生成のコストを下げることが基本です。WordPressであれば前述のキャッシュプラグインが有効です。次にCDN（コンテンツデリバリーネットワーク）の導入を検討します。CDNは静的ファイルをユーザーに地理的に近いサーバーから配信するため、海外訪問者が多いサイトや画像・動画が多いサイトで効果が出やすい傾向があります。Cloudflareは無料プランでも基本的なCDN機能を利用できるため、導入コストを抑えたい場面での選択肢になります。

一方、国内ユーザーのみを対象とした小規模サイトでは、CDN導入による改善幅が限定的なケースもあります。PageSpeed Insightsの「サーバーの応答時間の短縮」診断結果を確認しながら、優先度を判断することをお勧めします。

測定ツールの選び方と使い方——ラボデータとフィールドデータの違いを踏まえて

ラボデータとフィールドデータ——数値が違う理由と正しい読み方

Core Web Vitalsの測定で最初に押さえておくべきなのは、ツールによって数値の性質が根本的に異なるという点です。測定データは大きく「ラボデータ」と「フィールドデータ」の2種類に分かれており、同じページを計測しても数値が乖離するケースは珍しくありません。

ラボデータは、事前に設定した端末スペック・ネットワーク速度・ブラウザ環境をシミュレーションして計測した値です。PageSpeed InsightsのLighthouseスコアやChrome DevToolsの結果がこれにあたります。再現性が高く、改善前後の比較に向いていますが、実際のユーザー環境とは条件が異なります。

フィールドデータは、実際にサイトを訪れたユーザーのブラウザが収集したデータをGoogleが集計したものです。CrUX（Chrome User Experience Report）と呼ばれるデータベースに蓄積され、PageSpeed InsightsやGoogle Search Consoleで確認できます。SEOの評価に直接使われるのはこのフィールドデータです。

ラボデータで高スコアが出ていても、フィールドデータの指標が「改善が必要」の状態であれば、SEO上の評価は改善されません。両者を混同しないことが、測定作業の前提として重要です。

PageSpeed Insights——スコアの見方と改善ヒントの活用法

PageSpeed Insights（PSI）は、URLを入力するだけでラボデータとフィールドデータの両方を一画面で確認できるツールです。確認の順序としては、まずページ上部に表示される「フィールドデータ」セクションでLCP・CLS・INPの実態を把握します。次に、ページ下部のLighthouseスコアや「診断」セクションで、具体的な改善ヒントを確認するという流れが効率的です。

スコア（0〜100点）はラボデータをもとにした参考値であり、100点が目標ではありません。フィールドデータで各指標が「良好」の閾値を満たしているかどうかが実質的な判断基準になります。

Google Search Console「ウェブに関する主な指標」レポートの使い方

Google Search Consoleの「ウェブに関する主な指標」レポートは、サイト全体のページをURLグループ単位でまとめて評価できます。問題のあるページグループを一覧で把握できるため、優先度の高い改善対象を絞り込むのに適しています。特定のURLを個別に診断するPSIと使い分けることで、サイト全体の状況と個別ページの詳細を両面から確認できます。

Chrome DevTools・Lighthouse——ローカル環境での詳細診断

Chrome DevToolsとLighthouseは、本番環境に変更を加える前の事前検証や、ステージング環境での診断に活用します。DevToolsの「Performance」パネルではレンダリングの詳細なタイムラインを確認でき、LCPの対象要素の特定やレイアウトシフトの発生箇所の特定に役立ちます。Lighthouseはブラウザの拡張機能またはDevTools内から実行でき、改善の方向性を示す「機会」と「診断」の項目が実装判断の参考になります。

目的別にまとめると、以下のように使い分けるのが実用的です。

• SEO評価の現状確認：PageSpeed Insightsのフィールドデータ、またはGoogle Search Consoleのレポート
• サイト全体の問題ページの洗い出し：Google Search Console
• 改善前後の効果検証・原因の特定：PageSpeed InsightsのLighthouseスコア、またはChrome DevTools
• ステージング環境での事前確認：Chrome DevTools・Lighthouse

CLS改善の具体的な方法——レイアウトシフトを引き起こす原因と対策

CLSの改善は、「何がレイアウトシフトを引き起こしているか」を原因別に特定することから始まります。PageSpeed InsightsやChrome DevToolsの「Layout Shift Regions」機能を使うと、シフトが発生している要素を視覚的に確認できます。原因が判明したら、以下の対策を優先度に従って実施していきます。

画像・動画への幅×高さ属性とaspect-ratio指定

画像や動画にwidth属性とheight属性を明示していない場合、ブラウザはリソースの読み込みが完了するまでその領域の高さを確保できません。結果として、画像が表示された瞬間に周囲のテキストや要素が押し下げられ、CLSスコアを大きく悪化させます。

対策は2段階です。まずHTMLにwidthとheightを明記します。次に、CSSでaspect-ratioを設定することで、レスポンシブ環境でも縦横比を維持したままスペースを事前確保できます。

• HTML側：<img src=”example.jpg” width=”800″ height=”450″ alt=””> のように両属性を記述する
• CSS側：img { aspect-ratio: 16 / 9; width: 100%; height: auto; } と指定し、表示領域を先に確保する

動画の埋め込み（iframeを使うYouTubeなど）にも同様の考え方が適用できます。ラッパー要素にaspect-ratio: 16 / 9を指定し、iframeを内側でposition: absoluteに配置する手法が広く使われています。

広告・埋め込みウィジェットのスペース確保

広告枠やSNS埋め込みウィジェットは、外部スクリプトの読み込み後に初めてサイズが確定するため、CLSの主要な発生源になりやすいです。対策の基本は、広告が表示される前から最低限の高さをCSSで予約しておくことです。

• 広告コンテナにmin-height: 250pxなどを設定し、空の状態でも領域を確保する
• Google広告など高さが可変の広告は、想定される最大サイズに合わせてスペースを確保する
• ウィジェット（Twitterの埋め込みなど）は、読み込み前にプレースホルダーとなるスケルトンUIを置く方法も有効です

Webフォントによるレイアウトシフトの防止——font-display設定

Webフォントが遅延読み込みされると、最初はシステムフォントで描画され、カスタムフォントへの切り替わりのタイミングでテキストサイズが変化し、レイアウトシフトが発生します。これを防ぐために有効なのが、font-displayプロパティの適切な設定です。

• font-display: swap：フォントが読み込まれるまでシステムフォントで表示し、準備ができ次第切り替えます。CLSが発生する可能性は残りますが、テキストの視認性は維持されます
• font-display: optional：ごく短時間だけフォントの読み込みを待ち、間に合わなければシステムフォントを使い続けます。CLSの発生を最小化したい場合に適しています

加えて、Google Fontsを使用している場合は<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>を追加してフォントファイルの取得を早めることも、シフト発生タイミングの短縮につながります。

動的コンテンツ挿入（バナー・通知）の扱い方

ページ読み込み後にJavaScriptでバナーやクッキー同意通知を挿入する実装は、既存のコンテンツを押し下げるためCLSを引き起こします。この種のシフトはユーザーの操作がトリガーになっていないため、CLSのスコアに直接加算されます。

• バナーや通知はページ上部ではなく画面下部（fixed配置）に表示することで、既存レイアウトへの影響を回避できます
• どうしても上部に表示する必要がある場合は、その分の高さをサーバーサイドレンダリングの段階からmin-heightで確保しておきます
• ユーザーのスクロールやクリックなど操作後に挿入されるコンテンツは、CLSの計算対象から除外されます。挿入タイミングを操作後に変更できる場合は、その設計変更も選択肢に入ります

LCP改善の具体的な方法——描画速度を縮める7つのアプローチ

LCP（Largest Contentful Paint）の改善は、ヒーロー画像の圧縮だけで完結しません。サーバー応答・リソース優先度・レンダーブロッキングなど、複数の要因が重なって描画速度を押し上げているケースがほとんどです。以下では、要因の特定から実装判断まで、7つのアプローチを順を追って整理します。

① LCP要素の特定方法——DevToolsでヒーロー画像を確認する

改善に着手する前に、まず「何がLCP要素になっているか」を確認します。Chrome DevToolsのPerformanceタブで録画を実行すると、タイムライン上に「LCP」マーカーが表示され、対象要素をピンポイントで特定できます。

PageSpeed InsightsやLighthouseでも「Largest Contentful Paint element」として対象要素が明示されます。ヒーロー画像の場合が多いですが、テキストブロックや背景画像がLCP要素になることもあるため、思い込みで対処せず必ず計測から始めてください。

② 画像最適化——WebP変換・サイズ指定・遅延読み込みの使い分け

LCP要素がヒーロー画像の場合、まず取り組むべきは画像自体の軽量化です。具体的には以下の3点を押さえてください。

• WebP変換：JPEGやPNGと比較して20〜30%程度のファイルサイズ削減が見込めます。WordPressであればSHORTPIXELやEWWW Image Optimizerで自動変換できます。
• width／height属性の明示：レイアウトシフト防止にも直結します。省略するとブラウザが描画前にサイズを計算できず、LCPが遅延します。
• loading=”lazy”の除外：LCP要素に遅延読み込みを設定するとブラウザが意図的に読み込みを後回しにします。ファーストビューに表示される画像にはloading=”lazy”を付与しないことが鉄則です。

③ fetchpriorityとpreloadによるリソース優先度の制御

画像を軽量化しても、ブラウザが優先して読み込まない限りLCPは改善しません。そこで有効なのがfetchpriority=”high”属性と<link rel=”preload”>の組み合わせです。

ヒーロー画像の<img>タグにfetchpriority="high"を追加すると、ブラウザはその画像を高優先度で取得します。さらに<head>内に<link rel="preload" as="image" href="hero.webp">を記述することで、HTMLのパース完了を待たずにリソース取得を開始できます。

WordPressではfunctions.phpにフックを追加するか、パフォーマンス系プラグイン（例：WP Rocket）のpreload設定から対応可能です。HTMLベース環境では<head>に直接記述します。

④ レンダーブロッキングCSSとJavaScriptの排除

ブラウザはHTMLのパース中にCSSやJavaScriptを検出すると、描画を一時停止します。これがレンダーブロッキングです。LCPが遅い場合、この処理待ち時間が原因になっているケースは少なくありません。

• CSS：ファーストビューに必要なスタイルをインライン化（クリティカルCSS）し、残りを非同期で読み込みます。WordPressではAutoptimizeプラグインが対応しています。
• JavaScript：deferまたはasync属性を追加し、HTMLパースをブロックさせない設定に変更します。ただし実行順序への依存がある場合はdeferが安全です。

⑤ サーバー応答速度（TTFB）の改善とCDNの活用

TTFB（Time to First Byte）が200msを超えている場合、サーバー側の問題がLCPの足を引っ張っています。改善の優先順位は以下の通りです。

1. サーバーキャッシュの有効化：WordPressではWP RocketやW3 Total Cacheでページキャッシュを設定します。
2. ホスティングプランの見直し：共有サーバーでリソース不足が常態化している場合、VPSや高速化に特化したマネージドホスティングへの移行を検討します。
3. CDN（Content Delivery Network）の導入：静的ファイルを地理的に近いサーバーから配信することで、物理的なレイテンシを短縮します。Cloudflareは無料プランでも基本的なCDN機能を利用できるため、まず試すには適しています。ただし動的コンテンツが多いサイトでは、CDNの恩恵が限定的になることもあります。

HTMLベース環境では設定の自由度が高い分、サーバー設定ファイル（.htaccessやnginx.conf）を直接編集してgzip圧縮やブラウザキャッシュを制御できます。WordPress環境ではプラグイン経由で同等の設定を行いますが、プラグイン同士の競合が起きやすいため、変更は1つずつ行って効果を確認する進め方が安全です。

INP改善の具体的な方法——操作への応答遅延を解消する

INP（Interaction to Next Paint）は2024年3月にFID（First Input Delay）の後継としてCore Web Vitalsの正式指標となりました。FIDがクリックなどの「最初の入力への応答開始までの時間」だけを測定していたのに対し、INPはページ滞在中のすべてのインタラクション（クリック・キータッチ・タップ）の応答時間を総合的に評価します。良好とされる閾値は200ミリ秒以内です。

競合記事ではFIDの延長線上として浅く扱われることが多い指標ですが、改善には独自のアプローチが必要です。以下では原因の構造から対策まで順に整理します。

INPが悪化する主な原因——メインスレッドのブロックとは

ブラウザはJavaScriptの実行・レイアウト計算・画面描画をすべて「メインスレッド」と呼ばれる1本の処理ラインで行っています。ユーザーがボタンをクリックした瞬間にメインスレッドが他の処理で占有されていると、クリックへの応答が後回しになります。この状態を「メインスレッドのブロック」と呼びます。

INPの応答時間は次の3フェーズの合計で構成されています。

• 入力遅延（Input Delay）：イベントがキューに入ってから処理が始まるまでの待ち時間
• 処理時間（Processing Time）：イベントハンドラー内のJavaScript実行時間
• 表示遅延（Presentation Delay）：JavaScriptの実行完了から実際に画面が更新されるまでの時間

このうち入力遅延と表示遅延は、メインスレッドに長時間占有されるタスク（50ミリ秒超の「Long Task」）が直接の原因になります。

長いJavaScriptタスクの分割とscheduler.yield()の活用

Chrome DevToolsのPerformanceパネルを開くと、50ミリ秒を超えるタスクが赤くハイライト表示されます。これがLong Taskです。まずはここを起点に改善対象を特定してください。

Long Taskへの対処として有効なのが、タスクの分割です。一度に実行していた処理を小さな単位に分け、ブラウザがインタラクションに応答できるタイミングを意図的に作ります。従来はsetTimeout(fn, 0)による擬似的な分割が使われていましたが、現在はより精度の高い方法としてscheduler.yield()が利用できます。

scheduler.yield()を使うと、処理の途中でメインスレッドを一時的にブラウザに返し、ユーザー操作への応答を優先させることができます。2024年時点でChrome 115以降に対応しており、ポリフィルと組み合わせれば他ブラウザでも段階的に導入できます。大量のDOM操作やデータ処理ループを含む機能がある場合は、この手法の適用を検討する価値があります。

サードパーティスクリプト（タグマネージャー・チャット等）の影響と対策

INPが悪化しているサイトの多くで、サードパーティスクリプトが原因の一因となっています。Google Tag Manager経由で配信されるトラッキングタグ、チャットウィジェット、A/Bテストツールなどは、自社のコードとは独立してメインスレッドを消費します。

対策として効果的な方法は以下のとおりです。

• 遅延読み込みの適用：ページの初期表示・最初のインタラクションに不要なスクリプトは、defer属性や動的インポートを使って読み込みを後回しにする
• Web Workerへのオフロード：処理をメインスレッドから切り離せるスクリプトはWeb Workerで実行する（Partytown等のライブラリが有効）
• タグの棚卸し：GTMコンテナ内に蓄積した未使用タグを定期的に削除し、不要なスクリプトの実行そのものを減らす

サードパーティスクリプトの影響はChrome DevToolsの「Third-party summary」セクションで確認できます。どのドメインのスクリプトがどれだけメインスレッドをブロックしているかを数値で把握したうえで優先順位をつけると、改善効率が上がります。

Reactなどフレームワーク利用時の注意点

ReactやVue、Next.jsといったフレームワークを使ったSPAやSSRサイトでは、フレームワーク固有の処理がINPに影響するケースがあります。

Reactの場合、ユーザー操作をきっかけに発生する状態更新（setState）が大規模なコンポーネントツリーの再レンダリングを引き起こし、処理時間フェーズが長くなることがあります。React 18で導入されたuseTransitionフックを使うと、緊急度の低い状態更新を「遷移」として分類し、ユーザー操作への応答を優先させることができます。

また、Next.jsではサーバーコンポーネントとクライアントコンポーネントの分割設計が適切でないと、クライアント側のJavaScriptバンドルが肥大化し、Long Taskの温床になります。クライアントコンポーネントの範囲を必要最小限に絞ることが、INP改善の前提条件になります。

フレームワークを使っているサイトでINPが基準値を超えている場合は、Lighthouseの「Avoid long main-thread tasks」の指摘箇所と合わせて、レンダリングの境界設計を見直すことが出発点になります。

CLS改善の具体的な方法——レイアウトシフトを引き起こす原因と対策

CLSの悪化は、広告・Webフォント・動的に挿入されるUI要素など、複数の原因が重なって起きます。それぞれの原因に対して適切な対策を講じることで、スコアを「良好」の閾値である0.1以下に抑えることができます。

画像・動画への幅×高さ属性とaspect-ratio指定

画像や動画に width・height属性 を明示していない場合、ブラウザはリソースの読み込み完了後に初めてサイズを確定します。その結果、周囲のテキストや要素が押し下げられ、CLSが発生します。

対策としては、HTMLの img要素にwidth・height属性を明記 するのが基本です。加えて、CSSで以下のように aspect-ratio を指定しておくと、読み込み前からブラウザがレイアウト上のスペースを確保できます。

• HTMLに width=”800″ height=”450″ などの実寸を記述する
• CSSで aspect-ratio: 16 / 9; を指定し、レスポンシブ環境でも比率を維持する
• 遅延読み込み（loading=”lazy”）を使う場合も、サイズ指定は省略しない

広告・埋め込みウィジェットのスペース確保

Google AdSenseなどの広告ユニットや、SNSの埋め込みウィジェットは、読み込みタイミングが遅れるため、後から表示領域が確保されてレイアウトシフトを引き起こしやすい要素です。

対策は、広告表示エリアを事前に固定サイズでCSSによりmin-height指定しておく ことです。たとえば、バナー広告枠であれば min-height: 90px のような値をラッパー要素に当て、広告が読み込まれる前からスペースを確保します。広告の配信がなかった場合にコンテンツが跳び上がらないよう、空スペースを維持する設計が求められます。

Webフォントによるレイアウトシフトの防止——font-display設定

Webフォントは読み込みに時間がかかるため、フォールバックフォントで描画した後に本フォントへ切り替わる際に、テキストのサイズや字間が変化してシフトが発生します。この現象はFOUT（Flash of Unstyled Text）と呼ばれます。

CSSの font-display プロパティを適切に設定することで、この挙動をコントロールできます。

• font-display: swap;　フォールバックフォントで即座に描画し、Webフォントの準備ができ次第切り替える。テキストが早く表示される一方でシフトは残りやすい
• font-display: optional;　一定時間内にフォントが読み込まれなければWebフォントを使用しない。シフトを最小化したい場合に有効

加えて、Google Fontsを使用している場合は &display=swap をURLパラメータに付与するか、フォントファイルを自己ホスティングして読み込み速度を改善することも有効です。

動的コンテンツ挿入（バナー・通知）の扱い方

ページ上部に後から挿入されるCookieバナーや、JavaScriptで動的に追加されるお知らせバーは、CLSの大きな要因になりやすいです。ページ読み込み後に突然コンテンツを押し下げる構造が問題です。

対策としては、以下のアプローチが有効です。

• バナーを ページ上部への挿入ではなく、オーバーレイ（position: fixed）で表示 し、既存コンテンツのレイアウトに影響を与えない設計にする
• バナーのスペースをHTMLに最初から確保しておき、表示・非表示をCSSで制御する
• ユーザー操作（スクロールやクリック）をトリガーに挿入する場合は、CLSの計算対象外となるため影響を抑えられます

動的挿入のタイミングと配置場所を設計段階から意識することが、CLS改善における実装上のポイントになります。

WordPress環境での改善——プラグインと設定変更で対処できる範囲を整理する

WordPressはCMSのシェアが非常に高く、実際にCore Web Vitalsの改善を検討している担当者の多くがWordPress環境で作業しています。コード改修なしでプラグインと設定変更だけ対応できる範囲は意外に広く、まずその範囲を把握してから開発者への依頼範囲を判断するのが効率的です。

画像最適化・遅延読み込み——推奨プラグインと設定の考え方

LCPの主な原因は、ファーストビューに配置された大きな画像の読み込み遅延です。WordPressではImagifyやShortPixelなどの画像最適化プラグインを導入することで、WebP変換・圧縮・リサイズを自動化できます。

設定時に注意すべき点が2つあります。1つ目は、LCPの対象となるファーストビューの画像には遅延読み込み（lazy load）を適用しないことです。WordPressはバージョン5.5以降、デフォルトで全画像にloading=”lazy”を付与しますが、LCP画像に適用するとむしろスコアが悪化します。プラグイン側やfunctions.phpの設定で先頭画像を除外してください。2つ目は、圧縮品質の設定です。過度な圧縮はビジュアル品質を損ない、特にBtoB向けサービスサイトでは信頼感に影響するため、品質70〜85%程度を目安にしてください。

キャッシュ・ミニファイ——サーバー応答とリソースサイズの削減

サーバー応答速度（TTFB）の改善には、WP RocketやW3 Total Cacheといったキャッシュプラグインが有効です。これらはページキャッシュの生成に加え、CSS・JavaScript・HTMLのミニファイ（不要な空白やコメントの除去）、Gzip圧縮の有効化も設定画面から対応できます。

WP Rocketを例にとると、「ファイルの最適化」タブからCSS・JSのミニファイと結合を有効にするだけで、リソースのリクエスト数とファイルサイズの両方を削減できます。ただし、JavaScriptの結合はサイト固有のスクリプト依存関係によっては表示崩れを起こす場合があるため、有効にしたあとは必ずステージング環境で動作確認を行ってください。

テーマ・プラグインに起因するスコア悪化の診断方法

Core Web Vitalsのスコアが改善しない場合、テーマや不要なプラグインがレンダーブロッキングリソースを生成しているケースが少なくありません。診断の手順は次のとおりです。

• Google Chrome DevToolsの「Performance」タブで、ページロード時のスクリプト実行タイムラインを確認する
• PageSpeed Insightsの「レンダーブロッキングリソースの除外」セクションで、問題のあるファイルパスを特定する
• 該当ファイルがどのプラグイン・テーマに属するかをパスから判別し、プラグインを一時的に無効化してスコア変化を確認する

特にページビルダー系のテーマ（Divi、Elementorなど）は多くのCSSとJavaScriptを読み込むため、使用していないモジュールやウィジェットの読み込みを無効化できる設定がないか確認することをお勧めします。CLANEではWordPressの管理とSEO検証を統合したWeb制作ワークスペースを用いており、こうした診断と改善の作業を一元的に管理できる体制をとっています。

プラグイン対応の限界——コード改修が必要になるケース

プラグインと設定変更で対処できる範囲には明確な上限があります。以下のケースでは、カスタム開発や既存コードへの直接介入が必要になります。

• CLS（レイアウトシフト）の根本対処：フォントの読み込みによるテキストのズレや、width・heightが未指定の画像によるシフトは、テーマのテンプレートファイルやCSSの修正が必要です
• INP（操作応答遅延）の改善：重いJavaScriptの処理はプラグインで解決できず、コードのリファクタリングやWeb Workerへの処理移譲など開発対応が求められます
• サードパーティスクリプトの遅延化：広告タグや解析ツールのスクリプトは、ファサードパターンの実装など、テーマのカスタマイズを伴う対応が必要になるケースが多いです

改善の優先順位は「プラグインで対応できる項目を先行して実施し、スコアへの影響を確認したうえで開発コストをかける範囲を判断する」という順序が合理的です。スコアへの寄与が大きい課題から着手することで、開発リソースの投入判断を根拠を持って行えます。

INP改善の具体的な方法——操作への応答遅延を解消する

INP（Interaction to Next Paint）は2024年3月にFID（First Input Delay）と置き換わった指標です。FIDが「最初の操作への応答開始までの遅延」だけを測っていたのに対し、INPはページ滞在中のすべての操作（クリック・タップ・キー入力）における応答遅延を総合的に評価します。良好の閾値は200ms以内とされており、これを超えると「操作したのに画面が反応しない」という体験をユーザーに与えます。

INPが悪化する主な原因——メインスレッドのブロックとは

ブラウザはJavaScriptの実行・レイアウト計算・描画をすべて単一の「メインスレッド」で処理します。ユーザーがボタンをクリックした瞬間にメインスレッドが別の処理で占有されていると、クリックへの応答は処理が空くまで待たされます。この状態が「メインスレッドのブロック」です。

INPの悪化はおもに次の3つの構造から生じます。

• 長いJavaScriptタスク（Long Tasks）：50ms以上かかる処理が連続すると、その間は操作を受け付けられません。
• 過剰なサードパーティスクリプト：タグマネージャー・チャットウィジェット・広告スクリプトなどがメインスレッドを断続的に占有します。
• レンダリングコストの高いDOM操作：ボタンクリック後に大量の要素を一括更新すると、描画完了までの時間が伸びます。

長いJavaScriptタスクの分割とscheduler.yield()の活用

Long Tasksを解消する基本的な手法は、処理を小さな単位に分割してブラウザに「制御を返す」タイミングを作ることです。従来はsetTimeout(fn, 0)による擬似的な分割が使われていましたが、現在はscheduler.yield()が有力な選択肢になっています。

scheduler.yield()はasync/awaitと組み合わせて使います。重い処理ループの途中でawait scheduler.yield()を挟むと、ブラウザはその時点でユーザー操作を受け付け、処理が終わり次第残りのタスクを再開します。Chrome 115以降で利用可能で、対応していないブラウザ向けにはMessageChannelを使ったポリフィルで代替できます。

Chrome DevToolsの「Performance」パネルでは、50ms超のタスクが赤くハイライトされます。INP改善に取り組む際はまずここで対象タスクを特定し、優先順位をつけて分割対応することが実際的です。

サードパーティスクリプト（タグマネージャー・チャット等）の影響と対策

サードパーティスクリプトはINP悪化の見落とされやすい原因です。Google タグマネージャー経由で複数のピクセルやトラッキングコードを読み込んでいるサイトでは、スクロールやクリックのたびにイベント計測処理がメインスレッドを占有するケースが少なくありません。

対策として有効なのは次の2点です。

• 遅延読み込みの導入：チャットウィジェットや広告スクリプトはページ読み込み直後ではなく、ユーザーが最初にスクロールまたは操作した後に読み込む設定にします。
• タグの棚卸しと削除：タグマネージャー内に残っている未使用タグは定期的に削除します。タグの数が増えるほどINPへの累積的な影響が大きくなります。

Chrome DevToolsの「Performance」パネルでボトムアップ表示を確認すると、どのスクリプトがメインスレッドを何ms占有しているかをドメイン単位で把握できます。

Reactなどフレームワーク利用時の注意点

ReactをはじめとするSPAフレームワークは、状態変化のたびに仮想DOMの差分計算と再レンダリングが走ります。コンポーネントの設計によっては、ボタン1回のクリックで想定外に広い範囲が再レンダリングされ、INPが悪化することがあります。

React環境での対応策として押さえておきたいのは以下の点です。

• useMemo・useCallbackによるメモ化：不要な再計算・再レンダリングを抑制します。
• React 18のuseTransition：優先度の低い状態更新を「並行モード」で処理し、ユーザー操作への応答を優先させます。
• コンポーネントの分割：影響範囲を小さくすることで、1回の操作でトリガーされる再レンダリングのコストを下げます。

フレームワークの利便性と引き換えにINPが犠牲になるケースは珍しくありません。実装前の段階でChrome DevToolsのReact Profilerを使い、ボトルネックとなるコンポーネントを特定しておくことが重要です。

改善作業を継続的に回す——測定→改善→確認のサイクルを定着させる

Core Web Vitals対策は、一度の改修で終わりにできるものではありません。デプロイのたびにスコアが変動するリスクがあり、改善後の確認と継続的なモニタリングがなければ、気づかないうちに数値が悪化するケースも少なくありません。

改善後の確認手順——Search ConsoleとPageSpeed Insightsの読み直し方

Core Web Vitals改善の方法を実施した後、まずGoogle Search Consoleの「ウェブに関する主な指標」レポートを開き、「良好なURL数」の推移を確認します。ただし、Search Consoleが表示するフィールドデータ（実際のユーザー計測値）は28日間の集計のため、改修直後には変化が反映されません。デプロイ後2〜4週間を目安に数値の推移を追うことが現実的な運用です。

即時性が必要な確認にはPageSpeed InsightsまたはLighthouseを使います。ラボデータとして改修前後のスコアを比較することで、変更の効果を素早く検証できます。改善対象のページURLを固定してブックマークしておくと、確認作業のコストを下げられます。

リグレッション防止——デプロイ前後でスコアを比較するフロー

改善後に別の修正が原因でスコアが下がる「リグレッション（後退）」は頻繁に起こります。これを防ぐには、デプロイ前後でLighthouseスコアを計測・記録する習慣が有効です。

1. ステージング環境でLighthouseを実行し、LCP・CLS・INPのスコアをスプレッドシートに記録する
2. 本番デプロイ後に同一ページで再計測し、デプロイ前後の差分を確認する
3. スコアが閾値（LCP2.5秒・CLS0.1・INP200ms）を超えた場合は原因の特定を優先する

CLANEの統合ワークスペースは自動検証とSEO分析機能を備えており、このスコア比較のサイクルを一元管理できる構成になっています。

改善優先順位の判断基準——影響ページ数とビジネス重要度で絞る

Core Web Vitals測定ツールで複数の問題が検出された場合、すべてを同時に対処しようとすると工数が分散します。優先順位をつける際は、次の2軸で判断するとスムーズです。

• 影響ページ数：テンプレートやサイト全体に共通するコンポーネントの問題は、1件の修正で多数のページが改善されるため優先度が高い
• ビジネス重要度：コンバージョンに直結するランディングページや主要カテゴリページは、スコアのわずかな改善が成果に結びつきやすい

この2軸で課題を整理し、「影響が広くビジネス上も重要なページ」から着手することで、限られたリソースでCore Web Vitals対策の効果を最大化できます。

WordPress環境での改善——プラグインと設定変更で対処できる範囲を整理する

WordPressはCMS市場の過半数を占めており、実際にCore Web Vitalsの改善を検討する現場のほとんどがWordPress環境です。ただし、プラグインで解決できる範囲とコード改修が必要な範囲が混在しているため、まず両者を整理してから施策の優先順位を決めることが重要です。

画像最適化・遅延読み込み——推奨プラグインと設定の考え方

LCPに直接影響する画像の最適化は、プラグインだけでも相当程度対応できます。EWWW Image OptimizerやImagifyは既存画像をWebP形式に変換し、ファイルサイズを大幅に削減します。新規アップロード時の自動変換設定をオンにすることで、運用後の作業負担も抑えられます。

遅延読み込み（Lazy Load）はWordPress 5.5以降でコア機能として実装されていますが、ファーストビューの画像にまで適用されてしまうとLCPが悪化します。ヒーロー画像にはloading="eager"を指定するか、プラグイン側で除外設定を行う必要があります。この設定漏れはスコア悪化の原因として頻出します。

キャッシュ・ミニファイ——サーバー応答とリソースサイズの削減

サーバー応答速度（TTFB）の改善にはWP RocketやW3 Total Cacheが有効です。ページキャッシュを有効化するだけでTTFBが半分以下になるケースも珍しくありません。あわせてCSS・JavaScriptのミニファイと結合を設定することで、リソースサイズとリクエスト数を同時に削減できます。

ただし、ミニファイによってスクリプトが競合し、フォームやスライダーが動作しなくなる事例があります。設定変更後はステージング環境で動作確認を行い、問題が生じたファイルは除外設定に追加する運用が安全です。

テーマ・プラグインに起因するスコア悪化の診断方法

Core Web Vitalsのスコアが突然低下した場合、テーマやプラグインのアップデートが原因であることが少なくありません。診断にはChrome DevToolsのPerformanceパネルまたはPageSpeed Insightsの「診断」セクションを使います。「レンダーブロッキングリソースの排除」に表示されるURLを確認し、どのプラグインが出力しているCSSやJSかを特定します。

プラグインの影響範囲を切り分けるには、管理画面から一時的に無効化して計測を繰り返す方法が確実です。CLANEではWordPress管理とSEO検証を統合したWeb制作ワークスペースを用いることで、こうした診断と改善確認の作業を一元的に進める体制を整えています。

プラグイン対応の限界——コード改修が必要になるケース

以下のケースはプラグインだけでは解決が難しく、テーマやカスタムコードへの介入が必要です。

• LCPリソースのプリロード設定：ヒーロー画像をCSSのbackground-imageで指定しているテーマでは、<link rel="preload">をheadに追加するためにテンプレートファイルの編集が必要になります。
• INPの改善：JavaScriptのイベントハンドラーが長時間メインスレッドを占有している場合、コード分割や処理の非同期化はプラグインでは対応できません。
• CLSの根本解決：広告枠やiframeのサイズ未指定に起因するレイアウトシフトは、テンプレート内のHTML属性を直接修正する必要があります。

プラグインによる改善は導入コストが低く即効性もありますが、スコアが一定以上改善しない場合はコードレベルの診断に移行することを検討してください。

まとめ——指標別の対策と測定サイクルを組み合わせて継続改善する

本記事で解説してきたCore Web Vitals改善の要点を、指標別に整理します。どの指標から着手すべきかを判断する際の参考にしてください。

• LCP（最大コンテンツの描画速度）：画像の遅延読み込み解除・次世代フォーマット化・CDN導入・サーバー応答速度の改善が優先度の高い対策です。ヒーロー画像やファーストビューの大きな要素に絞って着手すると効果が出やすくなります。
• CLS（レイアウトシフト）：画像・動画・広告枠へのサイズ指定、Webフォントの最適化、動的コンテンツの挿入位置の見直しが主な対処法です。スコアが悪化しているページを優先して確認してください。
• INP（操作への応答速度）：JavaScriptの実行コストとメインスレッドの占有時間を削減することが根本対策です。タスクの分割やサードパーティスクリプトの整理から始めると取り組みやすくなります。

着手する指標の選び方としては、Search ConsoleのCore Web Vitalsレポートで「不良URL」が多い指標を最初に優先するのが現実的です。フィールドデータ（実ユーザーの計測値）が基準に達していない指標ほど、SEO評価への影響が直接的であるためです。

改善を継続させるうえで欠かせないのが、測定→改善→確認のサイクルを定着させることです。施策を実施しても計測を怠ると、効果の有無が判断できないまま次の施策に移ってしまいます。測定なき改善は方向性を見誤ります。ツールと測定タイミングを事前に決め、定期的にスコアを記録する仕組みを整えることが、Core Web Vitals対策を形骸化させない最大のポイントです。

改善作業を継続的に回す——測定→改善→確認のサイクルを定着させる

Core Web Vitals対策は、一度改善すれば終わりではありません。JavaScriptライブラリのアップデート、新しい広告タグの追加、CMSプラグインの変更など、日常的なデプロイが原因でスコアが悪化するリグレッションは頻繁に起こります。改善後の確認手順を標準化し、サイクルとして定着させることが継続的な成果につながります。

改善後の確認手順——Search ConsoleとPageSpeed Insightsの読み直し方

Search Consoleの「ウェブに関する主な指標」レポートでは、URLごとの合格・改善が必要・不良のステータスを確認できます。改善施策をデプロイした後、Googleが再クロールしてデータを更新するまでには通常28日程度かかります。そのため、施策の効果を判断するタイミングとして、デプロイから4週間後のレポートを基準にするのが現実的です。

確認のポイントは2つです。

• 合格URLの増加数：不良・改善が必要から合格に移行したURL数を前月比で追う
• 影響ページ数の変化：同じ指標で不良扱いになっているURL群がまとめて改善されているか確認する

PageSpeed InsightsはフィールドデータとラボデータをURLごとに即時取得できるCore Web Vitals測定ツールです。デプロイ直後の定点観測に活用し、ラボデータ（Lighthouseスコア）でまず動作確認する流れが合理的です。

リグレッション防止——デプロイ前後でスコアを比較するフロー

デプロイのたびにスコアが劣化するリスクを抑えるには、CI/CDパイプラインにLighthouseの自動計測を組み込む方法が有効です。具体的には、ステージング環境でのビルド後にLighthouse CIを実行し、本番デプロイ前にLCP・CLS・INPの閾値を下回っていないかをチェックします。閾値を設定しておけば、スコアが一定水準を下回った際にデプロイを止めることも可能です。

CLANEの統合ワークスペースは自動検証機能とSEO分析機能を備えており、こうした計測・確認のサイクルを一元管理できる構成になっています。ツールを横断する手間を減らし、改善→検証→モニタリングの流れを継続しやすくする点で、運用コストの削減に寄与します。

改善優先順位の判断基準——影響ページ数とビジネス重要度で絞る

改善対象が多い場合、すべてを同時に着手するのは現実的ではありません。優先順位をつける際は、次の2軸で整理すると判断しやすくなります。

• 影響ページ数：同じテンプレートを使う一覧ページや商品ページは、1箇所の修正で複数URLをまとめて改善できるため優先度が高い
• ビジネス重要度：コンバージョン導線に直結するランディングページや、流入数の多いキーページを先行させる

この2軸の掛け合わせで「影響ページ数が多く、かつ重要度が高いページ」から順に着手することで、限られたリソースでCore Web Vitals改善の効果を最大化できます。

まとめ——指標別の対策と測定サイクルを組み合わせて継続改善する

本記事で解説してきたCore Web Vitals改善の要点を、指標別に整理します。どの指標から着手すべきか迷っている場合は、まずGoogle Search ConsoleのCore Web Vitalsレポートを開き、「不良」判定が出ている指標を優先してください。

• LCP（最大コンテンツの描画）：ヒーロー画像の最適化・preloadの設定・サーバー応答速度の改善が最初の着手点です。2.5秒以内を目標に、画像フォーマットのWebP化とCDN導入を優先します。
• CLS（累積レイアウトシフト）：画像・広告・埋め込みコンテンツへのサイズ属性明示が基本対策です。0.1以下を達成するには、フォントの遅延読み込みによるズレの解消も合わせて確認します。
• INP（次のペイントへの応答）：JavaScriptの実行コスト削減とメインスレッドの分散が核心です。200ミリ秒以内を目標に、不要なサードパーティスクリプトの見直しから始めます。

改善を進める際に見落としやすいのが、測定サイクルの設計です。一度改善を施したあとも、コンテンツ追加・プラグイン更新・広告タグの変更などによってスコアは容易に悪化します。月次でPageSpeed InsightsとSearch Consoleを確認し、変化の兆候を早期に捉える習慣が欠かせません。

測定なき改善は方向性を見誤ります。体感やツールのラボデータだけを根拠にするのではなく、実際のユーザー環境を反映したフィールドデータ（CrUX）を判断軸に置いたうえで、指標ごとの対策を積み重ねることが、Core Web Vitals改善を継続的な成果につなげる唯一の道筋です。