まず切り分ける — 「サーバーが遅い」のか「WordPressが遅い」のかを最初に見分ける
WordPressが重いと感じたら、まず原因を切り分けます。ブラウザの開発者ツールでTTFB(サーバーが最初の1バイトを返すまでの時間)を確認し、ここが遅ければサーバー側、TTFBは速いのに表示が遅ければ画像やJavaScriptなどフロント側、と方向が決まります。
いきなりキャッシュプラグインを入れるのは、この切り分けを飛ばした遠回りにすぎません。
ブラウザのNetworkタブでTTFBを見る:ここが遅ければ原因はサーバー側
Chromeなら F12 →「Network」タブでページを再読み込みし、一番上のドキュメント行の「Waiting(TTFB)」を見ます。ここに数秒かかるならPHPやデータベースの処理が遅い証拠で、画像圧縮やCDNをいくら足しても効きません。逆にTTFBが速く描画だけ遅いなら、プラグインの切り分けは飛ばして画像とスクリプトの最適化へ進みます。
プラグイン全停止・デフォルトテーマ切り替えで犯人を数分で特定する
TTFBが遅いと分かったら、プラグインを全停止し、WordPress標準のテーマに切り替えて再計測します。これで速くなれば犯人はプラグインかテーマ。あとは一つずつ有効化し、二分探索の要領でどれが原因かを絞ります。本番で止めづらければ、検証環境で同じ操作を行ってください。
原因別の改善策を、手間の軽い順に試す
方向が見えたら、コストの低い施策から当てます。設定変更で済むものを先に、コードやDBに触るものを後に回すのが鉄則です。
キャッシュ・PHPバージョン・不要プラグインという低コストな一手
まずPHPのバージョン。7系のまま動いているサイトは珍しくなく、8.1以降といった新しいバージョンへ上げることでTTFBが縮む場合があります。次にページキャッシュ(生成済みHTMLを再利用する仕組み)の導入、そして使っていないプラグインの削除です。停止ではなく削除まで行うのは、停止中でも一部の処理やデータが残るプラグインがある可能性を考慮してのことです。
遅いクエリとwp_optionsのautoload肥大 — 表示速度を蝕む見落としがちな要因
設定変更で足りないときに疑うのが、全リクエストで読み込まれる自動読み込みデータの肥大です。wp_optionsテーブルのautoload指定が膨らむと、ページを開くたびに読み込むデータが増え、全体が遅くなる要因になり得ます。停止済みプラグインが残した設定値が原因になっていることもあるため、Query Monitorなどのツールで遅いクエリと重い読み込みを可視化し、不要な行を特定して削除します。
改善したつもりで再発させないための、効果測定と運用上の注意
施策は「一つ変えるごとに再計測」が原則です。まとめて変えると、何が効いて何が逆効果だったのか分からなくなります。判断は体感ではなくTTFBの数値で行ってください。
忘れやすいのがキャッシュ導入後の検証です。キャッシュが効いた状態では速く見えて当然なので、シークレットウィンドウや未ログイン状態でも計測し、初回訪問者の体感を確認します。プラグイン更新のたびにautoloadが再び膨らむこともあるため、四半期に一度は同じ手順を回せば、遅さが積み上がる前に気づけます。
カスタマイズに関するお問い合わせはこちら
本記事のコード・挙動に関する記述は、WordPress 7.0.2 の実際のソースコードと照合して確認しています。
EC-CUBEゴールドパートナー
WordPress構築・保守