既存サービスのCore Web Vitalsを改善する手順

「Search ConsoleのCore Web Vitalsレポートが赤(不良)のまま半年放置されている」「広告LPの品質スコアが低くてCPCが上がっている」「PageSpeed Insightsのスコアが悪いと指摘されたが、何から手をつければいいか分からない」——事業責任者やPdMからよくいただく相談です。多くの場合、原因は1つではなく、計測方法を誤解したまま対症療法を繰り返して改善が進んでいません。この記事では、Core Web Vitalsの3指標を噛み砕いた上で、正しい計測方法、原因別の改善策、優先順位のつけ方、SEOへの実際の影響までを整理します。

Core Web Vitalsとは何を測っているか

Core Web Vitalsは「ページがどれだけ速く・安定して・反応よく使えるか」をGoogleが定義した3つの指標です。それぞれが測っているものはまったく違うので、混同すると改善の方向を間違えます。

• LCP(Largest Contentful Paint): ページ内で最も大きい要素(メインビジュアル画像・見出しテキストなど)が表示されるまでの時間。「ページが表示され切った」とユーザーが感じるタイミングに近い指標です。良好の基準は2.5秒以内。
• CLS(Cumulative Layout Shift): ページ読み込み中にレイアウトがどれだけガタつくかのスコア。「読もうとしたらボタンの位置がずれて誤タップした」という体験の原因です。良好の基準は0.1未満(単位のないスコア)。
• INP(Interaction to Next Paint): クリック・タップなどの操作から、画面が反応するまでの時間。2024年3月にFID(First Input Delay)から置き換わった指標で、操作全体の反応の鈍さを測ります。良好の基準は200ミリ秒以内。

3つとも「良好」「改善が必要」「不良」の3段階で評価され、Search Consoleの「ウェブに関する主な指標」レポートで確認できます。よくある誤解は「LCPだけ直せば全部よくなる」というものですが、LCPが速くてもCLSが悪い(広告やレイアウトのガタつきが原因)ケースは珍しくなく、指標ごとに原因も対策もまったく別物として扱う必要があります。

計測: フィールドデータとラボデータを区別する

Core Web Vitalsの改善で最初につまずくのが、計測方法の混同です。ここを誤ると「PageSpeed Insightsのスコアを上げたのにSearch Consoleの評価が変わらない」という事態になります。

• フィールドデータ(実測データ): Chrome User Experience Report(CrUX)が、実際のユーザーのChromeブラウザから匿名で収集した実測値。Googleが検索評価に使うのはこちらです。Search Consoleの「ウェブに関する主な指標」レポート、またはCrUX Dashboardで確認します。過去28日間の実測値の75パーセンタイルで評価されるため、直近の改善が反映されるまで数週間のタイムラグがあります。
• ラボデータ(模擬計測): Lighthouse・PageSpeed Insightsが、特定のネットワーク・デバイス条件をシミュレートして1回だけ計測する値。検索評価には使われませんが、原因の内訳(何が遅いか)を診断するのに向いています。
• 両者がズレる理由: ラボは決まった条件での単発計測、フィールドは実際のユーザー(回線が遅い・低スペック端末・混雑時間帯を含む)の集積です。オフィスのWi-Fiで開発者が見て「速い」と感じても、実際のユーザーの多くがモバイル回線・型落ち端末からアクセスしていれば、フィールドデータは悪化したままということが普通に起こります。

実務では「PageSpeed Insightsで原因を診断し、Search Consoleのフィールドデータで改善が効いたか判定する」という役割分担で運用します。どちらか一方だけを見て一喜一憂しないことが重要です。

LCPの改善: 画像とサーバー応答を疑う

LCPが遅い場合、原因は大きく2つに分かれます。

• サーバー応答が遅い(TTFB): HTMLが返ってくるまでに時間がかかっていると、その後のすべてが遅れます。DBクエリが重い、サーバーのリソース不足、CDNを経由していない、といった原因が典型です。特に動的にレンダリングするページ(検索結果・パーソナライズされたトップページ)で起きやすく、遅いAPIレスポンスを改善する調査と実装手順で扱う原因調査がそのまま当てはまります。
• 最大要素(多くは画像)の読み込みが遅い: 圧縮していない巨大な画像、次世代フォーマット(WebP/AVIF)未使用、画像の遅延読み込み(lazy loading)をLCP要素にまで適用してしまっている、フォントの読み込みが表示をブロックしている、といったケースです。特に「lazy loadingを全画像に一律適用」は逆効果になりがちな地雷で、ファーストビューの画像にはloading="eager"またはfetchpriority="high"を指定し、優先的に読み込ませる必要があります。

改善の優先順位は「まずTTFBを1秒以内に収める→次に最大要素の読み込みを最適化する」の順です。TTFBが遅いままいくら画像を圧縮しても、土台が遅いので効果は限定的です。

CLSの改善: サイズ未指定の要素を洗い出す

CLSは原因がほぼパターン化されているため、対応は比較的機械的です。

• 画像・動画にwidth/heightが指定されていない: ブラウザが表示前にサイズを確保できず、読み込み完了時にレイアウトが押し出されます。CSSでアスペクト比を指定するか、width/height属性を明示するだけで解消することが大半です。
• 広告枠のサイズが動的: 広告が読み込まれた瞬間に周囲のコンテンツが押し出される、最も苦情の多いパターンです。広告枠に固定の高さ(min-height)を事前に確保しておく必要があります。
• Webフォントの読み込みによるテキストの再レイアウト(FOIT/FOUT): フォールバックフォントで表示された後にWebフォントに置き換わり、文字幅が変わってガタつくケースです。font-display: optionalの指定や、フォールバックフォントのメトリクス調整で緩和できます。
• JS実行で動的にDOMを挿入している: 「Cookie同意バナー」「訴求バー」などをJSで後から挿入すると、挿入時にレイアウトがずれます。挿入前にスペースを予約しておくか、初期HTMLに含めてCSSで表示制御する方が安全です。

