WordPress高速化完全ガイド2026｜Core Web Vitals・PageSpeed改善の実践手順

---

PageSpeed Insightsでは90点を超えている。それなのに、Search Consoleでは「Core Web Vitals：改善が必要」と表示される。WordPressを高速化したはずなのに、なぜ数字が一致しないのか。

答えは、PageSpeed Insightsの「点数」と、実際のユーザーが体験したCore Web Vitalsが別のデータだからである。2026年のWordPress高速化で追うべきなのは100点ではない。ユーザーがどこで待ち、どこで反応が遅れ、どこで画面が動くのかを特定することである。

つまり高速化とは、プラグインを増やす作業ではない。測定し、原因を絞り、一つずつ修正し、実ユーザー体験の変化を再確認する改善サイクルである。

PageSpeed Insightsでは高得点なのに、なぜSearch Consoleでは「改善が必要」になるのか

PageSpeed InsightsのLab Dataと、CrUXに基づく実ユーザー体験の評価では測定条件と集計単位が異なるため、結果が一致しないことは珍しくない。

WordPress高速化で最初につまずきやすいのが、PageSpeed Insights（PSI）とSearch Consoleの結果の違いです。PSIでは90点以上なのに、Search ConsoleのCore Web Vitalsレポートでは「改善が必要」と表示されることがあります。

これは異常ではありません。PSIには、実際のChromeユーザーから収集されたField Dataと、Lighthouseが一定条件でページをシミュレーションするLab Dataという、性格の異なるデータがあります。

表1：Field DataとLab Dataの違い

項目	Field Data	Lab Data
データ源	実際のChromeユーザー	Lighthouseによるシミュレーション
主な用途	実ユーザー体験の評価	原因の診断・再現
環境	端末・通信・地域など多様	一定条件
時間軸	直近28日間のCrUXデータ	測定時点
見るべき場面	改善結果の確認	何を直すかの特定

PSIのField DataはChrome User Experience Report（CrUX）を基に、直近28日間の実ユーザー体験を表します。一方、Lab Dataは測定した時点のテストです。今日サーバーや画像を改善してLab Dataが良くなっても、Field Dataには改善前の利用体験がまだ含まれています。

Search ConsoleのCore Web Vitalsレポートでも、CrUXに基づく実ユーザー体験の傾向から、問題のあるURLグループを確認できます。個別アクセスログそのものを見るのではなく、類似した体験を持つURL群の傾向を把握するためのレポートと考えると分かりやすいでしょう。

PSIでは個別URLまたはオリジンのField Dataを確認し、Search Consoleでは類似URLをまとめたURLグループ単位で直近28日間の傾向を確認します。Lab Dataで原因を見つけ、Field Dataで成果を確認する。この役割分担を理解すると、「PSIでは速いのにSearch Consoleでは悪い」という混乱の多くは解消できます。

Core Web Vitalsとは？LCP・INP・CLSを正しく理解する

Core Web Vitalsは単なる速度スコアではなく、読み込み・応答性・視覚的安定性という実ユーザー体験の3側面を測る指標である。

Core Web Vitalsは、ページの読み込み、応答性、視覚的安定性に関する実ユーザー体験を測る主要指標群です。現在はLCP、INP、CLSの3つで構成されます。

GoogleはCore Web Vitalsをランキングシステムで利用しています。ただし、良好なCore Web Vitalsだけで検索上位が保証されるわけではありません。Google自身も、SEO上の理由だけで満点を追い続けることは、必ずしも有効な時間の使い方ではないと説明しています。

表2：Core Web Vitalsの推奨基準

指標	何を測るか	良好	改善が必要	不良
LCP	読み込みパフォーマンス	2.5秒以下	2.5秒超〜4.0秒	4.0秒超
INP	操作への応答性	200ms以下	200ms超〜500ms	500ms超
CLS	視覚的安定性	0.1以下	0.1超〜0.25	0.25超

さらに重要なのが75パーセンタイルです。モバイルとデスクトップを分け、少なくとも75％のページ訪問で推奨値を満たしているかを見るのがCore Web Vitalsの基本的な評価方法です。

LCP：最大コンテンツが「見えた」までの時間

