WordPressはPHPアプリケーションであるため、キャッシュプラグインがよく利用される。多くのキャッシュプラグインは「高速化」という言葉と一緒に紹介されることが多いため、それならば試してみようと思うことが多いが、実は高度な技術であるため、ある程度の知識が必要とされる。この記事では前提知識を含めた上で、いくつかのおすすめプラグインを紹介しよう。
そもそもキャッシュとは？
キャッシュとはコンピューターシステムの専門用語で、「ある領域から他の領域に情報を伝送する際にその中間で作用し遅延を隠蔽するシステム」のことだ。図示すると、このようになる。
「情報の伝送」だと少し具体性にかけるので、PHP（スクリプト）とMySQL（データベース）を例にしよう。
キャッシュとは、そもそもこのような仕組みを指す。
Glossaries（用語集）
WordPressでWebサイトを構築する際、キャッシュが適用可能な領域は様々だ。どんなキャッシュがあるのかを一つずつ挙げていく。なお、ここに挙げるのはWordPressで問題となるケースであり、別の方法でWebサイトを構築する場合においてはこの限りではない。
ブラウザキャッシュ
我々がWebサイトを見るとき利用しているブラウザにはキャッシュ機能がある。たとえばCapitalPのトップページを見ると、style.cssがダウンロードされる。2ページ目以降でも同様にまったく同じstyle.cssを必要とするのだが、これはトップページを閲覧したときと同じファイルなので必要ない。この場合、ブラウザはキャッシュを利用し、同じファイルを2度ダウンロードすることはない。
ただし、これはきちんと設定していればの話なので、そのやり方については後述する。
CDN（コンテンツデリバリーネットワーク）
ネットワーク規模でキャッシュを利かせるブラウザキャッシュの上位概念のようなもの。ブラウザキャッシュはWebサイトを閲覧しているユーザー1人1人がそれぞれのブラウザにキャッシュを保持するが、CDNを利用すると、ネットワーク上にキャッシュが保持される。
ただし、これはプラグイン導入でどうこうなる話ではなく、Amazon CloudFrontやCloudFlare、FastlyなどのCDNサービスを利用する必要がある。唯一の例外としてJetpackのPhotonがプラグインページから利用できるが、対象となるのは画像だけだ。ちなみに、Photonを利用していなくても、Jetpackのタイルギャラリーを利用した場合、画像はPhotonのサーバーに保持される。
ページキャッシュ
WordPressを一言であらわすと、「PHPとMySQLを使ってHTMLを作り上げるシステム」である。したがって、この一連の操作をすべてキャッシュしてしまえば、ページを描画するための時間が短縮できる。
「キャッシュを導入したらめちゃくちゃ早くなった！」というブログ記事の多くはこの「ページキャッシュプラグイン」について書いていることが多い。
データベースキャッシュ
これはWebサイト構築における常識なのだが、データベースからデータを取得する作業はとてもコストが高い。要するに遅い。
したがって、「データベースへの問い合わせをすべてキャッシュすれば早くなるじゃん？」という発想から作られたいくつかのプラグインが存在するが、はっきりいって脆弱性の温床なので、後述する「オブジェクトキャッシュ」をお勧めする。
オブジェクトキャッシュ
これはWordPressが持つ独自の機構であり、「データをメモリ上に保存する」という機能を持つ。筆者が以前書いたブログ記事WordPressでbloginfoなくしてもDB負荷は減らないんじゃないかという話にある通り、WordPress自体にもともと備わっている「データベース接続を何度もしない」という工夫の1つだ。
詳細はCodexを参照してほしいのだが、デフォルトだと一回のページロードにおいてしか有効にならない。プラグインを利用することで劇的な効果をもたらす。
トランジェント
これもWordPressが持つ独自の機構だ。有効期限のあるデータの取得に利用される。データの持ち方が少し汚い（wp_optionsテーブルに保存される）ことを除けば、オブジェクトキャッシュとは異なり、どの環境でも利用できる。
具体的な利用方法としては、「twitterのタイムライン取得」である。すべてのページアクセスに対して毎回twitterのタイムラインを取得するのは馬鹿馬鹿しいので、たとえば30分はトランジェントキャッシュを利用し、キャッシュの有効期限が切れた時だけ再度取得しに行く。
おすすめプラグイン紹介
ページキャッシュ
ページキャッシュプラグインは大量にあるが、以下のプラグインをお勧めしておく。
理由としては「ページキャッシュだけを提供している」「レンタルサーバでも動く」「開発期間が長く、開発者も有名人である」の3点。ちなみに、CapitalPではWP Super Cacheを利用していたが、HSTSに対応するという宮内の強いこだわりによって外されてしまった（よって、いまこのサイトではキャッシュが効いていないはずである）
なお、エンタープライズ向けのページキャッシュとしてはVarnish Cachingというものがある。ただし、普通の人はVarnish自体を知らないはずなので、名前を紹介するだけにとどめたい。
VPSなどを利用している方はNginxのProxyキャッシュを導入するとともにNginx Cache Controllerを利用するのもいいだろう。
Memcachedを利用できる環境にある人は、後述するオブジェクトキャッシュと組み合わせるBatcacheを試してみてはいかがだろうか。BatcacheとMemcachedの組み合わせはかなり強力で、ページキャッシュなしでも数十万PV / 日に耐えることができる。
ブラウザキャッシュ
ブラウザキャッシュのおすすめプラグインは存在しない。なぜなら、サーバの設定をすれば済む話だからだ。
日本国内のレンタルサーバーにおいては、「サーバー名 + mod_expires」で調べると事例がたくさん見つかるだろう。mod_expiresはApacheのモジュール名で、ブラウザキャッシュの有効期限を指定するモジュールだ。
CDN
CDNで手軽に導入できるのはプラグインが存在するPhoton, Fastly, CloudFlareだろう。この中で一番簡単なのはサービス申し込みの必要がないJetpackのPhotonだ。ただし、厳密な速度でいうと、データセンターが日本に存在するかどうかが重要なので、それは調べてみた方がよいかもしれない。
Amazon Web Service を利用している人は画像をs3に上げてくれるプラグインNephila clavataを試してみてはいかがだろう。このプラグイン名、とっても覚えづらいのだが、作者の岡本さんが京極夏彦のファンだからこのような名前になっているのだと推察される。
オブジェクトキャッシュ
オブジェクトキャッシュと使うにあたっては、サーバの要件がものを言う。いわゆるレンタルサーバの場合、利用できるのはファイルシステムにオブジェクトキャッシュを保存するWP File CacheやW3 Total Cacheなどだ。しかし、どちらも筆者はあまりおすすめできないし、なによりファイルにキャッシュを保存するという仕組みが脆弱性につながる気配がする。
そのため、オブジェクトキャッシュを利用する場合は「どんなデータストアが利用できるか」によって異なってくる。よく使われるものを例に挙げ、いくつか紹介しよう。
また、プラグインとして紹介しているが、実際には「ドロップイン」なので、 wp-content/object-cache.php として配置する。何か問題が起きたらこのファイルを削除するだけで問題解決だ。
APCu
APCuは以前APCという名前だったが、PHP5.5からZend OpcacheとAPCuに分割され、ユーザー定義のデータストア機能はAPCuに任された。
APCuはPHP拡張としてインストールすることができるので、VPSなどであれば利用可能だ。プラグインとしては以下のものがある。
前者はArchLinuxメンテナのPierre Schmitz、後者はWordCamp US 2016でブースをボッシュートされたPantheonによるもの。どちらもそれなりに詳しい人たちなので、品質に関しては問題ないだろう。
注意点として、APCuはコマンドライン、つまりwp-cliと相性が悪いことは覚えておこう。APCuを有効化したデフォルトの状態だと、wp-cliはエラーになる。apc.enable_cli=1としなければならない。
Memcached
Memcachedはメモリ上にデータを保存するKVS（キーバリューストア）である。非常に高速で、オブジェクトキャッシュの保存先としてもっとも適任だ。
また、サーバが複数台構成されている場合、キャッシュがあちこちにあると困ったことになるので、Memcachedサーバを立てておくと安心だ。Amazon Web Service の Elastic Cache のようなものを使うと、クラスタリングも可能になる。これはAPCuにはない利点だ。セッションの保存先としても利用できる。
これぐらいの規模の構成になると非常に快適で、「なんでもかんでもオブジェクトキャッシュに突っ込んでおこう」というぐらいオブジェクトキャッシュ脳になる。筆者もよく、サイドバーやフッター（のレンダリング結果）をすべてオブジェクトキャッシュに突っ込んでいる。
Redis
RedisはKVSの一種と説明されるのだが、Listのように高度な機能も備えており、データをMySQLなどに永続化できるのだが、WordPressがオブジェクトキャッシュとして使う分にはMemcachedとの違いはない。
筆者はRedisを商用環境で使ったことがないのだが、プラグインとしては存在する。
Redisを利用した場合もMemcached同様に複数台構成のサーバでも問題なく動作するし、AWS Elastic Cache のようなRedisクラウドホスティングもいくつかある。
オブジェクトキャッシュについてまとめると、VPSならAPCu、複数台環境またはクラウドならMemcachedまたはRedisとなるだろう。
補足：ページキャッシュには向かないサイト
以前、筆者が書いた記事「ほんとうは怖いWP Super Cacheの話」にまとまっているのだが、ページキャッシュが劇的な効果をもたらすのは、あくまでそれがブログやメディアのような「限られた少人数が更新し、大量の人が見にくるサイト」の場合である。
注意すべきは次のようなケースだ。
- ログインしているユーザーにのみ提供する機能が多い（bbPressなど）
- キャッシュの誤配があった場合のダメージが大きい（ECサイト）
ただし、筆者が記事を書いた頃と異なり、WooCommerce + WP Super Cacheに関しては、双方ともAutomatticの傘下になったため、いくらなんでも普通に使って問題が出ることはないだろう（と信じたい）
ECサイトはコンピューターリソースあたりの客単価がブログやメディアと比べて高いので、キャッシュを駆使してサーバ代をケチるより、性能の高いサーバに移った方が楽というのが個人的見解である。
まとめ
以上、WordPressにおいてよく話題にのぼるキャッシュについてまとめてみた。おそらくすべての範囲をカバーしていると思うのだが、他に要望などがあれば、タレコミをお待ちしている。
コメントを残す