WordPressが遅い・重い原因の切り分け方｜プラグイン・サーバー・DBの改善策

はじめに

「WordPressのサイトが遅い」という問題は、Web担当者が最もよく直面する課題の一つです。最適化なしのWordPressサイトのPageSpeed InsightsモバイルスコアはしばしP30〜50台になり、Core Web Vitalsはほぼすべてのページで「要改善」または「不良」になることが多いです。

本記事では、WordPressが遅い主な原因を体系的に整理し、各原因に対する具体的な改善策を解説します。

WordPressが構造的に遅い理由

まず理解しておくべきことは、WordPressには「構造的な速度の限界」があるという事実です。

WordPressはPHP（サーバーサイドのプログラミング言語）でデータベース（MySQL）からコンテンツを取得し、アクセスのたびにHTMLを動的に生成します。このプロセスが毎回発生するため、すでに生成済みのHTMLを返す静的配信と比べて、必然的にTTFBが長くなります。

プラグインを30個以上インストールしていたり、共有レンタルサーバーを使っていたりする場合、TTFB 2〜3秒という状況も珍しくません。

「WordPressで十分なパフォーマンスを出すために高速化施策が必要」という現実と、「Next.js＋Vercelのような静的配信ベースのアーキテクチャには構造的に及ばない」という事実の両方を理解した上で、適切な判断をすることが重要です。

WordPressが遅い原因を切り分ける手順

WordPressが遅いという症状には複数の原因が重なっていることが多く、思いついた施策から手を付けると、効果が出たのかどうかすら判断できなくなります。改善に着手する前に、どの層がボトルネックになっているのかを切り分けておくと、後続の施策の優先順位が決まります。

切り分けは上流から下流へ順に見ていきます。第一に、現状を数値として記録します。トップページと、実際に流入の多い下層ページの両方を計測し、改善前の値を残しておきます。ページによって重さの原因が異なるケースは珍しくないため、1ページだけの計測で判断しないことが重要です。

第二に、サーバーが応答を返すまでの時間（TTFB）と、ブラウザが受け取ってから描画するまでの時間を分けて見ます。本記事の後半でも触れるとおり、TTFBが2〜3秒かかっている場合はサーバー側またはPHP・データベース側の問題が中心であり、画像やCSSをいくら最適化しても体感は変わりません。逆にTTFBが短いのに表示が遅いのであれば、原因はフロントエンド側にあります。

第三に、サーバー側が疑わしい場合は、プラグイン・テーマ・データベースのどれが重いのかを分解します。本番環境をそのままいじるのではなく、ステージング環境を複製したうえで、プラグインを一つずつ無効化して応答時間の変化を見るのが一般的です。特定のプラグインを外した瞬間に大きく改善するなら、そのプラグインが主要因と判断できます。

この切り分けを最初に済ませておくと、次章の原因別の改善策のうち、自社が着手すべきものだけを選べるようになります。

• ステップ1：トップページと主要な下層ページの現状値を計測し、改善前の数値として記録する

• ステップ2：サーバーの応答時間（TTFB）と描画時間を分け、原因がサーバー側かフロントエンド側かを判定する

• ステップ3：サーバー側ならステージング環境でプラグインを個別に無効化し、影響の大きいものを特定する

• ステップ4：フロントエンド側なら、画像・CSS・JavaScriptのどれが描画を止めているかを計測結果から確認する

• ステップ5：管理画面だけが重い場合は、データベースの肥大化を疑い、投稿数・リビジョン数を確認する

WordPressが遅い主な原因と改善策

原因1：過剰なプラグイン

WordPressの速度低下で最も多い原因の一つが、必要以上に多くのプラグインのインストールです。各プラグインは独自のCSS・JavaScriptをすべてのページに読み込み、データベースクエリを追加する場合もあります。

確認方法：Query Monitorプラグインをインストールして、ページ読み込み時のデータベースクエリ数・実行時間・読み込まれているスクリプト/スタイルを確認します。

改善策

• 使っていないプラグインを削除する（「あとで使うかも」でインストールしたままのプラグインを整理）

• 複数のプラグインで実現していた機能を1つのプラグインで代替できるか検討します

• フロントエンドにCSSやJSを読み込む必要がないプラグインの出力を制限します

原因2：最適化されていない画像

WordPressはデフォルトでは画像の最適化を行わません。Web担当者がそのままアップロードした高解像度のJPEG・PNG画像が圧縮なしで配信されていることが多いです。

改善策

• 画像最適化プラグイン（Imagify・ShortPixel等）を導入してWebP変換・圧縮を自動化します

• WordPress標準の遅延読み込み機能（WordPress 5.5以降の標準機能）を確認します

• Cloudflareの画像最適化機能を活用します

原因3：低性能なホスティング環境

共有レンタルサーバー（複数のサイトがサーバーリソースを共有する環境）は、他のサイトのトラフィックによって自サイトのパフォーマンスが影響を受ける。

確認方法：PageSpeed InsightsでTTFBが600ミリ秒以上の場合、ホスティング環境が原因の可能性が高いです。

改善策

• WordPressに最適化されたマネージドWordPressホスティングへの移行（Kinsta・SiteGroundのCloud Hosting等）

• VPS・専用サーバーへの移行

• CDN（Cloudflare等）の導入でオリジンサーバーへの負荷を削減

原因4：キャッシュの未設定

WordPressはデフォルトではページキャッシュを持たません。すべてのアクセスでPHPが処理を行います。

改善策：キャッシュプラグインを導入してページキャッシュを有効化します。

主要なキャッシュプラグイン

WP Rocket（有料：年間約$59〜）