LCP（Largest Contentful Paint）は、ページ読み込み開始から、ビューポート内の最大のコンテンツ要素が描画されるまでの時間を測ります。「最もファイル容量の大きい画像」が対象になるという意味ではありません。

記事ページではアイキャッチ画像、ヒーロー画像、大きな見出しやテキストブロックなどがLCP要素になることがあります。まずPSIやChrome DevToolsで何が実際のLCP要素になっているかを確認することが出発点です。

あなたのサイトのトップページでは、何がLCP要素になっているでしょうか。大きな画像なのか、見出しなのか。それを確認しないまま画像圧縮だけを始めると、対策する場所そのものがずれる可能性があります。

INP：クリックした後、画面が反応するまで

INP（Interaction to Next Paint）は、ユーザーがクリック、タップ、キーボード操作を行った際の応答性を測る指標です。2024年3月12日にFID（First Input Delay）を置き換えてCore Web Vitalとなり、最初の操作だけでなく、ページ滞在中のインタラクションをより広く捉えるようになりました。

WordPressでは、大量のJavaScript、重いプラグイン、広告、タグマネージャー、チャット、分析ツールなどがメインスレッドを長時間占有するとINPが悪化することがあります。

CLS：読みながら画面が突然動かないか

CLS（Cumulative Layout Shift）は、予期しないレイアウト移動による視覚的不安定さを測ります。画像や広告の領域が後から確保されたり、Webフォントの読み込みで文字幅が変わったりすると悪化する場合があります。

WordPress高速化は「測定」から始める

高速化プラグインを入れる前に、Search Console、PageSpeed Insights、Chrome DevToolsの順で症状と原因を切り分ける。

WordPressサイトが遅いからといって、すぐにキャッシュプラグインを追加するのはおすすめしません。まず「誰が、どこで、何に困っているか」を測ります。

診断の基本は、Search Consoleで「何が悪いか」を見る → PageSpeed InsightsでFieldとLabの差を見る → DevToolsで「なぜ悪いか」を掘る、という順番です。 この流れを飛ばすと、高速化が「思いついた施策を試す作業」になってしまいます。

1. Search Console：サイト全体の症状を見る

Search ConsoleのCore Web Vitalsレポートでは、CrUXに基づく実ユーザー体験の傾向から、問題のあるURLグループを確認できます。まずモバイルとデスクトップを分け、LCP・INP・CLSのどこに問題が集中しているかを確認します。

ここでは個別のコード原因を探すのではなく、サイト全体のどのページ群に問題が集中しているかを見るのが目的です。

2. PageSpeed Insights：FieldとLabを比較する

PageSpeed Insightsでは、Field DataがあるページならCrUXに基づく実ユーザーのCore Web Vitalsを確認できます。その下に表示されるLighthouseのLab Dataや診断項目を使って、改善候補を探します。

Labのパフォーマンススコアが90以上ならLighthouse上では「良好」と分類されますが、それはSEO上の合格点ではありません。 Field Dataが悪ければ、実ユーザー側の問題はまだ残っています。

3. Chrome DevTools／Lighthouse：原因を掘る

Chrome DevToolsではNetwork、Performance、Coverageなどを使い、重い画像、長いJavaScript処理、不要CSS、サードパーティリクエストを詳しく調べられます。

高速化は健康診断に似ています。数値が悪いからといって薬を全部飲むのではなく、検査して原因を特定してから治療することが重要です。

WordPressはどこで遅くなるのか

WordPressの速度低下は一つの原因ではなく、ネットワーク、サーバー、PHP、DB、テーマ、プラグイン、フロントエンドの各層で発生する。

WordPressは特定の「Nginx＋PHP＋MariaDB」だけで動くCMSではありません。Apache、Nginx、LiteSpeedなどのWebサーバー、MySQLやMariaDBなど、さまざまな構成で利用されています。

重要なのは製品名ではなく、どの層で時間を使っているかです。

表3：WordPressの主なボトルネック

層	主な問題	確認するもの
ネットワーク	配信経路、転送量、CDN構成	TTFB、転送サイズ、CDN
Webサーバー	CPU・メモリ不足、キャッシュ不足	TTFB、負荷、キャッシュヒット
PHP / WordPress	重い処理、プラグイン	PHP処理時間、エラー、クエリ
データベース	遅いクエリ、肥大化	クエリ時間、options、インデックス
フロントエンド	画像、CSS、JavaScript、フォント	LCP、INP、CLS、Network
外部サービス	広告、計測、チャット、埋め込み	Third-party scripts、Long Tasks

