Core Web Vitals改善の進め方 点数競争をやめて成果につなげる実務手順

Core Web Vitals改善が長引く事業組織には、ほぼ共通のつまずきがあります。PageSpeed Insightsの点数を毎週追っていても、検索流入や問い合わせ率が大きく動かない。開発側は「改善した」と見ているのに、運用側ではSearch Consoleの不良URLが減らない。こうしたずれは努力不足ではなく、確認する順序を取り違えていることで起こります。

結論から言うと、Core Web Vitals改善で最初に着手すべきなのは、画像圧縮でもJavaScript削減でもありません。実測値で悪いページ群を特定し、LCP・CLS・INPのうち何が事業成果を削っているのかを先に決めることです。web.dev のWeb Vitals解説 や Googleのページ エクスペリエンス説明 が示す通り、Core Web Vitalsは検索評価に関わる重要な指標ですが、順位を単独で決める魔法の点数ではありません。だからこそ、点数を追いかけるより、主要導線の体験を立て直すほうが成果に結びつきます。

特にBtoBサイト、比較検討型のサービスページ、資料請求導線、記事経由の送客ページでは、LCPの遅さとINPの重さが重なるだけで離脱が増えます。実際、LCPが4秒前後、INPが300ミリ秒台の状態を放置している案件は、広告費や制作費を積み増しても歩留まりが上がりません。反対に、主力ページだけでも2.5秒台と200ミリ秒前後へ寄せると、流入後の歩留まりは戻りやすくなります。Core Web Vitals改善は、検索対策のためだけでなく、獲得効率を守る施策です。

JPSM SEO 編集事業部でも、速度改善のご相談では「全ページを均等に速くする」という提案は基本的に行いません。主力テンプレート、CV導線、更新頻度を並べ、どこに工数を投じるべきかを先に決めます。そのほうが、技術施策と事業判断がずれません。この記事では、その進め方を曖昧にせず、実務で使える基準まで落として整理します。

最初に押さえる実測値と検証値の読み分け方

Core Web Vitals改善で最初に確認すべきなのは、実測値です。Lighthouseの点数から議論を始める方法は勧めません。なぜなら、検索評価や実際の離脱率に近いのは、開発環境で一度だけ測った値ではなく、利用者の端末や通信環境から集まる値だからです。web.dev: Web Vitals では、良好ラインとしてLCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下が示されており、その判定は75パーセンタイルで行われます。つまり、一部の速い訪問ではなく、大半の利用者が基準内に収まっているかを見なければなりません。

方針は明快です。月間PVが3万を超え、SEO流入が獲得の主要経路になっているなら、改善会議の冒頭で実測値を確認する運用へ切り替えてください。実測値を見ないまま「体感では速い」「手元の環境では問題ない」と進めると、議論は必ず空転します。特に広告タグ、ABテスト、外部計測、会員向け機能があるサイトでは、手元の軽さと本番の重さは一致しません。

判断基準も曖昧にしないほうがよいでしょう。私は次の基準で切ります。

• LCPが3.0秒を超える主要LPは、今四半期の改善対象に入れるべきです。
• CLSが0.15を超え、CTA周辺やフォーム周辺でずれが起きるページは、見た目の問題ではなく機会損失として扱うべきです。
• INPが250ミリ秒を超え、絞り込みやモーダル操作が多いページは、LCPより先に操作起点の調査を始めたほうが成果につながりやすくなります。

例外もあります。月間PVが1万未満で、更新頻度が低く、主要ページが5ページ以下の小規模サイトなら、厳密なRUM設計までは不要です。その場合は PageSpeed Insights と実機確認を起点に、LCPとCLSの大きな問題から先に片づければ足ります。ただし、資料請求や予約導線など、1ページの価値が高い場合は小規模でも優先度を上げるべきです。

実務でよくある誤解に、「実測値が悪くても検証値が良ければ安心」というものがあります。これは危険です。実測値が悪いのに検証値が良い場合、初回表示後のずれや、利用者の操作後に発生する重い処理が隠れていることが多いからです。web.dev: CLS の最適化 でも、実測と検証の差は、初回表示以外のずれを疑う手がかりになると示されています。差が大きいほど安心せず、むしろ録画して追うべきです。

改善の順番は、次の4段階を崩さないのが基本です。

1. 実測値で悪いページ群を見つける
2. 検証値で原因を再現する
3. テンプレート単位で修正範囲を絞る
4. 改修後に再計測し、再発監視を置く

