WordPress パフォーマンス最適化：実践ガイド

遅いWordPressサイトを高速化するには、優先順位に従って5つの項目を修正します。高速なホスティングとページキャッシュ、画像最適化、プラグインの管理、圧縮機能付きCDN、そしてデータベースとサーバーのチューニングの順です。各変更は、一度限りのLighthouseスコアではなく、実際のCore Web Vitalsフィールドデータと照合して検証してください。この順序には意味があります。各施策は影響度の高い順に並んでおり、ほとんどのサイトでは最初の2つで速度低下の大部分が回復します。このガイドでは、各ステップを具体的な修正方法、改善される指標、そして管理型ホスティングや共有ホスティングでは実施できない修正の明確な注記とともに解説します。

このガイドが解決する核心的な問題は「優先順位付け」です。WordPressのパフォーマンスに関するアドバイスは、40項目のヒントが羅列されたリストとして提示されることが多く、どれが実際にLargest Contentful Paint（LCP）やInteraction to Next Paint（INP）を改善するのかを自分で判断しなければなりません。このガイドでは、すべての修正が影響度でランク付けされ、測定可能な目標と紐付けられています。これにより、効果的な箇所に労力を集中させ、実際の訪問者がサイトをどのように体験しているかに基づいて各変更を検証できます。

優先度別の修正手順の概要

何かを変更する前に、各修正が何を対象としているか、そしてご利用のホスティングプランでそれが実施可能かどうかを把握してください。以下の表は、この記事の残りの部分の作業計画です。

上から順に作業してください。すべてを一度に適用するのではなく、各変更後に必ず再測定してください。そうすることで、どの修正が実際にサイトの改善に役立ったかを推測ではなく確認できます。

まず計測する：ラボスコアと実ユーザーフィールドデータ

まず、多くのガイドが混同している2種類の計測を区別することから始めましょう。Lighthouseスコア（PageSpeed Insightsの「診断」部分を動かすエンジン）はラボテストです。つまり、1台のシミュレートされたデバイス、1つのネットワークプロファイル、1つの場所からのテストです。一方、フィールドデータは実際の訪問者が体験した内容であり、GoogleがChrome User Experience Report（CrUX）で収集した、75パーセンタイルで報告される直近28日間のデータセットです。実際のユーザーは高速なエミュレートされたデスクトップではなく、モバイルネットワーク上のミドルレンジのAndroid端末を使用しているため、ラボではグリーンスコアを獲得していてもCrUXでは不合格になることがあります。

重要な3つの指標はCore Web Vitalsです。2026年時点での「良好」な閾値は、フィールドデータの75パーセンタイルで評価した場合、LCP ≤2.5秒（読み込み）、INP ≤200ミリ秒（応答性）、CLS ≤0.1（視覚的安定性）です。INPは2024年3月12日にFirst Input DelayをCore Web Vitalsの指標として正式に置き換えました。FIDに言及しているガイドは時代遅れです。INPについては、200ミリ秒から500ミリ秒の間は「改善が必要」、500ミリ秒を超えると「不良」と判定されます。

サーバーサイドの数値として**Time to First Byte（TTFB）**も把握しておきましょう。これはサーバーがHTMLの最初のバイトを送信するまでの遅延です。TTFBが高い場合は、ホスティングの遅さ、ページキャッシュの欠如、またはデータベースの肥大化を示しており、これらはこのガイドが最初に修正する項目です。実用的な目標値は約800ミリ秒未満で、キャッシュされたページではより低い値が望ましいです。

実ユーザーモニタリング（RUM）とセッションリプレイは、ラボとフィールドのギャップを埋めるものです。合成テストは1か所から1回実行されるだけですが、セッションリプレイとRUMは実際の訪問者が遭遇するLCPの停滞、レイアウトシフト、インタラクションの遅延を記録します。例えば、同意バナーやチャットウィジェットのスクリプトが最初のタップを遅らせたり、低速な接続環境でのみヒーロー画像が停滞したりするケースが挙げられます。WordPressの遅いインタラクションのセッションリプレイでは、単一のサードパーティまたはプラグインのスクリプトがメインスレッドを占有していることが頻繁に明らかになります。これは1か所からのLighthouse実行では見逃してしまう種類の障害です。OpenReplayのようなツールはWordPressで動作するJavaScriptスニペットを実行し、このラボとフィールドのギャップを解消します。

