キャッシュプラグインを導入し、推奨設定を適用し、画像も最適化した。それでもサイトが速くならない。あるいは、普段は問題ないのに特定の場面でだけ極端に遅くなる ── この状態に心当たりがあるなら、原因はプラグインの設定ではなく、サーバ構成側にある可能性があります。
キャッシュ設定そのものの手順は別の記事で解説しています。本記事はその続きとして、キャッシュプラグインで解決できる問題と、できない問題の境界線をどう見分けるかを扱います。
WordPress のキャッシュ設定完全ガイド｜速度改善の基本と実践方法
目次
キャッシュプラグインが速くしているのは、どこか
前提を確認します。ページキャッシュ系のプラグインがやっているのは、PHP が生成した HTML を保存し、次回以降の同じリクエストにはその保存済み HTML を返すことです。PHP の実行とデータベースへの問い合わせを丸ごとスキップするため速くなる、という仕組みです。
この仕組みから、キャッシュが効かない領域が論理的に導けます。
- 管理画面(wp-admin)：キャッシュ対象外。アクセスのたびに PHP が実行されます
- ログイン中のユーザーへの表示：ユーザーごとに表示が変わるため、通常はキャッシュから除外されます
- フォーム送信などの POST リクエスト：キャッシュできません
- キャッシュが生成されていないコンテンツへの初回アクセス：PHP が実行されます
- 検索結果や絞り込み結果：URL のパターンが多様なため、キャッシュヒット率が構造的に低くなります
つまり、遅さを感じている場面がこれらに該当する場合、キャッシュプラグインをどう設定しても改善しません。速度問題の切り分けは、「遅いのはキャッシュが効く領域か、効かない領域か」の判定から始まります。
まず測る：キャッシュが実際に効いているかを確認する
設定したつもりで効いていない、というケースは珍しくありません。推測で対策を重ねる前に、事実を確認します。
レスポンスヘッダを見る
キャッシュプラグインや CDN は、キャッシュのヒット・ミスをレスポンスヘッダに記録することが多くあります。ターミナルから確認できます。
curl -sSI https://example.com/ | grep -i -E 'x-cache|cf-cache-status|age|x-litespeed-cache'ヒットを示す値が返っていれば、そのページではキャッシュが機能しています。何も返らない、あるいは MISS が続く場合は、キャッシュの設定側に問題があります。この段階ならサーバ構成の話ではなく、プラグイン設定の見直しが先です。
TTFB を測る
TTFB（Time To First Byte）は、リクエストを送ってから最初の1バイトが返るまでの時間です。サーバ側の処理時間を反映する指標なので、フロントエンドの最適化とサーバ性能の切り分けに使えます。
curl -o /dev/null -sS -w 'TTFB: %{time_starttransfer}s\n' https://example.com/一般的な目安として、web.dev などで示されている基準では TTFB は800ミリ秒以下が良好とされ、1.8秒を超えると改善対象という区分が使われています。ただし絶対値よりも重要なのは比較です。次の3つを測り比べてください。
- キャッシュがヒットするトップページ
- キャッシュを除外した状態のページ(またはログイン中のアクセス)
- 管理画面(/wp-admin/)
キャッシュヒット時は速く、キャッシュが効かない場面だけが遅い場合は、PHP・データベース・サーバ性能のいずれかがボトルネックです。逆に、キャッシュがヒットしているページでも TTFB が遅い場合は、静的な HTML を返すだけの処理が遅いということであり、サーバやネットワークの基盤性能を疑う段階になります。
症状別に見る、サーバ構成側を疑うべきケース
症状1：管理画面だけが遅い
前述の通り管理画面はキャッシュされないため、ここが遅い場合はキャッシュプラグインの担当範囲外です。ただし原因は WordPress 側とサーバ側の両方にあり得るので、順に切り分けます。
先に WordPress 側を確認します。 管理画面の遅さで頻出するのは、autoload されるオプションの肥大化です。WordPress は毎回のリクエストで autoload が有効なオプションをまとめて読み込むため、ここに大量のデータが蓄積していると全体が遅くなります。WP-CLI が使える環境なら確認できます。
wp option list --autoload=on --fields=option_name,size_bytes --format=csv | sort -t, -k2 -rn | head -20数百 KB から MB 単位のデータが autoload に入っている場合、それが原因である可能性が高く、これはサーバを変えても解決しません。プラグインの残骸やトランジェントの蓄積が典型です。あわせて Query Monitor などのプラグインで、実行されているクエリ数と遅いクエリを確認します。
WordPress 側に明確な問題がないのに遅い場合、サーバ側の処理性能が疑われます。管理画面の操作は PHP の実行とデータベースアクセスの繰り返しなので、CPU 性能とディスク I/O が素直に反映されます。共用サーバでは、これらのリソースを同じ物理サーバの他の利用者と分け合っているため、自社の WordPress に問題がなくても処理が遅くなることがあります。
症状2：アクセスが集中したときだけ落ちる、または極端に遅くなる
メール配信の直後、プレスリリースの公開後、テレビや SNS で紹介された直後 ── 普段は問題ないのに、アクセスが増えた瞬間だけサイトが応答しなくなるパターンです。
キャッシュが効いていればこの症状は大幅に軽減されますが、それでも起きる場合は同時処理能力の上限に達しています。具体的には、PHP を実行できるプロセス数の上限、データベースへの同時接続数の上限、あるいはサーバ全体の帯域やメモリです。共用サーバではこれらに契約単位の制限が設けられており、上限に達したリクエストは待たされるか、エラーになります。
これはキャッシュの設定では解決できません。処理能力そのものを増やすか、そもそも PHP を実行しない構成にするか、という選択になります。
症状3：キャッシュヒットしているページでも TTFB が遅い
前述の計測で判明するケースです。保存済みの HTML を返すだけの処理に時間がかかっているということは、PHP でもデータベースでもなく、その下の層が遅いということです。考えられる要因は、サーバのディスク I/O 性能、ネットワーク経路、あるいは同一サーバ上の他の利用者による負荷です。
CDN を導入すれば配信経路は改善できますが、オリジンサーバ自体の応答が遅い状態は残ります。
症状4：特定の時間帯にだけ遅くなる
毎日同じ時間帯、あるいは特定の曜日にだけ遅い場合、自社サイトのアクセスパターンと相関しているかを確認します。相関していない場合、同じ物理サーバに同居している他の利用者の負荷、またはサーバ会社側のバックアップ処理などの定期タスクが影響している可能性があります。
自社サイトのアクセスログと突き合わせて、自社のトラフィックが増えていないタイミングで遅くなっているなら、自社の努力では改善できない領域です。
なぜ共用サーバでは、この種の問題が起きるのか
ここまでの症状のうち、複数が共通して指しているのはリソースを他の利用者と共有していることです。
レンタルサーバーは、1台の物理サーバを多数の契約者で共用するマルチテナント構成です。各社ともリソース制御の仕組みを実装しているため「必ず影響を受ける」わけではありませんが、CPU、ディスク I/O、メモリといった資源に上限があり、それを分け合っている構造そのものは変わりません。だからこそ、自社サイトのチューニングを尽くしても超えられない天井が存在します。
対して、AWS などのクラウド上に自社専用の環境を構築するシングルテナント(専有)構成では、割り当てられたリソースが自社サイトのために確保されます。他の利用者の負荷に左右されず、必要に応じてリソースを増やす判断も自社で下せます。マネージドホスティングの月額料金がレンタルサーバーより高い理由の相当部分は、この構成差にあります。
選択肢は2つに分かれる
サーバ構成側に原因があると判断できた場合、方向性は2つです。
専有構成のマネージドホスティングへ移行する（動的維持）
WordPress を動的に稼働させたまま、リソースを専有する構成に移す方向です。会員機能、リアルタイムの在庫連動、パーソナライズなど、リクエストごとの動的処理が必要なサイトはこちらになります。管理画面の速度、アクセス集中時の耐性、TTFB の安定性はいずれも構成の変更によって改善が期待できます。
静的化して、PHP を実行しない構成にする（静的配信）
サイトを事前に静的な HTML として生成し、配信のみを行う方向です。リクエスト時に PHP もデータベースも動かないため、アクセス集中による処理能力の上限という問題が構造的に消えます。ただし前述の動的処理が必要なサイトには適用できません。コーポレートサイト、製品サイト、メディアサイトのように「更新はするがその頻度は高くなく、また、閲覧者ごとの出し分けはしない」サイトであれば、速度問題の根本的な解決になります。
どちらを選ぶかは、速度の問題だけでなく、サイトが必要とする機能によって決まります。移行に踏み込む前に、人件費を含めた総コストで比較しておくと判断しやすくなります。
レンタルサーバー継続 vs Amimoto vs Shifter ── 人件費を含めた3年総コスト比較
まとめ
キャッシュプラグインを導入している環境での速度改善は、プラグインの設定から始めるのが正しい順序です。ただし、その手を尽くしても改善しない領域が存在します。管理画面の遅さ、アクセス集中時の停止、キャッシュヒット時の TTFB の遅さ ── これらはキャッシュプラグインの担当範囲外であり、サーバ構成側に原因があることを示すサインです。
大切なのは、推測ではなく計測で切り分けることです。キャッシュが実際に効いているかをレスポンスヘッダで確認し、TTFB をキャッシュヒット時・非ヒット時・管理画面の3点で比較する。autoload されたオプションのサイズを確認する。この手順を踏めば、対処すべき層がどこかは判定できます。
計測してみて「サーバ構成側に原因がありそうだが、動的維持と静的化のどちらが適しているか判断がつかない」という段階になったら、LabWorks へご相談ください。サイトの構成と要件を確認したうえで、Amimoto（専有マネージド）と Shifter（静的化）のどちらが現実的かを一緒に整理できます。
関連リンク
当社へご興味をお持ちいただきありがとうございます。
「こんなことやってみたい！」と、ぜひ気軽にご相談ください。
担当者よりご連絡差し上げます。