「WordPressが遅い」のではなく、WordPressを構成するどこかが遅い。この考え方に切り替えると、対策を絞り込めます。

LCPが悪いときに見る場所

LCP改善では画像圧縮だけに飛びつかず、TTFB、LCP要素、リソース発見、CSS、キャッシュの順に原因を切り分ける。

LCPが悪い場合、最初に「画像をWebPにする」と決めつけてはいけません。サーバー応答が遅ければ、画像をいくら圧縮しても改善には限界があります。

1. TTFBを確認：HTML自体が返るまで遅くないか
2. LCP要素を特定：画像か、テキストか、別の要素か
3. LCPリソースのサイズ確認：過剰に大きな画像ではないか
4. 発見タイミング確認：CSSやJavaScriptの後まで画像取得が遅れていないか
5. lazy loadingを確認：LCP画像まで遅延読み込みしていないか
6. render-blockingを確認：CSSやJavaScriptが描画を止めていないか

WebPだけでなくAVIFも選択肢

画像最適化ではJPEG／PNGからWebPへ変換する方法が広く使われていますが、2026年はAVIFも選択肢です。WordPressは6.5（2024年4月2日公開）からAVIFを正式サポートしており、ホスティング環境の画像処理ライブラリが対応していれば通常の画像形式として扱えます。

ただし、AVIFの処理可否はサーバー側のImagickやLibGDなどの環境にも依存します。切り替え前にWordPress管理画面の「ツール → サイトヘルス → 情報 → メディア処理」などで対応状況を確認してください。

また、「AVIFだから必ず何％速くなる」とは言えません。画像の種類、画質設定、元ファイル、表示サイズによって結果は変わります。形式名ではなく、実際のファイルサイズと画質を比較して選ぶのが安全です。

LCP画像をむやみにlazy-loadしない

WordPress Coreには画像のlazy loadingが組み込まれていますが、ファーストビューの重要画像まで遅延読み込みするとLCPを悪化させる可能性があります。

WordPress 6.3（2023年8月8日公開）以降では、CoreがLCP候補と推定した画像へfetchpriority="high"を自動付与し、初期ビューポート内の画像へ不必要なlazy loadingを付けにくくする最適化が導入されています。

ただし、Coreの判定は推定です。PSIやDevToolsで実際のLCP要素を確認し、テーマや高速化プラグインがロード制御を上書きしていないかを検証してください。

INPが悪いときに見る場所

INP改善の中心は、JavaScriptによるメインスレッド占有を減らし、ユーザー操作にブラウザがすぐ反応できる状態を作ることである。

INPが悪いWordPressサイトでは、画像よりJavaScriptを疑う必要があります。クリックやタップをしても、ブラウザが別の長い処理を続けていれば画面更新が遅れます。

主な確認対象は次のとおりです。

• 大量のJavaScriptを読み込むテーマやプラグイン
• 使っていない機能のスクリプト
• 広告・タグマネージャー・分析ツール
• チャット・ヒートマップ・SNSウィジェット
• 大きなLong Task
• 複雑すぎるDOM

「プラグインが多い＝遅い」と単純には言えません。重要なのは数ではなく、各プラグインがフロント側で何を読み込み、何を実行しているかです。

CLSが悪いときに見る場所

CLS改善では、ページ表示後に領域サイズが変わる要素を探し、画像・広告・埋め込み・フォント・動的UIの領域を先に確保する。

CLSの代表的な原因は、画像や広告の読み込み後にページレイアウトが押し下げられることです。画像には可能な限りwidthとheightを指定し、ブラウザが読み込み前から必要な領域を確保できるようにします。

Webフォントも注意が必要です。代替フォントと本来のフォントで文字幅が大きく異なると、読み込み後の切り替えでレイアウトが動く場合があります。

• 画像にwidth／heightを指定する
• 広告・埋め込み領域を先に確保する
• 後から挿入するバナーや通知の配置を見直す
• 使用フォントとウェイトを減らす
• font-displayと代替フォントを調整する

WordPress高速化の実践10施策