ホスティングとキャッシュ：WordPressの速度最適化における最大の施策

ホスティングとキャッシュは基盤であり、最大の改善効果が得られる部分です。TTFBが高く、ホストが安価な共有インフラを使用している場合、どれだけ画像を調整しても救済できません。サーバーがボトルネックだからです。

ホスティングの選定基準（「最良のホスト」は予算とトラフィックによって異なるため、単一の推奨ではなく基準を示します）：

• エントリーレベルの共有ホスティングよりも、クラウド、VPS、管理型WordPress、または専用サーバーを優先してください。
• NVMe SSDストレージ、最新のPHP、HTTP/2またはHTTP/3のサポート、サーバーレベルのキャッシュを確認してください。
• 管理型WordPressの場合、オブジェクトキャッシュ（RedisまたはMemcached）が含まれているか確認してください。
• ベンダーのデモではなく、実際のページでホスト候補のTTFBをテストしてください。

キャッシュには2つの層があります：

1. ページキャッシュは完全にレンダリングされたHTMLを保存し、リクエストのたびにWordPressとPHPがページを再構築しないようにします。管理型ホストでは多くの場合、サーバーレベルで自動的に行われます。その他のホストでは、WP Super Cache、W3 Total Cache、またはWP Rocketなどのプラグインが対応します。これはキャッシュ層の中で最も効果が高く、TTFBを大幅に削減します。
2. オブジェクトキャッシュ（RedisまたはMemcached経由）は、繰り返し行われるデータベースクエリの結果をメモリに保存します。主に、完全にページキャッシュできない動的なページ、ログイン済みユーザー向けのページ、またはWooCommerceのページに効果があります。Redis/Memcachedサービスが必要なため、通常はそれを提供している管理型プランか、自分で管理するVPS上でのみ利用可能です。

まずページキャッシュを有効にしてください。ほぼすべての環境で利用可能であり、サーバーの応答時間を最も大幅に削減できます。オブジェクトキャッシュは、ホストが提供しており、かつキャッシュできないトラフィックが相当数ある場合にのみ追加してください。

画像最適化：圧縮、モダンフォーマット、CLSの修正

画像は通常、WordPressページで最も重いコンテンツであり、LCPが遅い最も一般的な原因です。LCP要素はヒーロー画像であることが多いためです。以下の4つの修正を順番に実施してください：

1. 圧縮とリサイズ。 表示サイズを超えない画像を提供し、非可逆圧縮を適用してください。ShortPixel、Imagify、またはEWWW Image Optimizerなどのプラグインがアップロード時にこれを自動化します。
2. モダンフォーマットの使用。 サポートされている場合は、JPEG/PNGの代わりにWebPまたはAVIFを使用してください。どちらも同等の品質でファイルサイズを大幅に削減できます。
3. スクリーン外の画像の遅延読み込み。 WordPressはデフォルトで画像にloading="lazy"を追加し、スクロールしないと見えない部分の読み込みを遅延させます。LCP/ヒーロー画像には遅延読み込みを適用しないようにしてください。改善しようとしている指標そのものを遅延させることになります。
4. 明示的なwidthとheightの設定。 画像が読み込まれる前にブラウザがスペースを確保できるよう、常に固有の寸法（またはCSSのaspect-ratio）を含めてください。寸法の欠如はレイアウトシフトの主な原因であり、これを修正することでCLSが直接改善されます。

<!-- レイアウトスペースを確保してシフトを防ぐ。LCP画像なので遅延読み込みしない -->
<img src="hero.webp" width="1200" height="630" alt="…" fetchpriority="high">

LCP画像にfetchpriority="high"を設定することは、LCP最適化として文書化されており、ブラウザに早期に読み込むよう指示します。

プラグインの管理：量より質

