最高記録をどんどん更新
ブログが重い！と焦りだして、数日経過し、記事にしてから1日経ちましたが、結局ブログは重いままです。
PageSpeed Insightsで時間測定をしたら、サーバの応答時間が6秒と過去記録を更新！
これはもうどうしたもんか…と悩んでおりました。
そこで、レンタルサーバのリソース情報を見たときに、たまたまアクセスが入っている時にぶち当たり、アクセスが入ったときのプロセス起動状況を見ることができました。
そこで気になったのが、wp-cron.phpというプロセス。
wp-cron.phpとは
wp-cron.phpはWordpressのファイルのことで、アクセスが入ったタイミングで、wp-cron.phpが呼び出されてそこに登録されている処理をしています。
ここに登録されている処理とは、予約投稿であったり、DBのバックアップであったりと、本来であればタスクスケジューラのようなものが起動させている処理を、疑似タスクスケジューラとしてwp-cron.phpが呼び出していることらしいです。
最初は、こいつがCPUのリソースを奪い、共有サーバを重くしているのでは無いか、と疑い、いろいろしらべてみました。
そして、自分のwp-cron.phpがどんな処理をしているのかチェックするプラグインがあるので、それを入れてみたのですが、自分のwp-cron.phpでは特にアクセス毎に重い処理は行われていない模様。
ということは、wp-cron.phpが原因とも考えにくい…
調べ物は暗礁に…と思いきや
wp-cron.php原因説も半ば否定され、途方に暮れたので、とりあえずレンタルサーバの運営会社に状況を詳しく報告したメールを出すことに。
もちろん共有サーバの不具合を疑っているわけでは無く、こちらで何かしら対処することができるかどうかのお伺いを立てるメールを、それなりの感じで書いたわけです。
そのメールについては返答待ちですが、その間に、もう一度wp-cron.phpについて調べることにしました。
するとwp-cron.phpとは違う方向性の情報がみつかりました。
サーバのリソースによっては、W3 Total Cacheがサーバのリソースを逼迫させ、逆に速度が落ちるというもの。
そこで、プラグイン一覧を見てみると、あった「W3 Total Cache」がうちのWordpressでも使われてた。
すかさず、W3 Total Cacheを削除し、いろいろ設定を書き換え、「Quick Cache」という比較的穏やかなキャッシュプラグインを導入してみました…
するとどうでしょう
PageSpeed Insightsのサーバ応答時間が1秒以下に…
でもたまーに対処する前もサーバの応答時間が短くなることがあったので、まだまだ気が抜けません。
ただ、全体的にレスポンスが向上しており、今まで悩まされていた、管理画面の動作もめちゃくちゃ速くなっているので、もしかするともしかすると「W3 Total Cache」が原因だったのかもしれません。
というわけで当面様子見です。
まとめ
「W3 Total Cache」を使用されている方で、導入当初は速度が上がっていても、使い続けているうちにブログが重くなってしまった方は、いちどキャッシュ系のプラグインを見直してみるのが良いかもしれません…