施策は効果期待度だけで選ばず、実測したボトルネックに対して必要なものだけを一つずつ適用する。

最初に着手する施策は、サイトごとに異なります。ただし迷った場合は、①LCP要素とTTFB、②不要なJavaScriptと外部スクリプト、③画像・広告・埋め込みによるCLSの順に確認すると、実ユーザー体験へ直結する問題を見つけやすくなります。

表4：WordPress高速化10施策と主な対象

施策	主に効く場所	優先判断
画像最適化	LCP・転送量	LCP画像が重い場合
ページキャッシュ	TTFB	動的生成が遅い場合
不要プラグイン整理	PHP・JS・DB	処理負荷が高い場合
テーマ最適化	CSS・JS・DOM	テーマ由来の負荷が大きい場合
CSS最適化	LCP	render-blockingが大きい場合
JavaScript最適化	INP	Long Taskが多い場合
DB最適化	TTFB・管理画面	クエリが遅い場合
CDN導入	転送・静的資産	配信経路改善が必要な場合
サーバー見直し	TTFB	基盤性能が不足する場合
フォント最適化	LCP・CLS	Webフォント負荷が大きい場合

1. 画像を適正サイズへ最適化する

最初に確認するのは画像形式より表示サイズと実ファイルサイズの一致です。横800pxで表示する画像に数千pxの原画像をそのまま配信していないか確認します。

WebPやAVIFへの変換は有効ですが、一律の改善率を期待するのではなく、実際の転送サイズと画質で比較してください。

2. ページキャッシュを活用する

ページキャッシュは、WordPressがPHPとDBから毎回ページを生成する処理を減らし、TTFB改善につながる場合があります。

WP Rocket、W3 Total Cache、WP Super Cacheなど複数の選択肢がありますが、特定製品を「最高性能」と決めつけることはできません。ホスティング側ですでにページキャッシュやEdge Cacheを提供している場合もあります。

3. 不要プラグインを監査する

プラグインは「数」よりも処理内容を見ます。使用していないもの、機能が重複しているもの、フロント側へ大量のCSS／JavaScriptを追加するものを確認してください。

1. インストール済みプラグインを一覧化する
2. 各プラグインの役割を確認する
3. 重複機能を探す
4. ステージング環境で一つずつ無効化する
5. 速度と機能への影響を再測定する

4. テーマは「高速ランキング」ではなく実測で選ぶ

テーマを変更すれば必ず速くなるわけではありません。テーマ選定では、ブランド名より次を確認します。

• 不要CSS／JavaScriptが少ないか
• DOMが過度に複雑でないか
• ページビルダー依存が強すぎないか
• 画像ロード最適化を邪魔していないか
• Webフォントを過剰に読み込まないか
• ステージング環境で実測して速いか

5. CSSを整理する

Minificationだけで劇的に速くなるとは限りません。未使用CSSやrender-blocking CSSの方が大きな問題になる場合があります。

Critical CSSや未使用CSS削減は有効ですが、自動最適化によってレイアウトが崩れるケースもあるため、必ずステージングで確認します。

6. JavaScriptを必要な分だけ読み込む

INPが悪い場合はJavaScriptの総量だけでなく、メインスレッドを長時間占有する処理を減らします。不要スクリプトの削除、遅延読み込み、第三者スクリプトの整理などを行います。

7. データベースを「掃除」ではなく診断する

リビジョン、期限切れtransient、不要データが増えることはありますが、無差別に削除することが高速化になるとは限りません。バックアップを取り、遅いクエリや肥大化したテーブルを確認してから作業します。

「DB最適化ボタンを押す」より、「何のクエリが遅いのかを見る」方が本質的です。

8. CDNを必要に応じて使う

CDNは、ユーザーに近いエッジ拠点からキャッシュ済みの画像、CSS、JavaScriptなどを配信し、配信経路の待ち時間やオリジンサーバーへの負荷を減らせる場合があります。

Cloudflare、Amazon CloudFrontなど選択肢はありますが、日本国内中心の小規模サイトでは、CDN導入前にサーバー応答や画像サイズを直した方が効果的なケースもあります。

9. サーバーはTTFBを見て判断する

「マネージドWordPressだから速い」「SSDだから速い」といった単純な判断は避けます。見るべきなのは実際のTTFB、CPU、メモリ、PHP処理、DB応答、キャッシュです。