重要な指標はプラグインの数ではなく、プラグインのコストです。よく作られたキャッシュプラグイン1つは効果的ですが、すべてのページでCSSとJavaScriptを読み込む粗悪なスライダーや「オールインワン」プラグイン1つはすべてのページに悪影響を与えます。各プラグインの実際のコストを監査してください：

• Query Monitorを使用して、遅いデータベースクエリとそれを発生させたプラグインを確認してください。
• プラグインプロファイリングツールを使用して、特定のプラグインに起因する読み込み時間と追加リクエストを把握してください。
• 機能が重複するプラグインを削除し、必要な機能のみを読み込めるモジュール型のツールを優先してください。
• ページビルダーには特に注意してください。大きなCSS/JSバンドルと深くネストされたマークアップを含むことが多く、LCPとINPの両方を悪化させます。

重いプラグインを1つ無効化して削除するだけで、インタラクションをブロックしていたメインスレッドのJavaScriptが除去されるため、数十の細かい最適化よりも実際の応答性が改善されることがよくあります。

CDNと圧縮：Brotli、gzip、HTTP/2-3

コンテンツデリバリーネットワーク（CDN）は、画像、CSS、JavaScript、フォントなどの静的アセットを、各訪問者に物理的に近いエッジロケーションから配信することで、レイテンシを削減し、オリジンサーバーの負荷を軽減します。Cloudflare、Bunny.net、Fastlyが一般的な選択肢です。多くの管理型WordPressホストにはCDNがバンドルされています。グローバルなユーザーを対象とする場合はLCPとTTFBが大幅に改善されますが、単一リージョンのユーザーを対象とする場合は改善幅が小さくなります。

CDNと合わせて、トランスポートレベルの2つの改善も実施してください：

• テキスト圧縮。 HTML、CSS、JavaScriptをBrotliまたはgzipで提供してください。Brotliは一般的に、同等の速度でgzipよりもテキストアセットをより効果的に圧縮します。ほとんどのCDNと最新のサーバーでは自動的に有効化されています。ブラウザのDevToolsのNetworkタブでContent-Encodingレスポンスヘッダーを確認して、機能していることを確かめてください。
• HTTP/2またはHTTP/3。 どちらも1つの接続で多数のリクエストを多重化し、HTTP/1.1を遅くしていたhead-of-lineブロッキングを解消します。DevToolsのProtocolカラムでアクティブな場合はh2（HTTP/2）またはh3（HTTP/3）と表示されます。

これらはコードの変更ではなく設定の切り替えであり、実質的にすべての最新のホストとCDNで利用可能です。

データベースのクリーンアップ：リビジョン、トランジェント、リビジョン上限

WordPressのデータベースには、クエリを遅くしてバックアップを肥大化させる不要なデータが蓄積されます。投稿のリビジョン、自動下書き、ゴミ箱に入ったコメントやスパムコメント、孤立したメタデータ、期限切れのトランジェントなどです。これらをクリーンアップすることで、キャッシュされていないページや動的なページのTTFBが低下します。

最も効果的な予防策は、投稿リビジョンの上限を設定することです。デフォルトではWordPressはリビジョンを無制限に保存するため、頻繁に編集された投稿には数百行のリビジョンが蓄積されることがあります。wp-config.phpの「stop editing」行の上に以下を追加してください：

// 投稿ごとに最新の5つのリビジョンのみを保持する
define( 'WP_POST_REVISIONS', 5 );

これにより、今後の肥大化を防ぐことができます。既存のデータをクリーンアップするには、WP-OptimizeやAdvanced Database Cleanerなどのメンテナンスプラグインを使用してください。一括クリーンアップの前には必ずバックアップを取ってください。テーブルが破損している場合、WordPressには組み込みの修復ツールがあります。wp-config.phpにdefine( 'WP_ALLOW_REPAIR', true );を追加し、/wp-admin/maint/repair.phpにアクセスして修復を実行した後、その行を削除してください。

INPを健全に保つ：WordPressのJavaScript管理

