Core Web Vitals改善ガイド｜サイト表示速度を3倍にしてSEO順位を上げる実践手順

Googleの公式データによると、ページ読み込み時間が1秒から3秒に増加すると直帰率が32%増加する（出典：Google「Find out how you stack up to new industry benchmarks for mobile page speed」2018年）。さらにHTTP Archiveの2025年12月調査では、モバイルでCore Web Vitalsの3指標すべてに合格しているサイトは全体の約48%にとどまっている。表示速度が遅いサイトは検索順位だけでなく、売上にも直結する損失を抱えている。

本記事では、情報システム部門が主導してCore Web Vitalsを改善するための具体的手順を、優先度順に整理して解説する。

Core Web Vitalsとは？ 2026年に押さえるべき3指標

Core Web VitalsはGoogleがページエクスペリエンスの評価に使用する3つの指標で構成される。2024年3月にFID（First Input Delay）がINP（Interaction to Next Paint）に置き換えられ、現在は以下の3指標が対象となっている。

LCP（Largest Contentful Paint）

ビューポート内で最も大きなコンテンツ要素が表示されるまでの時間を測定する。合格基準は2.5秒以内。メインビジュアルの画像やヒーローセクションのテキストブロックが対象になることが多い。

INP（Interaction to Next Paint）

ユーザーがクリック・タップ・キーボード入力した際に、次のフレームが描画されるまでの応答時間を測定する。合格基準は200ミリ秒以内。FIDがファーストインタラクションだけを計測していたのに対し、INPはページライフサイクル全体のインタラクションを対象とする。

CLS（Cumulative Layout Shift）

ページ読み込み中に予期しないレイアウトのずれがどれだけ発生したかを定量化する。合格基準は0.1以下。広告バナーや遅延読み込みの画像がレイアウトを押し下げるケースが典型的な原因である。

まず現状を把握する ― 計測ツールと読み方

改善の第一歩は正確な現状把握にある。ラボデータ（開発環境でのシミュレーション）とフィールドデータ（実ユーザーの計測値）の両方を確認することが重要だ。

無料で使える計測ツール一覧

ツール	データ種別	特徴
PageSpeed Insights	ラボ＋フィールド	CrUXデータとLighthouseスコアを同時に確認できる
Google Search Console	フィールド	「ウェブに関する主な指標」レポートでURL単位の状態を把握
Lighthouse（Chrome DevTools）	ラボ	改善提案が具体的。CI/CDに組み込み可能
WebPageTest	ラボ	ウォーターフォール表示で詳細な読み込み過程を確認
CrUX Dashboard（データポータル）	フィールド	時系列での推移を可視化できる

フィールドデータが最優先

Lighthouseスコアが高くてもCrUX（Chrome User Experience Report）のフィールドデータが不合格であれば、Googleはそのページを「不良」と判定する。情報システム部門の高速なPC環境で問題なくても、実ユーザーの3G回線・低スペックスマートフォンでは遅いというケースは非常に多い。Search Consoleの「ウェブに関する主な指標」レポートを週次で確認する運用を推奨する。

LCP改善 ― 表示速度を劇的に短縮する5つの施策

LCPはユーザーが「ページが表示された」と感じるタイミングに直結するため、最優先で取り組むべき指標である。

1. 画像の最適化

LCP要素が画像であるケースは全体の約70%を占める（Web Almanac 2024調査）。以下の対策を組み合わせる。

• 次世代フォーマットへの変換：JPEG/PNGをWebPまたはAVIFに変換する。AVIFはWebP比で約20%のファイルサイズ削減が可能
• 適切なサイズの提供：srcset属性とsizes属性を使い、デバイス幅に応じた画像を配信する
• プリロードの活用：LCP要素となる画像に``を指定し、発見を早める

2. サーバー応答時間（TTFB）の短縮

Time to First Byteが1秒を超えている場合、LCPの合格は難しい。CDN（Content Delivery Network）の導入、サーバーサイドキャッシュの設定、データベースクエリの最適化を検討する。

3. レンダリングブロックリソースの排除