HTTP/2やHTTP/3、CDN、オブジェクトキャッシュ、PHP workerなども確認対象になりますが、基盤変更は原因を確認してから行います。

10. Webフォントを最適化する

Webフォントはデザインに大きく貢献しますが、複数ファミリー・複数ウェイトを読み込めば転送量が増えます。必要なフォントだけに絞り、ローカル配信やpreloadの必要性も検討します。

WordPress Coreがすでに高速化している領域を知る

WordPress Core自身も画像読み込みやAVIF対応を改善しており、古い高速化プラグインの設定をそのまま重ねると逆効果になる場合がある。

WordPressは高速化機能をCore側へ継続的に取り込んでいます。そのため、数年前の記事に書かれた「この機能は必ずプラグインで追加する」という前提は、そのまま使えない場合があります。

• WordPress 5.5以降：画像のnative lazy loading対応
• WordPress 6.3（2023年8月8日公開）：LCP候補画像へのfetchpriority="high"自動付与など画像ロード最適化を強化
• WordPress 6.5（2024年4月2日公開）：AVIF画像形式を正式サポート

ただし、画像読み込みの最適化はWordPress Core、テーマ、プラグインの更新によって変わり得ます。ここで挙げた挙動は本記事の更新日時点で確認しているCore機能として捉えてください。

特に注意したいのが、LCP候補画像にloading="lazy"とfetchpriority="high"を同時指定するような矛盾です。Core・テーマ・プラグインがそれぞれロード制御を行うと、最適化が重複する場合があります。

高速化機能は「足せば足すほど速い」のではない。現在のWordPress Coreが何をしているか確認したうえで、不足する部分だけを補うのが安全です。

高速化でやってはいけない6つのこと

WordPress高速化で失敗しやすいのは、原因を測らず複数施策を同時実行し、改善したのか悪化したのか分からなくなることである。

高速化には、「良さそうだから」という理由だけで実行すると、かえって原因を見失う施策があります。特に次の6つは、WordPress運用で避けたい典型例です。

1. PageSpeed Insightsで100点だけを追う
2. 高速化プラグインを複数重ねる：ページキャッシュ、lazy loading、JavaScriptのdefer・delay、CSS最適化を複数ツールで同時制御しない
3. LCP候補画像まで一律でlazy-loadする
4. CSS／JavaScript最適化を本番で一気に行う
5. 原因を調べずサーバーを移転する
6. 施策を複数同時に実行して効果測定できなくする

改善後はどう測るか

施策直後はLab Dataで副作用と方向性を確認し、その後はCrUXに基づくField DataとSearch Consoleで実ユーザー側の変化を追う。

画像圧縮、キャッシュ、JavaScript削減などを実施した直後は、PSIやLighthouseで変更前後を比較できます。ただし、それだけで「Core Web Vitals改善完了」と判断しないでください。

PSIのField Dataは直近28日間のCrUXデータに基づくため、改善前の利用体験はすぐには消えず、時間とともに新しいデータへ置き換わっていきます。

Search ConsoleのCore Web Vitalsレポートでも、CrUXを基にした直近28日間の指標をURLグループ単位で確認できます。PSIでは個別ページの診断を深め、Search Consoleでは改善がサイト全体へ広がっているかを追う、という使い分けが実務的です。

表5：改善後の確認サイクル

タイミング	確認内容	主なツール
施策直後	表示崩れ・Lab指標・リクエスト	PSI / Lighthouse / DevTools
継続確認	実ユーザー指標の変化	PSI Field Data
サイト全体	URLグループの傾向	Search Console
大規模サイト	独自のユーザー別実測	RUM / web-vitals

重要サイトではCrUXだけでなく、独自のReal User Monitoring（RUM）を導入すると、ページ、端末、ユーザー条件など、より細かな条件でボトルネックを追跡できます。

Core Web VitalsとSEOをどう考えるべきか

Core Web Vitalsは検索ランキングで考慮されるが、検索意図に合わないページを高速化しても、コンテンツ価値そのものは補えない。

GoogleはCore Web Vitalsをランキングシステムで利用しています。一方で、検索では関連性やコンテンツの有用性など多くの要素が評価されます。

