WordPress 表示が重い｜サーバー側でできる高速化

本記事にはプロモーション（PR）が含まれます。

記事を積み上げて画像も増やしてきたWordPressサイトが、ある時期から管理画面の操作も表示ももたつくようになる。契約したばかりで乗り換えるほどではないし、テーマやプラグインを消して回るのも怖い。この記事は、そういう「もう契約は済んでいて、今のサーバーのまま速くしたい」人に向けたものです。どのサーバーが速いかを実測で比べたい場合は個人向け3社の3年総額を比べた記事を先に読んでください。

結論から言うと、今のサーバーのまま速くする順番は決まっています。まず「どこが遅いか」を切り分け、次に契約中のサーバーに最初から備わっているキャッシュ（一度作ったページを一時保存し、次のアクセスに使い回す仕組み）機能を使い、その上でプラグインと二重に掛けないよう整理し、最後に画像とPHP（WordPressを動かすプログラミング言語）を見直す。高速化プラグインを追加でインストールするのは、この順番の最後です。サーバー側の機能を使い切る前にプラグインを足すと、次に説明する「二重掛け」で逆に重くなることがあります。

まず切り分ける｜サーバー側が遅いのか、WordPress側が重いのか
高速化の中心はサーバー側のキャッシュ｜プラグインより先に使う
キャッシュの「保存期間」をどう決めるか
核心｜サーバーキャッシュとプラグインの二重掛けを避ける
残りの一手｜画像とPHPバージョン
判断フロー｜何から手を付けるか
よくある質問
参考・出典

まず切り分ける｜サーバー側が遅いのか、WordPress側が重いのか

開発者がサーバーらしき機器とノートPCを見比べ考慮する様子 — どちらが原因か、慎重に見極める様子（イメージ）

「wordpress 遅い」と感じても、原因は大きく2つに分かれます。1つはサーバーが最初の応答を返すまでが遅いケース、もう1つはブラウザに届いた後の描画（画像やスクリプトの読み込み）が重いケースです。この切り分けをせずにプラグインを足すと、効かない場所に手を入れることになります。

目安になるのがTTFB（Time To First Byte＝ブラウザが最初の1バイトを受け取るまでの時間）です。TTFBが大きいときはサーバー側やWordPressの処理が原因、TTFBは小さいのに表示完了が遅いときは画像やスクリプトなど「届いた後」が原因、と当たりを付けられます。TTFBの測り方や無料お試し中の計測は速度比較の記事で扱っているため、ここでは切り分けの入口としてだけ触れます。本記事が中心に扱うのは、TTFBが大きい側、つまりサーバー側で効く手当てです。

高速化の中心はサーバー側のキャッシュ｜プラグインより先に使う

共用サーバーの多くは、管理画面から使えるサーバー側キャッシュ機能を標準で持っています。WordPressはアクセスのたびにPHPを実行してデータベースからページを組み立てるため、ここで生成済みのページをサーバーに保存しておくと、2回目以降の表示が軽くなります。プラグインで同じことをするより、サーバーの機能で処理する方が土台に近い分だけ素直に効きます。

各社が用意する機能の名前と設定場所は次のとおりです。エックスサーバーとConoHa WINGはコントロールパネル内にサーバーキャッシュの項目があります。ロリポップのハイスピードプランは高速なWebサーバーソフトであるLiteSpeedを採用しており、後述するLiteSpeed専用のキャッシュと相性が良い構成です。さくらのレンタルサーバはCDN（Content Delivery Network＝各地のサーバーから配信を肩代わりする仕組み）である「コンテンツブースト」をスタンダードで月100GBまで無料、ビジネスで月300GBまで無料で使えます（いずれも2026年9月時点・公式サイト確認）。

キャッシュの「保存期間」をどう決めるか

電気的な青い光を放つタブレット画面に手をかざす様子 — 設定の調整を検討する（イメージ）

「キャッシュ保存期間」で迷うのは、長くすると速くなる一方で、更新がすぐ反映されなくなるからです。保存期間とは、一度保存したページを何時間（何分）そのまま使い回すかの設定で、この期間内はサイトを直しても訪問者には古いページが表示され続けます。

目安の考え方はサイトの更新頻度で分けると整理できます。

ほぼ更新しない紹介サイトやコーポレートサイト: 保存期間は長めでよく、表示速度を優先できます。
週に数本の記事を出すブログ: 中程度にし、記事公開のたびに手動でキャッシュを消す運用にすると、速さと反映のバランスが取れます。
価格やお知らせを頻繁に直すサイト: 保存期間は短め、または該当ページだけキャッシュ対象から外します。

迷ったときは、まずサーバーの初期設定のまま使い、更新が反映されない不便が出たら期間を短くする、という後追いで十分です。各社の初期の保存期間は公式の機能ページで確認してください。

核心｜サーバーキャッシュとプラグインの二重掛けを避ける

ここが本記事でいちばん伝えたい点です。サーバー側でキャッシュを効かせているのに、WordPressにもページキャッシュ系のプラグイン（WP Super Cacheなどページ全体を保存するタイプ）を入れて有効化すると、同じ仕事を2つの層が別々に行うことになります。これがいわゆる二重掛けで、更新が二重に保存されて古い表示が消えにくくなったり、レイアウトが崩れたり、かえって表示が遅くなる原因になります。

切り分けの原則はシンプルです。

サーバー側のキャッシュ機能を使うなら、WordPress側のページキャッシュ系プラグインは有効化しない（1つの役割は1か所に任せる）。
ロリポップハイスピードのようにLiteSpeedを使うサーバーでは、LiteSpeed専用のキャッシュプラグイン（LiteSpeed Cache）が例外的に相性が良く、これはサーバーと連携して動くため単独で使う前提です。この場合も他のページキャッシュ系プラグインは重ねません。
画像の遅延読み込みやファイル圧縮など、ページキャッシュとは役割が違う機能だけをプラグインで補う。

すでに複数の高速化プラグインを入れている場合は、一度すべて停止し、サーバー側キャッシュだけの状態で表示を確認してから、足りない役割を1つずつ戻すと原因を特定しやすくなります。

残りの一手｜画像とPHPバージョン

サーバー側の手当てをした後で効くのが、画像とPHPの見直しです。表示が重いサイトの多くは、撮ったままの大きな画像をそのまま貼っています。表示する枠より大きな画像はサイズを縮小し、次世代フォーマット（WebPなど、軽く保存できる画像形式）に変換するだけで、届いた後の描画が軽くなります。この役割はキャッシュと競合しないため、プラグインで補って問題ありません。

もう1つがPHPのバージョンです。古いPHPのまま動かしていると、新しいバージョンより処理が遅いことがあります。上げると表示が速くなる一方で、テーマやプラグインが対応していないと不具合が出るため、上げる前の確認は別記事に譲ります。多くのサーバーはコントロールパネルからバージョンを切り替えられます。多くの環境ではNVMe SSD（高速な記録装置）が使われており、記録装置そのものが遅いことは近年では少なくなっています。