CSSとJavaScriptがHTMLのパースを阻害していないかを確認する。クリティカルCSSのインライン化、非同期読み込み（async/defer属性）の適用が効果的だ。

4. フォント表示の最適化

Webフォントの読み込みが遅い場合、テキストがLCP要素のサイトではスコアが大きく悪化する。`font-display: swap`を設定し、フォントファイルのプリロードを行う。

5. サードパーティスクリプトの遅延読み込み

Google Tag Manager、チャットウィジェット、SNSボタンなどのサードパーティスクリプトは、ページの初期読み込みに含めず、ユーザーインタラクション後に読み込む方式に変更する。

INP改善 ― ユーザー操作への応答性を高める

INPはFIDの後継指標として2024年3月から正式導入された。ページ全体のインタラクション応答性を評価するため、対策がより包括的になる必要がある。

JavaScript実行時間の削減

• メインスレッドのロングタスク（50ms超）を特定し、分割する
• 不要なポリフィルやライブラリを削除する
• `requestIdleCallback`や`scheduler.yield()`を使い、重い処理を小さなタスクに分割する

イベントハンドラの最適化

クリックイベントやスクロールイベントに紐づく処理が重い場合、INPが悪化する。デバウンス・スロットルの適用、仮想スクロールの導入を検討する。

DOM要素数の削減

DOM要素数が1,500を超えるとINPに悪影響が出始める。不要なラッパー要素の削除、コンポーネントの遅延レンダリング（IntersectionObserver活用）で対処する。

CLS改善 ― レイアウトのガタつきをゼロにする

CLS（Cumulative Layout Shift）は視覚的な安定性を示す指標であり、ユーザー体験に大きく影響する。

画像・動画にサイズ属性を必ず指定する

width/height属性またはCSSのaspect-ratioプロパティを指定し、ブラウザが事前にスペースを確保できるようにする。これだけでCLSの大半が解消されるケースも多い。

広告スロットに最小高さを設定する

広告の読み込みが遅延するとコンテンツが押し下げられる。`min-height`を設定してスペースを事前確保する。

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

Cookie同意バナー、プロモーションバーなど、後から挿入されるUI要素はCSS Transformで表示し、レイアウトシフトを発生させないようにする。

改善事例 ― 製造業B社のコーポレートサイト

製造業B社（従業員80名）は、10年前に構築したWordPressサイトのCore Web Vitalsが全ページ「不良」判定を受けていた。以下の改善を3か月間で段階的に実施した。

項目	改善前	改善後
LCP（モバイル）	6.2秒	1.8秒
INP（モバイル）	480ms	120ms
CLS	0.35	0.04
PageSpeedスコア	28点	89点

改善後6か月でオーガニック検索流入が42%増加し、問い合わせ件数は月平均で1.8倍に増えた。技術的な改修だけでなく、不要なプラグインの棚卸しと画像ワークフローの見直しが大きな効果をもたらした。

改善プロセスの計画策定や技術選定について、弊社の導入事例もぜひ参考にしてほしい。

社内で改善を進めるための体制づくり

Core Web Vitalsの改善は一度やれば終わりではなく、継続的なモニタリングと改善のサイクルが必要になる。

計測の自動化

Lighthouse CIをCI/CDパイプラインに組み込み、デプロイごとにパフォーマンスをチェックする。スコアが閾値を下回った場合にアラートを出す仕組みにする。

改善の優先順位付け

すべてのページを一度に改善するのは現実的ではない。Search Consoleの「ウェブに関する主な指標」レポートで「不良」判定のページを抽出し、トラフィックが多い順に対応する。

外部パートナーの活用

画像最適化やCDN設定などのインフラ周りは自社で対応し、JavaScriptのリファクタリングやサーバーサイドレンダリングの導入など専門性が高い領域は外部パートナーと連携するのが効率的だ。GXOでは自社の技術力と180社以上の支援実績を活かした支援を行っている。

FAQ

Q1. Core Web Vitalsを改善するとSEO順位は本当に上がるのか？

