ANSWER FIRST

結論

Core Web Vitalsの改善は、PageSpeed Insightsの点数を一度上げて終える作業ではありません。まず実利用データで影響の大きいページ群と端末を特定し、検証環境でLCP・INP・CLSそれぞれの原因を分解します。そのうえで一度に変更する範囲を絞って実装し、同じ条件の再計測と公開後の実利用データで効果を確認します。検索評価だけを目的にせず、閲覧・申込・更新を妨げる体験上の問題から優先することが重要です。

01

最初に、合格値と事業上の影響を分けて整理する

Core Web Vitalsは、実際の利用者が感じる読み込み性能、操作への応答性、表示の安定性を測る指標です。2026年8月22日時点の公式案内では、LCPは2.5秒以内、INPは200ミリ秒以下、CLSは0.1以下が「良好」の目安で、モバイルとデスクトップを分けたページ読み込みの75パーセンタイルで三指標すべてを評価します。LCPは主要コンテンツが表示されるまで、INPは操作から次の描画まで、CLSは意図しないレイアウト移動の大きさを捉えます。

ただし、基準値だけを見て全ページを同じ優先度で直すと、費用と時間を使う場所を誤ります。企業サイトなら問い合わせや採用、自治体・団体サイトなら申請、避難情報、募集案内など、利用者が目的を達成できないと影響が大きい経路を先に特定します。数値が同程度でも、TOPの装飾画像と申込フォームの応答遅延では事業上の意味が異なります。改善計画には指標値だけでなく、対象ページ、主要端末、利用行動、発生頻度、失敗時の影響を記録します。

  • 対象となるURLまたは共通テンプレート
  • モバイル・デスクトップの区分
  • LCP・INP・CLSの現在値と判定
  • 問い合わせ・申込・閲覧など重要行動
  • 問題が起きた場合の利用者・業務への影響
02

実利用データと検証データを混同しない

改善の入口では、Search ConsoleのCore Web VitalsレポートやPageSpeed Insightsのフィールドデータなど、実際のChrome利用環境を集計した情報を確認します。これは端末性能、通信状態、キャッシュ、地域、操作方法などを含む現実の体験を把握するためのデータです。一方、Lighthouseなどのラボデータは、定めた条件で同じ検査を繰り返し、原因候補を調べる用途に向いています。実利用データとラボデータは対象期間と条件が違うため、数値が一致しないこと自体を異常とは判断しません。

実利用データがURL単位で十分に表示されない場合は、オリジン全体や同じテンプレートのページ群を確認し、独自の実利用計測を導入する必要性も検討します。反対に、ラボ計測が一度良好でも、実際の利用者全体が改善したとは断定できません。最初に『影響範囲の把握は実利用データ』『再現と原因調査はラボデータ』『公開後の確認は再び実利用データ』と役割を決めると、点数の上下に振り回されにくくなります。

  • 実利用データ：問題のあるページ群・端末・傾向を把握
  • ラボデータ：同条件で再現し原因候補を調査
  • 開発者ツール：通信・処理・レイアウト移動を詳細確認
  • 独自計測：重要な操作や利用者区分に沿って補完
  • 公開後データ：改善の定着と再発を監視
実利用計測・原因特定・実装・再検証をつなぎCore Web Vitalsを改善する工程ビジュアル
VISUAL GUIDE実利用データで対象を絞り、検証環境で原因を調べ、改修後に同じ条件と実利用の双方で確かめます。
03

LCP・INP・CLSを原因別に切り分ける

LCPが遅い場合は、最も大きく表示される要素が何かを特定し、サーバー応答、HTMLから対象素材が発見されるまでの遅れ、画像やフォントの転送、描画を妨げる処理を分けて確認します。単にすべての画像を圧縮するのではなく、最初の画面に必要な代表画像の形式・寸法・読み込み優先度、不要な転送、配信場所、キャッシュを見直します。重要画像を遅延読み込みへ指定していないか、CSS背景にしたため発見が遅れていないかも確認対象です。