この順序を飛ばして、軽そうな修正から先に手を付ける進め方は避けるべきです。LCPが悪いのに画像を少し圧縮して終える、CLSが悪いのに演出だけ消す、INPが悪いのにサーバーだけ増強する。こうした施策は部分的には当たっても、全体では外しやすい。Core Web Vitals改善は、順序を守ったほうが、かえって短く終わります。

計測ツールの役割を分けると原因特定が速い

Core Web Vitals改善が遅い案件ほど、ツールの役割が混ざっています。PageSpeed Insightsで原因まで断定し、Chrome DevToolsをほとんど触らず、GA4や独自計測を後回しにする。これでは、何を直せばよいのかが定まりません。最初に決めるべきなのは、どのツールで全体を見て、どのツールで原因を確定し、どのツールで再発を監視するかです。

おすすめの進め方は単純です。PageSpeed Insightsで対象URLを絞り、Chrome DevToolsで原因を確定し、RUMやGA4で優先順位と再発を監視する。この三段構えにしておくと、開発・運用・事業責任者の会話が噛み合います。PageSpeed Insightsだけで最後まで進めるべきではありませんし、逆にDevToolsだけで全体方針を決めるのも危険です。

中規模以上のサイトでは、RUMを後回しにしないほうが効率的です。目安として、月間PVが50万を超える、または主要テンプレートが10種類を超えるなら、独自計測なしで改善を進めるのは非効率になりがちです。理由は単純で、同じサービスページでも広告流入と自然検索流入では読み込み条件が違い、会員ログイン後はさらに別物になるからです。主要LPのコンバージョン率とCore Web Vitalsを重ねて見られない状態で、技術工数を配分するのは危険です。

GA4側の設計が粗い事業組織は、先に GA4の使い方を初心者向けに整理した記事 を見直したほうがよいでしょう。検索流入の入口ページ、CV導線への到達、主要イベントがつながっていないと、「どこを直すと成果に近いか」が判断できません。Core Web Vitals改善は、速度施策であると同時に、計測設計の問題でもあります。

例外として、採用ページやIRページのように更新頻度が低く、CV導線も限られるページ群では、RUMを細かく作り込むより、テンプレートごとに定点計測するほうが費用対効果が高い場合があります。ただし、その場合でも PageSpeed Insights と DevTools の両方は外さないほうがよいです。片方だけでは、改善前後の説明責任を果たせません。

ツールの使い分けを最初に固めると、改善会議の論点が「点数は何点か」から「どのテンプレートの、どの処理を、どの順で直すか」に変わります。現場ではこの差が大きいものです。Core Web Vitals改善を前に進めたいなら、まず役割分担を決めてください。

LCP改善は画像より先に初期応答から直す

LCP改善で最初に疑うべきなのは、画像の容量ではなく、HTMLの返却遅延とリソース発見の遅さです。ここを外すと、工数だけ使って効果が出ません。web.dev: Largest Contentful Paint と web.dev: LCP の最適化 では、LCPをTTFB、リソース発見の遅れ、読込時間、描画遅れに分けて考える方法が示されています。つまり、LCPは「重い画像の問題」ではなく、最初の画面が見えるまでの待ち時間の合計です。

優先して見るべきなのはTTFBです。LCPが3.0秒を超えるページでは、画像形式の見直しより先にTTFBを確認してください。 web.dev: Time to First Byte でも、TTFBは初期表示を支える重要な土台として扱われています。目安として0.8秒以下なら大きな問題になりにくい一方、1.2秒を超えるならサーバー応答やキャッシュ設計を疑うべきです。LCPが4秒で、TTFBが1.5秒あるページに対して画像だけ軽くしても、改善幅は限られます。

LCP改善の優先順位は次の通りです。

特に強調したいのは、ヒーロー画像に遅延読み込みを付けてはいけないという点です。web.dev: LCP の最適化 でも、LCP対象になりやすい画像の扱いには注意が必要だと示されています。CMSや共通部品で全画像に一律の遅延読み込みを付ける実装は、運用しやすく見えてもLCPを壊します。月間10万PV未満の事業サイトでも、これを外すだけで0.5秒以上改善する例は珍しくありません。

次に確認したいのが、初期表示に不要なJavaScriptです。web.dev: クリティカル レンダリング パス の考え方に沿って、最初の画面に不要な処理は後ろへ回すべきです。ヒートマップ、チャット、詳細な計測、会員向け補助UIが初期表示の前に並んでいる構成は、LCPを悪化させやすい。最初の一画面で必要なのは、見出し、要点、主要CTA、必要最小限の画像だけです。