最も人気のある高機能なWordPressキャッシュプラグイン。ページキャッシュ・ブラウザキャッシュ・CSS/JSの圧縮・遅延読み込み・データベース最適化などを一括で設定できます。設定が比較的簡単で、幅広いユーザーに推奨されます。

W3 Total Cache（無料・有料プランあり）

高度なカスタマイズが可能ですが、設定の複雑さがあります。エンジニアが管理する場合に適しています。

LiteSpeed Cache（無料）

LiteSpeedサーバーを使用している場合に特に効果的。Cloudflareとの連携も充実しています。

原因5：レンダリングをブロックするCSS・JS

WordPressのテーマやプラグインが多数のCSS・JavaScriptを <head> タグ内に読み込み、これがページのレンダリングをブロックします。

改善策

• キャッシュプラグイン（WP Rocket等）のCSS・JSの結合・ミニファイ・遅延読み込み機能を活用します

• 不要なCSS・JSを読み込んでいるプラグインを特定し、不要なプラグインを削除します

• Autoptimize プラグインでCSS・JSの最適化を追加します

原因6：データベースの肥大化

WordPress はアップデート・ページ編集・プラグインのデータ等を蓄積するうちにデータベースが肥大化し、クエリの実行速度が低下することがあります。

改善策

• 古いリビジョン（記事の自動保存履歴）を削除します

• wp_options テーブルの肥大化（不要なプラグインデータが蓄積）を解消します

• WP-Optimize等のプラグインでデータベースの最適化を定期的に実行します

WordPressの速度低下には様々な原因があります。サイト表示速度について詳しくは「サイト表示速度とは（UXとSEOへの影響）」で解説しています。

WordPressの高速化施策の実施順序

限られたリソースで最大の効果を得るための優先順位を示す。

最優先（即着手・効果大）

• 使用していないプラグインの削除

• キャッシュプラグイン（WP Rocket等）の導入

• 画像最適化プラグインの導入とWebP変換

高優先（1〜2ヶ月以内）

• CDN（Cloudflare等）の導入

• ホスティング環境の見直し（共有→マネージドWordPress等）

• CSS・JSの最小化・遅延読み込みの設定

中優先（3〜6ヶ月以内）

• テーマの見直し（重いテーマ→軽量なテーマへ）

• データベースの最適化

現実的な期待値

WordPressの高速化施策を積み重ねることで、PageSpeed InsightsのモバイルスコアをどこまGoodに引き上げられるかの現実的な期待値を示す。

一方、Next.js＋Vercelの構成は最適化のベースラインが85〜95台であることと比較すると、構造的な差は縮まりにくい。

「WordPressの高速化」vs「技術スタックの移行」の判断基準

WordPressの高速化施策で限界を感じた場合、Next.js＋ヘッドレスCMSへの移行を検討する価値があります。

高速化施策で対応すべきケース

• 現時点でのPageSpeed Insightsスコアが60〜70台（まだ施策の余地がある）

• 移行コストよりも継続改善のコストが低い

• WordPressに強い依存がある（大量のプラグイン・カスタマイズ）

技術スタック移行を検討すべきケース

• 最適化済みでもスコアが70未満（構造的な限界に達している）

• AI連携のような高度な機能の統合を計画している

• 長期的なパフォーマンス維持・技術的負債の削減を優先したい

切り分け結果を制作会社に伝えるときの整理のしかた

高速化を外部に依頼する場合、「サイトが遅いので速くしてほしい」という伝え方では、制作会社側が最初に行うのは結局のところ現状調査です。自社で切り分けまで済ませておくと、見積もりの前提が揃い、提案の精度も上がります。

伝えるべき情報は多くありません。遅いと感じている具体的なページのURL、計測した数値と計測日、そしてサーバー環境とWordPressの構成（ホスティングの種類、テーマが既製品か独自実装か、稼働中のプラグイン一覧）です。トップページなのか記事詳細なのかで原因も打ち手も変わるため、ページ単位で示すのが有効です。

加えて、「来期のリニューアルまでは現行のまま延命したい」のか「今回で根本的に解決したい」のかを共有できると、認識のずれが減ります。前者ならキャッシュとホスティングの見直しが中心になり、後者では構成そのものの見直しが検討対象に入ります。

なお、切り分けの結果としてPHPとデータベースによる動的生成そのものがボトルネックだった場合は、WordPressを管理画面として残したままフロントエンドを分離する構成も選択肢になります。判断の前提として、ヘッドレスCMSとは｜従来CMSとの違い・メリット・デメリットで仕組みと向き不向きを確認しておくと、提案を受けたときに比較しやすくなります。ただし、どの構成が適切かはサイト規模・更新頻度・社内の運用体制によって変わるため、ケースによる判断になります。

• 遅いと感じているページのURL（複数ある場合はすべて）

• 計測した数値と計測日（改善効果を検証するための基準値）

• ホスティングの契約種別とサーバースペック

• テーマが既製品か独自実装か、カスタマイズの有無

• 稼働中のプラグイン一覧と、切り分けで影響が大きかったもの

• 現行サイトをいつまで使う想定か（延命か、根本解決か）

まとめ

WordPressが遅い主な原因は「過剰なプラグイン・未最適化の画像・低性能なホスティング・キャッシュ未設定・レンダリングブロック・データベース肥大化」の6つです。

これらを体系的に改善することで一定のパフォーマンス向上は実現できますが、Next.js＋Vercelのような静的配信ベースのアーキテクチャとの構造的な差は、施策によって完全には埋まらない点を認識した上で判断することが重要です。

次の記事では、表示速度改善プロジェクトの進め方——診断から施策実装・効果測定までの全体プロセスを解説します。