INPが悪い場合は、メニュー、検索、フォーム、タブなど実際に遅い操作を再現し、長いJavaScript処理、過剰な再描画、重い第三者スクリプト、複雑なDOMを調べます。CLSでは、幅と高さが未指定の画像・広告・埋め込み、後から差し込まれる案内、Webフォントによる文字幅の変化を確認します。三指標へ同時に効く変更もありますが、原因を確認せず一括でコードや画像を変えると、どの施策が有効だったか分からず、別の指標や機能を悪化させるおそれがあります。

  • LCP：対象要素、応答、発見、転送、描画のどこで待つか
  • INP：遅い操作、長い処理、再描画、第三者コードを特定
  • CLS：画像寸法、動的挿入、フォント、固定領域を確認
  • 共通：ページ固有かテンプレート共通かを区別
  • 変更前：再現条件と計測結果を保存
04

改善は影響範囲を限定し、前後比較できる単位で実装する

実装順は、影響の大きさ、改善見込み、作業量、変更リスクから決めます。たとえば全ページ共通のヘッダーで不要な処理が動いている場合は広い改善が期待できますが、障害時の影響も大きいため、代表ページと主要操作の回帰確認が必要です。特定のランディングページだけで大きな画像が原因なら、対象素材の最適化から始める方が安全です。機能を削ることを前提にせず、読み込み時期、実行範囲、代替表示、素材の作り方を見直します。

一回の変更に複数の施策を詰め込まず、変更内容、対象URL、期待する指標、確認方法、戻し方を記録します。公開前は性能だけでなく、表示、フォーム送信、計測、構造化データ、アクセシビリティ、主要内部リンクを再確認します。速度を上げるために重要な本文を初期HTMLから外す、操作できる要素の説明を削る、画像品質を必要以上に落とすと、検索・AIへの情報伝達や利用者の判断を損ないます。性能は単独の合格項目ではなく、内容と機能を守りながら改善します。

  • 利用者・事業への影響が大きい
  • 原因と変更内容の対応を説明できる
  • 共通部品への波及範囲を把握している
  • 公開前に主要機能と情報を回帰確認できる
  • 問題時の切り戻しまたは無効化手順がある
05

同条件の再計測と公開後監視で完了を判断する

実装直後は、変更前と同じ端末条件、URL、操作、計測方法でラボ計測を行い、狙った原因が解消したかを確認します。一回の最高値ではなく複数回の傾向を見て、LCP対象要素や遅延した操作が別の要素へ移っただけではないかも調べます。あわせて、PCとスマートフォン、キャッシュの有無、Cookie同意前後など、主要利用者に関係する状態を絞って確認します。基準値へ届かなかった場合も、原因が減ったのか、新しいボトルネックが現れたのかを記録して次の施策を決めます。

公開後はエラーや問い合わせ動線を早期確認し、その後は実利用データの集計期間を踏まえて推移を監視します。Chrome UX Reportを利用する指標は直近の実利用を集計するため、公開直後のラボ改善が同じ日に反映されるとは限りません。完了条件は『点数が一度良かった』ではなく、『主要機能に問題がない』『再現条件で改善した』『実利用データでも悪化が止まり、改善傾向を確認できた』の三段階にします。更新や広告タグの追加で再発するため、主要テンプレートは定期確認と変更時確認の対象にします。

  • 変更前と同じ条件で複数回比較
  • 主要ページ・操作・フォームの回帰確認
  • 公開直後のエラーと導線を確認
  • 実利用データの更新を待って傾向を確認
  • 再発時の担当者・判断基準・対応期限を決定
FAQ

よくある質問

PageSpeed Insightsで100点を目指すべきですか？

100点そのものを事業目標にする必要はありません。ラボの総合点は原因調査の参考になりますが、Core Web Vitalsの評価は実利用データのLCP・INP・CLSを確認します。重要ページで利用者が目的を達成できること、三指標の原因を継続的に改善できることを優先してください。

実利用データとLighthouseの結果が違うのはなぜですか？

対象が異なるためです。実利用データには多様な端末、通信、地域、キャッシュ、操作が含まれ、ラボデータは定めた環境での一回または複数回の検証です。実利用データで影響範囲を把握し、ラボデータで原因を再現するという役割分担で使います。

改善後、いつ効果を確認できますか？

ラボ環境では公開前後に同じ条件ですぐ比較できます。一方、Chrome UX Reportなどの実利用データは一定期間の利用を集計するため、反映には時間差があります。公開直後は機能・エラー・主要導線を確認し、その後に実利用データの推移を見て完了を判断します。

PRIMARY SOURCES

参考にした一次情報

外部仕様は変更される場合があります。最新情報は各公式ページをご確認ください。

PUBLISHER / UPDATE株式会社ファーストイノベーション

提供サービス：FIRST INNOVATION WEB