Core Web Vitalsはランキングシグナルの一つとして公式に確認されているが、コンテンツの関連性やE-E-A-Tほど強い要素ではない。ただし、同程度の品質のコンテンツが競合している場合、ページエクスペリエンスが差別化要因になる。加えて、直帰率の低下やコンバージョン率の向上など、SEO以外のビジネス指標にも好影響がある。

Q2. WordPressサイトでもCore Web Vitalsは改善できるか？

改善可能である。画像の遅延読み込み、キャッシュプラグインの導入、不要プラグインの削除、テーマの軽量化で大幅な改善が見込める。ただし、プラグインを10個以上使用している場合や古いテーマを使っている場合は、根本的な見直しが必要になることもある。

Q3. 改善にかかる期間と費用の目安は？

対策の範囲により異なるが、画像最適化とキャッシュ設定だけであれば1〜2週間、JavaScriptのリファクタリングやサーバー構成の見直しを含む場合は2〜3か月が目安になる。費用は簡易的な改善で30〜80万円、フルリニューアルを伴う場合は200〜500万円程度が一般的な相場である。

Q4. LCP・INP・CLSのうち、どれを最優先で改善すべきか？

3指標のうち1つでも「不良」であれば検索結果での評価に影響するため、すべて「良好」にすることが目標になる。優先順位としては、LCP（表示速度の体感に直結）→ CLS（比較的対策が容易）→ INP（JavaScript改修が必要で工数がかかる）の順序で取り組むケースが多い。

Q5. 自社の情報システム部門だけで対応できるか？

画像最適化、キャッシュ設定、CDN導入など基盤的な施策は情シス部門で十分対応できる。一方で、フロントエンドのJavaScriptリファクタリングやレンダリングアーキテクチャの変更（SSR/SSG導入など）は専門的なWeb開発スキルが必要になるため、外部パートナーとの協業を検討するのが現実的だ。

GXO実務追記: システム開発・DX投資で発注前に確認すべきこと

この記事のテーマは、単なるトレンド紹介ではなく、要件定義、費用、開発体制、ベンダー選定、保守運用を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。

まず決めるべき3つの論点

論点	確認する内容	未整理のまま進めた場合のリスク
目的	売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか	成果指標が曖昧になり、PoCや開発が終わっても投資判断できない
範囲	対象部署、対象業務、対象データ、対象システムをどこまで含めるか	見積もりが膨らむ、または重要な連携が後から漏れる
体制	自社責任者、現場担当、ベンダー、保守運用者をどう置くか	要件確認が遅れ、納期遅延や品質低下につながる

費用・期間・体制の目安

フェーズ	期間目安	主な成果物	GXOが見るポイント
事前診断	1〜2週間	課題整理、現行確認、投資判断メモ	目的と範囲が商談前に整理されているか
要件定義 / 設計	3〜6週間	要件一覧、RFP、概算見積、ロードマップ	見積比較できる粒度になっているか
PoC / MVP	1〜3ヶ月	検証環境、効果測定、リスク評価	本番化判断に必要な数値が取れるか
本番導入	3〜6ヶ月	本番環境、運用設計、教育、改善計画	導入後の運用責任と改善サイクルがあるか

発注前チェックリスト

• [ ] 発注前に目的、対象業務、利用者、現行課題を1枚に整理したか
• [ ] 必須要件、将来要件、今回はやらない要件を分けたか
• [ ] 見積比較で、開発費だけでなく保守費、運用費、追加改修費を見たか
• [ ] ベンダー選定で、体制、実績、品質管理、セキュリティ、引継ぎ条件を確認したか
• [ ] 検収条件を機能、性能、セキュリティ、ドキュメントで定義したか
• [ ] リリース後3ヶ月の改善運用と責任分界を決めたか

参考にすべき一次情報・公的情報

• 経済産業省 DX政策
• IPA DX関連情報
• デジタル庁 標準ガイドライン群
• OWASP Top 10

上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。

GXOに相談するタイミング

次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。

• 見積もり依頼前に、要件やRFPの粒度を整えたい
• 既存ベンダーの提案が妥当か第三者視点で確認したい
• 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
• 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
• PoCや診断で終わらせず、本番導入と運用改善まで進めたい