CLSはLighthouseのレポートで「Layout Shift」の発生要素が具体的に列挙されるため、原因の特定自体は難しくありません。時間がかかるのは原因ではなく、要素数が多いサイトで1つずつ潰していく作業量の方です。

INPの改善: JS処理の重さを削る

INPは2024年に指標として新しく、既存プロダクトでは未対応のまま放置されているケースが多い指標です。

• メインスレッドをブロックする長いJS処理: クリックイベントのハンドラ内で重い計算・大量のDOM操作を同期的に行っていると、ブラウザが次の描画に進めず反応が遅れます。処理をrequestIdleCallbackやsetTimeoutで分割する、Web Workerに逃がすといった対応が基本です。
• サードパーティスクリプトの多さ: 広告タグ・アクセス解析・チャットウィジェットなど、複数のサードパーティJSが同時に走ると、それぞれがメインスレッドを奪い合いINPを悪化させます。本当に必要なものだけに絞り込む、遅延読み込みにする、といった棚卸しが効果的です。
• 巨大なJSバンドル: 1つのバンドルに全ページ分のコードが含まれていると、パース・実行のコストが常にかかります。ルートごとのコード分割(code splitting)で、そのページに必要な分だけ読み込ませることで改善します。フロントエンドの技術選定・実装はフロントエンド開発で扱う領域です。

INPの改善はLCP・CLSと比べてコードの構造に踏み込む必要があり、外注する場合も難易度・工数ともに高くなりやすい指標です。

優先順位のつけ方

3指標すべてを同時に改善しようとすると工数が発散します。実務では次の順で判断します。

1. Search Consoleで「不良」評価のURLグループを確認する。全ページ一律ではなく、URLパターン(商品詳細ページ・検索結果ページなど)ごとに評価が分かれているのが通常です。トラフィックが多いページ群から着手します。
2. 3指標のうち最も評価が悪いものから着手する。LCPが不良でCLS・INPが良好なら、LCPだけに集中する方が費用対効果が高いです。
3. 改修コストが低い項目を先に潰す。CLSの画像サイズ指定漏れのような機械的な修正は数日で効果が出ますが、INPのJS分割は設計から見直しが必要で数週間かかることもあります。着手順は「効果の大きさ」だけでなく「かかる工数」もセットで判断します。

具体的にどのページ・どの指標から着手すべきかの初動診断は、表示が遅いNext.jsページの速度調査でも実例を扱っています。

SEOへの実際の影響(過大評価しない)

Core Web Vitalsは検索順位を決める数百のシグナルの1つであり、コンテンツの関連性・質を上回る効果はありません。「Core Web Vitalsを改善すれば順位が劇的に上がる」という期待は過大評価です。実際に効果が出やすいのは以下のケースです。

• モバイル検索での順位競争が僅差の場合: 内容がほぼ同等の競合と競っているとき、Core Web Vitalsの差がタイブレーカーとして効いてきます。
• 広告(Google広告)の品質スコア: LP側のCore Web Vitalsは品質スコアの構成要素であり、改善するとCPCの低下に直結しやすいです。SEOよりも広告費への影響の方が即効性があります。
• 直帰率・コンバージョン率への影響: 表示が遅い・ガタつくことによるユーザー体験の悪化は、順位以前に離脱・機会損失として直接効いてきます。SEO目的というより、CVR改善の一環として取り組む方が投資対効果を説明しやすいです。

「SEOのため」だけを目的にすると費用対効果の説明が難しくなるので、広告費・CVRへの効果も含めて投資判断をするのが現実的です。

外注時の進め方

Core Web Vitalsの改善を外部に依頼する場合、次の流れで進めるとスコープが明確になります。

1. 現状のフィールドデータ(Search Console)を初回に共有する。改善前のベースラインがないと、効果測定ができません。
2. URLグループ単位で優先順位を合意する。全ページ一括ではなく、トラフィックの多いテンプレート(トップ・商品詳細・検索結果など)から着手する範囲を最初に決めます。
3. 改善実装とあわせて計測の仕組みを整える。Google Analytics 4のWeb Vitalsレポート連携や、リアルユーザーモニタリング(RUM)の導入まで含めると、外注終了後も自社で状態を追えるようになります。
4. 改善後、最低4週間は評価を待つ。フィールドデータは28日間の集計のため、リリース直後にスコアが動かなくても異常ではありません。

まとめ

• LCP・CLS・INPはそれぞれ違う原因・違う対策を持つ指標であり、まとめて「速くする」では改善が進まない。原因調査は必ずフィールドデータ(CrUX/Search Console)とラボデータ(Lighthouse)を役割分担して使う。
• LCPはTTFBと最大要素の読み込み、CLSはサイズ未指定要素、INPはJS処理の重さと、それぞれ機械的にチェックできるポイントがある。改修コストと効果を見て着手順を決める。
• SEOへの影響は限定的だが、広告の品質スコアとCVRへの効果は大きい。SEO単体でなく事業インパクト全体で投資判断をする。

既存プロダクトのCore Web Vitals改善は、まず既存プロダクトの改善、外部チームが最初に見る観点の診断プロセスに沿って現状を可視化するところから始めます。torcheeesでは、現状診断から、継続的な改善支援まで、既存プロダクトの状態に応じて支援範囲を設計しています。改善・モダナイゼーション支援の詳細はこちら、まずは現状を聞かせてください。お問い合わせはこちら。