LCPはWordPressサイトが最も失敗しやすいCore Web Vitalsの指標です。HTTP Archiveの2024 Web Almanac CMSチャプターによると、すべての3つのCore Web Vitalsを通過するWordPressモバイルサイトは約40%に過ぎず（2023年の28%から増加）、LCPがその数値を押し下げているボトルネック指標です。一方、INPはWordPressが最も得意とする指標であり、約82%のWordPressサイトが良好なスコアを達成しています。したがって、INPは消火すべき火事ではなく、守るべき資産です。ウェブ全体では、2024 Performanceチャプターによると、LCPが最も失敗率の高い指標（モバイルサイトの約59%が良好）であるのに対し、INPははるかに多くのサイトで合格しています。

INPを悪化させるのはJavaScriptです。重いプラグイン、ページビルダーのバンドル、そしてメインスレッドで長いタスクを実行してブラウザのタップやクリックへの応答をブロックするサードパーティタグ（アナリティクス、チャット、同意、広告スクリプト）が原因です。FIDからINPへの移行により、JavaScriptが多いサイトの合格率が測定可能なほど低下しました。INPはFIDが捉えられなかったそのブロッキングを正確に計測するからです。対策はJavaScriptの管理です：

• 重要でないスクリプトを削除または遅延させる。 サードパーティタグを遅延させ、チャット/同意ウィジェットはインタラクション後に読み込むようにしてください。
• プラグイン由来のJavaScriptを削減する。 ここで上述のプラグイン監査が2つ目の効果を発揮します。
• 長いタスクを分割することで、メインスレッドが処理の合間に入力に応答できるようにしてください。web.devのINP最適化ガイドでテクニックを確認できます。

Googleエンジニアが収集した事例研究では、これらの改善が収益に結びついています。Addy Osmaniのまとめには、INPとLCPの改善が測定可能なコンバージョン増加をもたらした事例が紹介されています。INPはインタラクションごとの指標であるため、実ユーザーモニタリングが適切な診断手段です。一度もクリックしないラボテストでは、トラッキングスクリプトが処理中だったために600ミリ秒かかったタップを検出できません。

最新WordPressでの無料の改善：Speculation Rules

最新バージョンのWordPressを使用している場合、無料のパフォーマンス機能が既に利用可能です。WordPress 6.8はSpeculation Rules APIのネイティブサポートを追加しました。これにより、ユーザーがナビゲートする前に内部リンクをプリフェッチし、キャッシュされたページをほぼ瞬時に感じさせます。ページの重量への影響はなく、サポートしていないブラウザへの影響もありません。コアのデフォルト設定はprefetchで控えめな積極性（ユーザーがクリックし始めた時点でトリガー）であり、ログイン済みユーザーとパーマリンクが設定されていないサイトでは無効化されています。開発者ノートによると、この機能を有効にしたサイトでは中央値でLCP合格率が約1.9%改善されました。wp_speculation_rules_href_exclude_pathsフィルターを使用して、状態を変更するURL（カート、アクションリンク）を除外できます。

高度なサーバーとPHPのチューニング（VPSのみ）

このセクションは、自分でサーバーを管理している場合にのみ適用されます。管理型ホスティングや共有ホスティングでは、PHP-FPMワーカー、Redis、NGINXのチューニングはできません。そのため、この部分に時間を費やさず、上記の施策に集中してください。VPS上では、高い効果が期待できる施策は以下のとおりです：

• 最新のPHPを実行する。 最新のPHPリリースはリクエスト処理時間を削減します。PHP 8.5が現在の安定版（8.4は安全なフォールバック）です。WordPressについては、WordPress 7.0時点での最小サポートPHPバージョンは7.4、推奨最小バージョンはPHP 8.3です。PHP 8.5のサポートはWordPress 6.9でベータ版として追加され、WordPressは2026年5月に「ベータサポート」のラベルを廃止しました。そのため、PHP 8.4と8.5はWordPress 7.0で完全にサポートされています。
• OPcacheを有効にすることで、PHPはリクエストのたびに再コンパイルする代わりに、コンパイル済みのバイトコードをキャッシュします。
• PHP-FPMワーカーを利用可能なRAMに合わせてサイジングする。 ワーカーが増えると比例してメモリが必要になるため、過剰にプロビジョニングするとスワッピングが発生し、速度が遅くなります。
• データベースをチューニングし、リバースプロキシキャッシュを追加する（Redisオブジェクトキャッシュ、MariaDBバッファサイジング、NGINX FastCGI/プロキシキャッシュ）。これらは深いトピックです。ワーカーの計算とバッファサイジングについては、InMotionのサーバーチューニングガイドを参照してください。

