WordPress用ファイルキャッシュ Yasakani Cache

WordPress用にYasakani Cacheという新しいキャッシュプラグインが登場した。
日本人が作っていて日本語の説明ページもあるのでこの手のプラグインが苦手な人も安心。

Yasakani Cacheはファイルキャッシュ(データキャッシュ)。
ファイルキャッシュ系のプラグインは設定が難しく動作に罠があったりで苦労させられることが多い。ウェブサーバ側の設定にも手を付けなければならないことも多いのでとっつき難いという印象も。プラグインによっては.htaccessなどにmod_rewrite周りの設定を自動的に追加してくれるのでウェブサーバがApacheであれば難しくないという場合もあるけど勝手に変えられたせいで自分が指定した設定が台無しになることも。
Yasakani Cacheではキャッシュを高速なSQLiteデータベースファイルに置くという方法を採ることでウェブサーバ側に設定を追加する必要がなくなっていて、ウェブサーバがApache以外でも面倒が無い。そもそも導入については殆ど何も考える必要がない。Yasakani CacheプラグインをWordPressの管理画面の「プラグイン」から検索・ダウンロード・有効にしてYasakani Cache設定ページで「ページキャッシュ」を「有効」にするだけ。

Yasakani Cache 1
Yasakani Cacheの設定画面でページキャッシュを「有効」、ログモードを「All request url」にして「設定更新」。
利用しているホスティングサーバでSQLiteモジュールが使えない場合はこんなエラー。(左下のphp_errorの薄橙の部分にマウスポインタを置いて1秒待つとエラー内容が表示される。)
もちろんYasakani Cacheの設定でキャッシュを「有効」にしていても機能しない。
PHPのSQLiteモジュールが使えない(ホスティング)サーバでは使用を諦めるしかない。

Yasakani Cache 2
SQLiteモジュールが使えるサーバで設定は上と同じ。設定後に管理者画面からログアウトしてサイトのページを表示・再表示するとこんな感じのログになる。ログは新しいのが上、古いのが下。
左下のType列で「Store」になっているのがキャッシュ作成。「not_modified」はキャッシュが読み出されている。

キャッシュされているページ数は一番上の[Valid Cache]に表示される。

投稿や固定ページを更新した場合などはキャッシュは自動的に再作成されることになるようだが、テンプレートを編集したとかメニューやウィジェットを変更した場合は「キャッシュクリア」してやる必要があるみたい。

動作確認後の通常運用時のログモードは「無効」で良い筈。

記事にしたことがあるWP Super Cacheなどに比べると変なクセが無いのとNginxなどApache以外のウェブサーバでも何も考えずに気軽に使えるので凄く良いと思う。
ただし、データキャッシュ方式なので例えばテンプレートのPHPファイル内でアクセスしてきたブラウザのリファラを基に条件分岐してPC用とスマホ用に表示分けするような仕組みのサイトだと導入するべきでないし、動的に表示を変えるようなサイトでもやはり使うわけにはいかないと思われる。レスポンシブなテンプレートの場合はサーバからブラウザに送るデータは同じで、ブラウザ側でレイアウトを調整するのでデータキャッシュとの相性は良い。
(Yasakani Cacheはwp_is_mobile()を使ったPC用/モバイル用の表示分けには対応しているらしいのでwp_is_mobile()以外の分岐が要注意)

他のデータキャッシュと併用しても表示速度向上は望めない。例えば一つ前の記事のAPCuと併用しても意味が無い。

関連記事:

PHP7とAPCuによるWordPressの高速化

FreeBSDではPHP7用のAPCuのportsが存在しない状態が続いていたが、2016年8月初日にようやくportsになったみたい。まぁ、存在しないといっても既存のdevel/pecl-APCuのportsをコピペしてMakefileの対象バージョン(PORTVERSION)をAPCuの5系に書き換えてIGNORE_WITH_PHP= 70の行を消すだけで野良portsが作れたんだけど。
(もちろん、distinfoも書き換えてmake makesumするのも一連の流れとして必要)
と、いうことで野良portsでなく公式portsでインストール。

# cd /usr/ports/devel/php70-APCu
# make install

/usr/ports/devel/php70-APCu/work/apcu-5.1.5/apc.phpをどこかのウェブ用ドキュメントルート下に置いてAPCuのキャッシュを表示・管理できるようにする。(5.1.5の部分はバージョンなので将来は変わる)
apc.phpを編集。管理者のログインアカウントとパスワードをオリジナルなものに書き換える。

1
2
defaults('ADMIN_USERNAME','apc');           // Admin Username
defaults('ADMIN_PASSWORD','password');

/usr/local/etc/php.iniにAPCu関係の設定を追記して、PHP周りの再起動。

で、APCuを使う側だけど、以前に書いたAPCuによるWordPressの高速化では「Tribe Object Cache」プラグインを挙げたんだけど使えないみたい。(PHP7.0 + APCu5.1.5 + WordPress4.6の組み合わせで)
そこで、別のプラグインを使うことに。

今回はWP-FFPCを入れてみた。

APCuを使う 1
WP-FFPCを入れた直後はプラグイン管理画面に警告が出る。警告に従って設定が必要。

このプラグインは少し気が利かないので他のキャッシュ系プラグインのように自動でWordPressの設定ファイルwp-config.phpを書き換えてくれない。
wp-config.phpファイルをエディタで開き、define('DB_NAME', 'hoge');の上辺りに1行追加

define('WP_CACHE', true);

APCuを使う 2
キャッシュの種類(Select backend)は当然APCuにする。また、キャッシュの有効期間を指定する。画像の例では記事追加や更新が殆どないサイトを想定していてAPCuによるキャッシュの有効期間を12時間(43200)、ブラウザのキャッシュ期間を1日(86400)とした。(動作確認するまではブラウザのキャッシュ期間は0にした方が良いかも)
普通に更新のあるウェブサイトなら少なくともHomeのキャッシュ期間はサーバ側が3600(1時間)、ブラウザ側が600(10分)のように特にブラウザ側のキャッシュ期間を必要最低限にしておいた方が良い筈。
上の画像には表示されてないがスクロールして下の方に設定保存(Save Changes)ボタンがあるので押すと警告が2つ減る。

APCuを使う 3
キャッシュ対象を指定することもできる。初期値が常識的なので触る必要はないかも。
チェックしたものがキャッシュ対象でなくなる。

最低限の設定はこれで終わり。

APCuを使う 4
WordPressのページを幾つか表示した後にapc.phpを開きキャッシュの状態を確認。リスト表示にWordPressのサイトのURLが表示されていればキャッシュされている。
また、キャッシュされたページを閲覧した場合はHit列の数値が増える筈。Hitが発生(キャッシュを利用)していること(1以上)を確認できれば正常に機能していると言える。

APCuはデータキャッシュなので特定の条件で内容の一部または全部を変えて出力するようなページには向かないというか使っちゃダメ。例えばPCブラウザ用とモバイル用で出力を分けているとか日付・時間で出力を変えているとかetc.という場合。モバイル端末で訪れた人にPC用ページが表示される(或いはその逆)というようなことになる。ブラウザの窓サイズによって可変表示される綺麗なレスポンシブなページであれば出力するページそのものが変わるわけではなく表示するブラウザ側でCSSを元にレイアウトを変えるのでキャッシュするのに向いている。

関連記事:
Up