したがって、「LCPを2秒にすれば順位が何位上がる」といった計算はできません。 Core Web Vitalsは、良いコンテンツをユーザーが快適に利用できる状態にするための基盤と考えるのが適切です。

GoogleがSEOについて公式に何を案内しているかは、Google公式SEOガイド2026で整理しています。

また、順位変動が起きたときにCore Web Vitalsだけを原因と決めつけるのは危険です。検索順位下落の切り分けは、Googleアップデートと順位回復の実務ガイドも参照してください。

まとめ

2026年のWordPress高速化では、PageSpeedの点数より、実ユーザーが体験している問題を測定し、原因だけを順番に取り除くことが重要である。

WordPress高速化というと、画像圧縮、キャッシュ、CDN、プラグイン削減といった「施策」が先に語られがちです。しかし、同じ施策がすべてのサイトで同じ効果を出すわけではありません。

まずSearch Consoleで症状を見る。PSIでField DataとLab Dataを分ける。DevToolsで原因を特定する。そして一つずつ直す。 この順番を守れば、高速化は「効いた気がする施策」の積み重ねではなく、再現可能な改善になります。

WordPress高速化は、100点を取る競争ではない。実ユーザーの待ち時間を減らす改善活動である。

その結果として、Core Web Vitalsの改善だけでなく、離脱の抑制やコンバージョン機会の改善につながる可能性があります。SEOのために速くするのではありません。訪れた人が、待たされず、迷わず、必要な情報へ到達できる状態を作ることが、企業のWeb資産の品質です。

専門用語まとめ

WordPress高速化で頻出する指標と測定概念を、実務で迷わないために短く整理する。

Core Web Vitals

実ユーザー体験のうち、読み込み・応答性・視覚的安定性を評価する主要指標群。現在はLCP・INP・CLSで構成されます。

Field Data

実際のユーザーの端末・ネットワーク環境から収集されたデータ。PageSpeed InsightsではCrUXに基づく直近28日間のデータを表示します。

Lab Data

Lighthouseなどが一定条件でページをシミュレーションして測定するデータ。実ユーザー評価より、原因診断に向いています。

CrUX

Chrome User Experience Reportの略。実際のChromeユーザーから集計されたユーザー体験データです。

TTFB

Time to First Byteの略。リクエスト開始から最初のデータを受信するまでの時間で、サーバー側ボトルネックの診断に役立ちます。

RUM

Real User Monitoringの略。実際のサイト利用者からパフォーマンスデータを収集し、自社条件で詳細分析する手法です。

参考文献 / 出典

Core Web Vitalsの基準値、CrUX、Search Console、WordPress Coreの画像最適化についてはGoogle・Chrome・WordPress公式資料を基準としている。

次に読むならこの3本

高速化の次は、Google公式SEOの全体像、品質評価、順位変動の診断へ進むとテクニカルSEOの位置づけが整理できる。

補足Q&A

WordPress高速化で特に誤解されやすいPageSpeedの点数、反映期間、施策の進め方について整理する。

Q1.
PageSpeed Insightsは何点なら合格ですか？

A1.
SEO上の公式な「合格点」はありません。

Lighthouseでは90点以上が良好と分類されますが、それはLab Dataの評価です。Googleも、Core Web Vitalsで良い結果や満点を取ったからといって検索上位が保証されるわけではないと説明しています。Field Dataと実際のユーザー体験を優先してください。

Q2.
高速化施策をしたのにSearch Consoleがすぐ改善しないのはなぜですか？

A2.
Core Web VitalsのField Dataには、直近28日間の実ユーザー体験が含まれるためです。

改善前のデータは施策直後には消えません。まずLab Dataで変更の方向性を確認し、その後PSIのField DataとSearch ConsoleのURLグループで実ユーザー側の傾向を継続して確認してください。

Q3.
高速化施策は全部まとめて実施した方が速いですか？

A3.
一度にすべて変更することはおすすめしません。

複数施策を同時に行うと、どの変更が改善または悪化の原因なのか分からなくなります。バックアップとステージング環境を用意し、重要度の高いボトルネックから一つずつ変更・測定してください。

更新履歴

Core Web Vitals、WordPress Core、測定方法の変更に合わせて、主要な改稿内容を記録する。