WordPress自体も最新の状態に保ってください。現在のメジャーバージョンはWordPress 7.0で、2026年5月20日にリリースされました。WordPressは現在年間約3回のメジャーリリースを行っており、WordPress 7.1は2026年8月にリリース予定です。ベンチマークを取る前に最新バージョンであることを確認してください。

明日から始めるべきこと

遅いWordPressサイトから最速で抜け出す方法は、実際のCore Web VitalsとTTFBを計測し、優先順位に従って施策を実施することです。適切なホスティングとページキャッシュを確保し、画像を最適化して適切なサイズにし、メインスレッドをブロックするプラグインとスクリプトを削除し、圧縮機能付きCDNを追加して、データベースをクリーンアップしてください。1回のラボスコアではなく、フィールドデータに対して各変更後に再テストしてください。それが、修正が効果を上げたことを確認する方法と、ただ期待する方法の違いです。PageSpeed Insightsを開き、最も遅いページのフィールドレポートを確認して、表の上から作業を始めてください。

よくある質問

WordPressサイトがLighthouseでは合格しているのに、Search ConsoleのCore Web Vitalsで不合格になるのはなぜですか？

Lighthouseは1つの場所から1つのデバイスと1つのネットワークをシミュレートするラボテストです。一方、Search ConsoleはChrome User Experience Reportのフィールドデータを報告しており、これは75パーセンタイルで直近28日間の実際の訪問者の体験を集計したものです。実際のユーザーはLighthouseのエミュレーションよりも低速なデバイスとネットワークを使用しているため、ラボでグリーンスコアを獲得しながらフィールドの評価では不合格になることは珍しくありません。フィールドデータを常に真実の情報源として扱ってください。

WordPressの適切なTTFBとはどのくらいですか？またLCPとはどう違いますか？

Time to First Byteの実用的な目標値は約800ミリ秒未満で、キャッシュされたページではより低い値が望ましいです。TTFBはサーバーがHTMLの最初のバイトを送信するまでの遅延のみを計測するため、ホスティングの速度、ページキャッシュ、データベースの負荷を反映します。LCPは最大の可視要素がレンダリングを完了するまでの時間を計測し、「良好」な閾値は2.5秒です。TTFBが遅いとLCPが悪化しますが、画像を修正することでTTFBに触れずにLCPを改善することも可能です。

ページが既に完全にページキャッシュされている場合、RedisによるオブジェクトキャッシュはSEOに役立ちますか？

完全にページキャッシュされたページにはほとんど効果がありません。ページキャッシュは既にデータベースクエリを実行せずに事前構築されたHTMLを提供しているからです。オブジェクトキャッシュは繰り返しのクエリ結果をメモリに保存し、主に完全にページキャッシュできない動的なページ、ログイン済みユーザー向けのページ、またはWooCommerceのページに効果があります。また、RedisまたはMemcachedサービスが必要なため、通常はそれを提供している管理型プランか、自分で管理するVPS上でのみ利用可能です。まずページキャッシュを有効にし、キャッシュできないトラフィックが相当数ある場合にのみオブジェクトキャッシュを追加してください。

プラグインの数を減らすことがWordPressの速度を改善する最善の方法ですか？

いいえ。重要なのはプラグインの数ではなく、プラグインのコストです。よく作られたキャッシュプラグイン1つはパフォーマンスを向上させますが、すべてのページでCSSとJavaScriptを読み込む粗悪なプラグイン1つはすべてのページに悪影響を与えます。Query Monitorを使用して遅いクエリを特定のプラグインに帰属させ、プロファイリングツールを使用して読み込み時間を特定のプラグインに帰属させ、最も重いプラグインを削除してください。インタラクションをブロックしていたメインスレッドのJavaScriptが除去されるため、重いプラグインを1つ無効化するだけで、数十の細かい最適化よりも実際の応答性が改善されることがよくあります。