例外もあります。ブランド訴求が極端に強く、動画ヒーローが事業要件として必須のページでは、画像軽量化や遅延制御だけでは解けません。その場合は、動画をLCP対象にしない構成へ変える、最初は静止画で見せて再生を後ろへ回す、といった設計判断が必要です。大きな訴求を守りたいからこそ、表示順を見直すべきでしょう。

LCPの改善策を画像最適化だけに縮めるのは危険です。より踏み込んだ実装論点は LCP改善を実装目線で整理した記事 でも扱っていますが、重要なのは順序です。初期応答、見つかりやすさ、描画条件を整えてから画像を詰める。 この順番なら外しにくい。逆から手を付けると、改善したつもりで終わります。

CLS改善は後から出る要素と寸法不足から潰す

CLS改善で先にやるべきことは、細かなアニメーション調整ではありません。後から差し込まれる要素を止めることと、画像や埋め込みの表示領域を先に確保することです。web.dev: Cumulative Layout Shift と web.dev: CLS の最適化 が挙げる典型原因も、画像サイズ未指定、広告やiframeの寸法未確保、動的挿入、Webフォント切り替えです。現場でも、この四つで大半を説明できます。

方針ははっきりしています。CLSが0.1を超えたら、まず画像・動画・iframe・広告枠の寸法予約を確認してください。 CSSの調整で見た目を整える前に、場所を確保しなければ再発します。記事一覧、関連記事、資料、埋め込みフォーム、バナーなど、一覧系テンプレートでは寸法不足が広く残りやすい。上位3テンプレートを直すだけで、不良URLの半数以上が改善することもあります。

次に止めたいのが、読み込み後に本文やCTAの上へ差し込まれる要素です。関連記事ユニット、同意バナー、比較表の追従UI、チャット、レコメンド、キャンペーン告知。これらが読み位置や押下位置をずらすと、見た目以上に損失が大きくなります。後から出る要素は「出すかどうか」ではなく、「どこに、どれだけの高さを確保して出すか」で判断するべきです。高さを確保できない要素は、本文中ではなく下部や別領域へ逃がしたほうがよい場合もあります。

CLSでは、発生件数より発生位置を重く見るべきです。フッター付近の軽微なずれより、ヒーロー、比較表、CTA、フォーム上部のずれを優先して潰す。これが実務判断です。CLS 0.08でもフォーム送信前にボタンがずれるなら直す価値は高い。一方、CLS 0.12でも本文末尾の小さなずれだけなら後回しにできる場合があります。点数より、事業上重要な位置で起きているかを先に見るべきです。

調査は必ず録画で行います。Chrome DevToolsのPerformance機能 と web.dev: CLS の最適化 を見ながら、Layout Shiftの記録が出た瞬間のDOM変化を追うと、被害を受けた要素ではなく、原因になった要素を見つけやすくなります。私はCLS調査で、最初の5分は数値より録画を優先します。数値だけを見ていると、「どこが悪いか」は分かっても「何が動かしているか」が見えません。

例外もあります。意図的に展開するアコーディオンや、利用者の操作に伴う明示的な表示切り替えは、必ずしも問題とは限りません。重要なのは、利用者が予期した変化かどうかです。クリック直後に展開されるFAQは許容されても、読み進めている途中で関連記事が割り込むのは避けるべきです。CLS改善では、予期しないずれを止めることを第一に置く。 この視点を外さなければ、対処はぶれません。

INP改善は重い処理を短く分割して進める

INP改善が難しく見えるのは、原因が一つに見えにくいからです。ボタンが重い、検索が遅い、モーダルがもたつく。現場ではそう表現されますが、実際には入力遅延、処理時間、描画遅れのどこで詰まっているかを分けて見なければ解決しません。web.dev: Interaction to Next Paint と web.dev: INP の最適化 でも、この分解の重要性が明確に示されています。

優先方針は単純です。INPが250ミリ秒を超えるページでは、「重いイベントを減らす」ではなく、「一回の操作で同時に走る仕事を減らす」方向で設計を見直してください。 クリック直後に状態更新、条件整形、計測送信、履歴更新、関連部品の再描画を全部乗せしている実装は、ほぼ確実に重くなります。利用者が求めているのは、押した直後に画面が反応することです。見えない仕事は後ろへ回して構いません。

