最近、ある海外サーバーで運営しているWordpressサイトが日に日に重くなってきてるなと感じてました。特にアクセス数が多いわけではないのに、ページがなかなか表示されない。
ページが表示されないと離脱率がーという話もありますし、サーバーを引っ越すか、同一サーバー会社で料金プランを上げるか悩んでいました。
サーバーだけの引っ越しなら簡単なのですが、そのドメインはメールも紐づいており、メールアカウントも同時に引っ越さないといけないのが結構めんどい、かといってプランを上げても速くなる保証はない。
最近まで使っていたWordpressテーマLuxeritasでは、キャッシュ系プラグインは非推奨だったこともあって、今まで使ったことがなかったのですが、キャッシュ系プラグインを導入したらモッサリ感があっさり解決したのでシェアします。
モッサリ感がある理由は？
検証ツールで、TOPページ表示のどこに時間がかかっているのか調べたら、TTFBが支配的でした。
TTFBとは「Time To First Byte」の頭文字をつなげた言葉で、「最初の1バイトが到着するまでの時間」を表します。
この「最初の1バイト」とは、Webサーバーにリクエストを行なった際に「サーバーから初めて返ってきた1バイト」のことを意味しています。
つまりサーバーがリクエストを受け取ってからデータを返し始めるまでの時間を計測することができる指標ということになります。
TTFBはWordpressがphpファイルからHTMLを吐き出すまでの時間だと思います。その時間はユーザーにとっては純粋な待ち時間になってしまいます。
その部分を静的HTMLに置き換えられたらTTFBは短縮できるはずでは？と考えました。
キャッシュ系プラグインはどれを使えばよい？
キャッシュ系プラグインで有名なのは、以下の2つだと思います。
どちらも人気もあり、性能もよいと評判です。
特に、WP Super Cacheは静的HTMLを吐き出すことができるので探していたものです。しかし、次のような評判を目にしました。
- 機能が複雑なため設定項目が多くて取っつきにくい
- プラグイン自体が重い
- 相性・競合問題などもあり
- サイトが真っ白くなり表示できなくなった、アンインストールしても完全に消えない
たどり着いたのはcache-enablerというプラグイン
別のおススメはないのか？ということで今回、使ったのはcache-enablerというプラグインです。
日本語で紹介しているサイトは殆どないで、聞いたことある人は少ないのではないかと思います。
あらためて見てみると、Luxeritasの作者さんもcache-enablerをおススメとして紹介していました。さすがです。
このプラグインの良いところは、機能がシンプルで、軽いことです。
そして、Wordpressの動的サイトを静的HTMLに置き換えてくれることです。
そうすることで、ページが表示されるまでの時間（TTFB）が短縮されます。
cache-enablerには、HTMLやJSの圧縮機能もありますが、Autoptimizeと併用している場合は、cache-enabler側からメッセージが出てAutoptimizeと競合しないように設定を教えてくれるなど、Autoptimizeと併用できるようにプラグインが開発されています。
結局、cache-enablerでページ表示は速くなったの？
cache-enableを導入したら、まず体感速度は明らかに速くなりました。TTFBがほぼ0になったので、ページが表示され始めるまでの時間がそのまま短縮されたのだともいます。
cache-enablerはnginxだと有効にならない場合もある
いろんなサイトでcache-enablerを導入してテストしましたが、Apache系は問題ないのですが、nginxサーバーの場合はイマイチ効果があるのかわかりませんでした。
というのもレスポンスヘッダーに304が返ってこないからです。
HTMLのソースを確認して、最後に以下のコメントが無ければキャッシュは読み込まれていないので、何かがうまくいっていません。
<!-- Cache Enabler by KeyCDN @ 10.11.2015 17:32:29 (webp gzip) --><!-- Cache Enabler by KeyCDN @ 10.11.2015 17:32:29 (webp) --><!-- Cache Enabler by KeyCDN @ 10.11.2015 17:32:29 (html gzip) --><!-- Cache Enabler by KeyCDN @ 10.11.2015 17:32:29 (html) -->
その後、304が返ってこないサーバーを色々調査してわかったことがあります。
実はcache-enablerは正しく動いているが、キャッシュ表示の条件がNGなだけ
時間が経つとキャッシュファイルは、作成されているようです。キャッシュそのものは作成されているのに表示されない、ということで、どこで表示しない判定になっているのか調べました。
キャッシュ系プラグインでは、advanced-cache.phpというファイルで、キャッシュファイルを表示するかどうか決めています。
私の場合は、Wordpressからログアウトしているのにcookieで管理者モードと判定されて、キャッシュが読み込まれないようでした。
// check cookie values
if ( !empty($_COOKIE) ) {
// check cookie values
if ( !empty($settings['excl_cookies']) ) {
// if custom cookie regexps exist, we merge them
$cookies_regex = $settings['excl_cookies'];
} else {
$cookies_regex = '/^(wp-postpass|wordpress_logged_in|comment_author)_/';
}
foreach ( $_COOKIE as $k => $v) {
if ( preg_match($cookies_regex, $k) ) {
return false;
}
}
}このことから分かるのは、cache enablerは正常に動いているんだけど、自分の環境では確認できないだけ、ということだと思います。
他のサイトではログアウトすればキャッシュファイルが読まれていることは確認できる（ソースのコメント＋304ヘッダー）のですが、なぜか特定のサイトではcookieの影響があってキャッシュが表示できなかったようです。
また、キャッシュが読み込まれない人がいくらサイトを表示してもキャッシュは作成されないようで、キャッシュが作成されないからプラグインが正しく動いていないという勘違いにつながりやすいです。
- しばらく時間をおいてキャッシュファイルが作成されるか確認
- サイトのCookieを確認し、キャッシュを表示しない条件のCookieの存在を確認する
- 必要に応じてCookieを削除する
キャッシュが表示されない時はCoockieを削除しよう
cache enablerの仕組みで、wordpress_logged_in_というcookieがあると、そのサイトはキャッシュを読み込みません。本来、wordpressからログアウトすれば消えるものだと思いますが、消されずに残っている場合があります。
そのcookieがある場合は、手動で削除することで、キャッシュの読み込みが行われるはずです。
cookieの削除はブラウザから簡単に行うことができます。
Cache enablerはpolylangと相性が悪い
PolyLang で多言語化しているサイトだと、TOPページだけキャッシュが作成されない現象があります。
PolyLangのドキュメントには、「ブラウザー言語の検出が有効の場合、初めてホームページにアクセスしたユーザーは、ブラウザの設定に応じた言語でホームページにリダイレクトされます。」とあり、リダイレクトされることによってキャッシュが作成されなくなるようです。
PolyLangで「ブラウザー言語の検出」を無効にすれば、ホームページもキャッシュされます。ただし、「ブラウザー言語の検出」を無効 にするとユーザーの言語環境によって自動的に言語が切り替わらなくなる欠点があります。
根本対策は行われていないようで、今のところ上記の対応になるようです。
Cache enablerはwp_is_mobileを使っているテーマでは使えない
Cache enablerを含む、殆どのキャッシュプラグインはPCとスマホのキャッシュを分けません。なので、PCとスマホのHTMLソースが異なる場合は、トラブルが起きます。
キャッシュされた時のHTMLソースがPC用だと、スマホでアクセスるとPCの画面が表示されます。その逆もあり得ます。
上記のような問題が起きるのは、wp_is_mobileというwordpressの関数を使ってデバイスの判定を行っているテーマが当てはまると思います。
wp_is_mobileを多用しているテーマとしては、TCDのテーマがあります。TCDのテーマは、キャッシュプラグインとの相性は良くないと思います。
wp_is_mobileを使っている場合の回避策としては、スマホの時にキャッシュしないというオプションがあるプラグインが多いですが、結局はスマホではプラグインを使わないというのと同じです。
国内のテーマでは安易にwp_is_mobileを使用しているテーマが多いですが、海外の有料テーマはwp_is_mobileを極力使わないように構成されている感じがします。
お名前 SDサーバーだとcache enablerが動かない
遅いサーバーほどキャッシュを導入したくなりますが、不幸なことにお名前SDサーバーはcache enaberが動きませんでした。
理由を少し探ったところ、ob_start()でバッファしてキャッシュを保存する部分が全く動かない様でした。おそらく、サーバー側でphp周りの制限があるのだと思います。
すでにRSサーバーがリリースされていることもあり、SDサーバーは今後の改善も見込めないため、素直にサーバーを移転する方が正しい行動だと思います。
cache enablerを導入した方がサーバー負荷は下がる
レスポンスヘッダーに302が返ってこなくても、cache-enablerを導入した方がよいです。ロリポップはサーバーが弱く、画像の読み込みやCSS、jsなども読み込めないケースがあり、サイトの表示が崩れまくります。しかし、ロリポップにcache enablerを導入することでサイトの表示が安定します。
実は無料では最強かもしれない yasakani-cacheプラグイン
cache enablerを入れてもイマイチな時は、yasakani-cacheプラグインをおススメします。
こちらのプラグインは日本製で作者はplugin load filterと同じ作者の方です。 とても役立つプラグインを作っています。
nginixのサーバーで、cache enablerがどうやってもadvanced-cache.phpを読み込んでない風のヘッダーを返すので諦めていたところ、yasakani-cacheを入れたら見事 304を返すようになりました。
どのキャッシュプラグインもダメ！という時は、yasakani-cacheを使うようにしたいと思います。
その後わかったのは、yasakani-cacheはautoptimizeと組み合わせて使用できないことです。作者さんは同じような機能を提供していますが、autoptimzeが好きな人にとってはいっしょに使えないというのはNGかもしれません。
Cache enablerよりも体感速度は早い感じがしますが、autoptimizeとの組み合わせが不可な点、また、たまに500エラーが出て不安定な点などあったので、cache enablerが使える場合は無理に使わなくてよいかなと思いました。
まとめ
キャッシュ系プラグインを導入しても、体感速度も、pagespeed insightなどの速度計測ツールでも数値が改善しないことが多いのですが、今回一番大事な体感速度が改善したのが良かったです。
Pagespeed insightの数値は改善しませんでした。最近、どうでもいい項目でやたらと点数が厳しく出るのであまり気にしないことにしています。