優先順位は次の通りです。

• 入力直後にメインスレッドを塞いでいる長い処理を減らす
• イベント内の仕事を短く切り、まとめて一度にやらない
• 画面更新に不要な計測送信や外部処理を後ろへ回す
• DOMの広範囲な差し替えをやめ、必要な範囲だけ更新する
• レイアウト計算を何度も誘発する実装を避ける

特に多いのが、計測タグの積み増しです。GA4、広告タグ、外部接客、独自イベント送信が同じクリックにぶら下がり、操作より先に計測が動いてしまう。これは本末転倒です。CV計測は重要ですが、操作性を壊してまで先に置くものではありません。 タグやイベント設計が整理されていない場合は、GA4のコンバージョン設定を整理した記事 を参照しながら、重複発火や不要イベントを整理したほうが、結果として速くなります。

INP改善では、フロントエンド担当だけに責任を寄せないほうがよいです。重い原因が、UI実装そのものではなく、後から積み増した外部スクリプトや運用ルールにあることが多いからです。絞り込み、比較表、FAQ開閉、モーダル、検索候補表示など、操作が多いページではなおさらでしょう。INPはJavaScriptの量というより、同時にやらせている仕事の設計ミスで悪化すると考えたほうが実態に近い。

例外として、会員向けダッシュボードや高機能な比較画面のように、クライアント側の処理量が一定以上必要なケースはあります。その場合でも、表示を返してから詳細処理を進める、初回操作で全領域を再描画しない、といった工夫はできます。機能が多いから遅くても仕方ない、という判断は避けるべきです。

INP改善で近道になるのは、重い一発処理をなくすことです。メインスレッドを塞ぐ長いタスクが見つかったら、そこから直してください。抽象論ではなく、「どの操作で」「どの処理が」「何ミリ秒使っているか」を必ず特定する。そこまで進めれば、INPは感覚論から抜け出せます。

サイト規模別に投資順序を変えると失敗しない

Core Web Vitals改善は、どのサイトでも同じ順番で進めるものではありません。月間PV、テンプレート数、更新頻度、操作の多さによって、最適な順序は変わります。ここを一律にすると、改善対象が広がりすぎて失敗します。大切なのは、サイトの規模そのものより、どこで劣化が起きやすいかに合わせて投資順序を変えることです。

まず、小規模サイトです。月間PV10万未満、主要LPが10ページ未満、更新頻度が月数回以下なら、LCPから着手するべきです。対象はトップページではなく、検索流入が多いサービスページ、資料請求ページ、比較訴求の強いLPに絞ります。ここで画像圧縮だけで終わらせるのではなく、TTFB、ヒーロー画像の見つけやすさ、初期表示に不要な処理の削減に集中する。これが最も回収しやすい進め方です。例外は、予約導線や診断UIなど、操作が多いページが売上の中心になっている場合です。そのときはINP調査を前倒しします。

次に、中規模サイトです。月間PV10万から100万で、記事、一覧、サービス詳細など複数テンプレートが混在するなら、テンプレート単位でLCPとCLSを並行改善するべきです。記事詳細、一覧、サービス詳細の3種類に切るだけで、対象URLの大半を押さえられることがよくあります。ここでPageSpeed Insightsだけで進めるのは避けたほうがよいでしょう。テンプレートごとの癖が異なるため、DevToolsで録画しないと原因が混ざります。例外は、会員機能や絞り込みが強く、一覧系で操作が多い場合で、そのときはINPも同時に見ます。

最後に、大規模サイトです。月間PV100万以上、週次以上で更新し、会員機能や比較UIが多いなら、RUMとINP監視を先に入れるべきです。LCPだけ改善しても、広告差し替え、タグ追加、UI改修で翌週に崩れます。大規模サイトほど、単発改修より再発防止の仕組みに投資したほうが回収しやすい。例外は、サーバー移行直後などで全体のTTFBが急悪化している場合です。そのときはまずLCPの土台を立て直す必要があります。

シナリオ別に整理すると、判断しやすくなります。

• 月間PV10万未満で主要LP中心のサイトなら、LCPを最優先にして主要3ページだけ先に直すべきです。
• 月間PV10万から100万でテンプレートが複数あるサイトなら、ページ単位ではなくテンプレート単位でLCPとCLSを並行改善するべきです。
• 月間PV100万以上で操作が多いサイトなら、INPとRUMを後回しにしてはいけません。
• 週1回以上更新するメディアやECなら、改善前に監視設計を入れるべきです。改修だけ先にやると再発します。

サイト規模に応じて進め方を変えるだけで、改善の失敗はかなり減ります。速度改善を「全部まとめて速くする話」にしないこと。これが、実務では最も効きます。

改善案件で止まりやすい論点を先回りで潰す

Core Web Vitals改善が長引く案件には、止まりやすい論点があります。技術力の問題に見えても、実際には判断基準の不足で止まっていることが少なくありません。ここを先回りで潰しておくと、改善はかなり進めやすくなります。

まず多いのが、「トップページが速いから全体も大丈夫」という誤解です。これは避けるべきです。自然検索の主力がサービスページや記事詳細である事業組織では、トップページの改善効果は限られます。自然検索流入の上位20URL、CV寄与の高い10URL、主要テンプレート3種類を並べ、その重なりから対象を決めるべきです。トップページはその後で構いません。

次に、「Lighthouseの点数が上がったから完了」という判断も危険です。点数はあくまで参考指標です。改善会議では、実測値の改善、主要導線の離脱変化、問い合わせや資料請求への到達率の三つを必ず並べてください。検索評価と事業成果の両方に効いているかを見ない限り、速度施策は内向きの活動になりやすくなります。

三つ目は、「フロントエンドで全部解決できる」という前提です。LCPにはサーバー応答、CLSには広告運用やコンテンツ差し替え、INPには計測タグや接客ツールが絡みます。改善担当を開発だけに固定すると、原因の半分を見落とします。少なくとも、開発、運用、マーケティングの三者で、どのタグや部品を初期表示で許容するかを決めるべきです。

四つ目は、改修後の監視を省くことです。特に週次更新サイトでは、性能劣化は事故ではなく運用の結果です。ヒーロー画像への遅延読み込み、バナー高さ未確保、クリックイベントへの仕事の追加。この三つは再発しやすい。改善の完了条件に、改修後の再計測と公開後の監視を含めるべきです。ここを入れないと、翌月には元に戻ります。

JPSM SEO 編集事業部では、Core Web Vitals改善を技術課題だけで閉じず、検索流入、CV導線、更新運用までまとめて判断します。理由は単純で、速度だけ改善しても、重要ページが対象から外れていれば成果につながらないからです。改善会議が点数と感想の往復になっているなら、論点の置き方から見直したほうが早いでしょう。

今週中に進める具体的な確認手順と優先順位

最後に、今週中に着手するなら何から始めるべきかを、実務の順番で絞ります。ここは曖昧にせず、実行順を決めてください。最初の一週間でやるべきことは、全ページの総点検ではなく、主要導線の特定と原因の確定です。

1. PageSpeed Insights で、自然検索流入が多い主要LP3ページとCV導線3ページの実測LCP・CLS・INPを確認する。トップページだけではなく、主力のサービスページや記事詳細を含めること。
2. 実測値が悪いページを、記事詳細、一覧、サービス詳細、LPなどテンプレート単位で束ねる。ページ単位でばらばらに直し始めない。
3. Chrome DevToolsのPerformance機能 で録画し、LCPはHTML返却から描画まで、CLSはLayout Shift、INPは長いタスクを確認する。数値だけで原因を決めない。
4. LCP画像の遅延読み込み、画像や埋め込みの寸法不足、クリック直後の重い処理の三点を優先修正する。まずはこの三つで十分です。
5. 改修前後で、自然検索流入、CV導線到達率、フォーム完了率の変化を確認する。速度だけを見て終わらせない。
6. 更新頻度が高いサイトなら、週次または隔週で主要テンプレートを再計測し、タグ追加や新UIが再発源になっていないか監視する。

ここまで進めれば、改善の起点としては十分です。追加で計測設計を整えるなら、GA4の使い方を初心者向けに整理した記事 も見直し、主要導線の到達計測と検索流入の入口をつなげてください。そこで課題が見えれば、Core Web Vitals改善の投資判断はかなりしやすくなります。

Core Web Vitals改善を点数競争にすると、施策は外れやすくなります。実測値を起点に、主力ページのLCP・CLS・INPを順番に直し、再発を監視すること。 この進め方に戻すだけで、表示速度、操作性、検索評価、CV導線の歩留まりは同時に立て直しやすくなります。まずは今週、主要6ページの実測値確認と録画調査から始めてください。