WordPress の運営を始めて1年後にしてようやく（満を持して！）、キャッシュ・プラグインを使い始めています。とは言っても、最初は 「アレが速い」 とか 「コレが良い」 などといった記事に目移りして、何をどう使えばよく分かりませんでしたが、ここらで私が理解出来ていることをまとめてみたいと思います。

下図は、サイト閲覧者 ～ WordPress 間の主要なキャッシュ機構とそれをサポートするプラグインの関連です。サーバーのファイルシステムや、メモリ／ハードディスクなどの I/O レベルのキャッシュなどは割愛します。

図を見れば分かる通り、W3 Total Cache がその名の通り全てのキャッシュをカバーしています。さらにメモリ・キャッシュ、CDN へのアップロード機能、各種 PHP アクセラレータ （ACP、eAccelerator、XCache）、HTTP アクセラレータ （Varnish） など、サーバー運営に必要な機能をサポートしており、特に海外では人気のプラグインとなっています。本エントリーでは、こういった高度な機能はとりあえず脇においておき （というか、LaCoocan では試せないので ）、各キャッシュ機構ごとに、サイトの状況に合ったプラグインの選び方と設定を考えていきます。

1.ページ・キャッシュ

動的に生成された WordPress ページを丸ごと圧縮してキャッシュとします。通常最も最初に手を付ける部分でしょう。有名どころとして W3 Total Cache、WP Super Cache や Hyper Cache などがあります。ここででは前2つのプラグインを取り上げます。

まずは WordPress のパーマリンク設定ですが、デフォルトの http://example.com/?p=123 では ? から先のクエリ文字列が WordPress に横取りされ動的ページ生成となってしまうため、他の形式に変えましょう。

余談ですが、フォーラムで取り上げられている /%category%/%postname%/ 形式のパーマリンクは、WP Super Cache でもまれに不具合が起きるようなので、FAQ を確認しましょう。

次に、キャッシュされた静的ページへ誘導し （可能であれば予め圧縮されたデータを） 出力する方法を決めます。これには 「サーバーのRewrite 機能を使う方式」 と 「PHP プログラムで行う方式」 の2つがあります。前者は .htaccess へルールを追記することで実現し、当然サーバーレベルの機構を使うため高速です。後者は LaCoocan の様に Rewrite がユーザーに解放されていないようなサーバーで使うことが出来ます。キャッシュ出力方式と主要なプラグイン設定の対応関係は次の通りです。

プラグイン	キャッシュ出力方式
	Rewrite 方式	PHP 方式
W3 Total Cache	Disk (enhanced)	Disk (basic)
WP Super Cache	Use mod_rewrite	Use PHP

キャッシュページが存在しない場合、ユーザーからのリクエストがあった時点で （動的にページを生成するときと同じように） 新規に作成され、指定の有効期間だけ保持されます。一方古くなったキャッシュは、一定時間ごとに起動されるガベージコレクションによって削除されます。この 有効期間 は、各プラグインの推奨値で良いと思いますが、アクセス頻度が高く、かつそれによって内容が頻繁に変わるようなコンテンツ （例えば Popular Post などのウィジェット） を重視するなら、より短くすれば良いでしょう。

ウィジェットといえば、WP Widget Cache というプラグインが、WP Super Cache と相互補完し、各ページに共通なウィジェットだけをキャッシュ （おそらくオブジェクト・キャッシュ） します。次の表は、ローカル環境 （WinXP + XAMPP + WP 3.01） で、あるページの作成に必要なクエリ数と所要時間を観測した結果です。ウィジェットのキャッシュだけが残った状態から、ページ・キャッシュが新規に作成される状況を再現させていますが、このプラグインの目的どおり、クエリ数と所要時間の短縮が図られていることが分かります。

プラグイン	クエリ数	所要時間(秒)
プラグインなし	27	0.615
WP Super Cache	27	0.729
WP Super Cache + WP Widget Cache	19	0.653

参考情報

• [Plugin: W3 Total Cache] WordPress MU and theme questions
  • Disk (enhanced) と Disk (basic) のモードの違いが説明されています。

2.データベース・キャッシュ

WordPress は記事を表示するとき、MySQL からデータを引き出すためにクエリ （コマンド） を発行するわけですが、その出力を保持しておき、発行するクエリ数の削減を目的としたキャッシュ機構です。MySQL データベースが、専用の高速なサーバー＆ストレージで構成されていない限り、キャッシュの方が高速にアクセスできることを想定しています。

ページ・キャッシュがほとんど静的ページと同じ事になるのに対し、データベース・キャッシュ単体では動的ページの様に動作します。ゆえにページ・キャッシュと組み合わせた場合、通常はページ・キャッシュだけが効いていて、キャッシュの新規作成時や更新時にデータベース・キャッシュがその効果を発揮することになります。しかし、ウチの様にコメントの書き込みが非常に少ないサイトでは、ページ・キャッシュの更新タイミングとデータベース・キャッシュの更新タイミングが一致してしまい、逆にページの応答時間が遅くなってしまいます。

つまり、書き込みなどによる更新頻度が高い場合に、ページ・キャッシュの更新時間を短縮すること がデータベース・キャッシュの狙うべき効果と言えるでしょう。

また MySQL の全クエリに対してキャッシュが作られるかというと、そうでもありません。ページやプラグインの構成によっては、キャッシュされるクエリの方が少ない場合もあります。前章と同条件の観測結果を以下に示します。

プラグイン	クエリ数	所要時間(秒)
プラグインなし	27	0.615
W3 Total Cache (有効キャッシュ：Database, Browser)	9	0.759
W3 Total Cache (有効キャッシュ：Page, Database, Browser)	24	0.812
DB Cache Reloaded	15	0.737
WP Super Cache + DB Cache Reloaded	24	0.772

WP Super Cache + DB Cache Reloaded の組み合わせでは、DB Cache Reloaded 単体より逆にクエリ数が増えており、W3 Total Cache でページ・キャッシュとデータベース・キャッシュを有効にした場合と一致しています。

ページの生成に必要なクエリ数や処理時間は、次のコードを WordPress テーマファイルの single.php や page.php などにある <?php get_footer(); ?> の直後に置くことで、コメントとしてページに挿入出来ます。各プラグインも同様の情報をコメントとして挿入するため、その効果を検証して導入するのが良いでしょう。

<!-- <?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds. -->

参考情報

• get_num_queries()
  • WordPress 実行の間に発行されたデータベースへのクエリ数を得る関数です。
• timer_stop()
  • WordPress の実行開始からの経過時間を得る関数です。
• Between WP Super Cache VS DB Cache Reloaded 2009年11月19日
  • 上記関数を用いて、WP Super Cache と DB Cache Reloaded 効果を検証した記事です。

3.オブジェクト・キャッシュ

オブジェクト・キャッシュは、WP_Object_Cache 関数 wp_cache_set()、wp_cache_get() を用いて PHP の変数をファイルとしてキャッシュする機構です。WordPress 2.1 ～ 2.3 に実装されていたようですが、現在は WP File Cache などのプラグインで利用可能です。

結果的に、データベース・キャッシュ同様 MySQL へのクエリを減らしてくれます。前章と同条件の観測結果を以下に示します。MySQL のクエリ数削減には、データベース・キャッシュとオブジェクト・キャッシュの組み合わせが効果的なことが分かります。

プラグイン	クエリ数	所要時間
プラグインなし	27	0.615
W3 Total Cache (有効キャッシュ：Object, Browser)	13	0.723
W3 Total Cache (有効キャッシュ：Database, Object, Browser)	4	0.721
W3 Total Cache (有効キャッシュ：Page, Database, Object, Browser)	4	0.894
WP File Cache	13	0.623
DB Cache Reloaded + WP File Cache	5	0.653
WP Super Cache + DB Cache Reloaded + WP File Cache	10	0.780

参考情報

• Using the WordPress Object Cache 2006年7月21日
  • オブジェクト・キャッシュの使い方が解説されています。
• [Plugin: WP File Cache] This plugin slows mysite
  • WP Super Cache との住み分けが説明されています。
• Rauru Blog ≫ Blog Archive ≫ WordPress のキャッシュ 2008年1月17日
  • ページ・キャッシュとオブジェクト・キャッシュの説明です。
• WP Cache Inspect
  • オブジェクト・キャッシュの効果を計るプラグインです。
• 関数リファレンス/WP Cache
  • オブジェクト・キャッシュを扱うための関数リファレンスです。

4.リソース・キャッシュ

「リソース・キャッシュ」 という言葉は、私がそう呼んでいるだけで一般的用語ではないです。要は、ページ中のスタイルシートや JavaScript などのサブ・リソースを、予め束ねて圧縮ファイルとして保持しておく機構のことです。Apache で言えば mod_deflate モジュールがインストールされていれば on the fly でファイルの圧縮が可能なのですが、サーバー負荷の点ではこちらの機構の方が有利だと思います。

リソース・キャッシュは、「サブ･リソースを呼び出す数 = HTTP リクエスト数」 と 「量 = 通信量」 の両方を削減します。W3 Total Cache、Head Cleaner、WP Minify の各プラグインはどれもそれらを実現してくれます。

ここでは index.php、single.php、page.php など、各ページに共通する JavaScript ファイルを束ねる方法を、W3 Total Cache を例に示しておきます。

1. W3 Total Cache のメニューで 「General Settings」 を選択し、「Minify」 を 「Enable」 にします。
2. W3 Total Cache のメニューで 「Minify Settings」 を選択します。
3. 「General」 タブから 「Rewrite URL structure」 を設定します。チェックを外すと PHP 経由でのアクセスとなります。
4. 「JavaScript」 タブ 「JS minify settings」 の 「Enable」 にチェックを入れます。
5. ページ上部の 「Help」 で 「Minify Help Wizard」 を開き、束ねる JavaScript ファイルを選択します。
6. 「JS file management」 の 「File URI」 に選択した JavaScript ファイルが入力されたことを確認し、「Template」 に 「All Template （全ページ共通）」 を、「Embed Location」 にスクリプトの埋め込み場所を選択します。「Non-Blocking」 は JavaScript の “Non-Blocking Loading” を埋め込みます。
7. 「Save changes」 で設定を確定します。
8. ルートディレクトリの .htaccess が更新されたことを確認します。

5.キャッシュ制御

proxy サーバーやユーザーエージェント（ブラウザ）に、リソースに対するキャッシュ・ポリシーや有効期限を示すことで、無駄な HTTP リクエストを削減することを目的としています。特定のリソースに対して、.htaccess や PHP 経由で HTTP ヘッダの Last-Modified、Cache-Control や Expires フィールド （Cache-Control の方が優先される） に値を埋め込みます。

有効期限ですが、Yahoo! のページ高速化ルール では次のように言っています。

• 静的コンポーネントには、Expires ヘッダで 有効期限なし のポリシーで、はるか将来の有効期限とせよ
• 動的コンポーネントには、ブラウザが状況に合ったリクエストが出来るよう、適切に Cache-Control ヘッダを設定せよ

以下に、この機能を持つプラグインと設定可能なフィールドを示します。

プラグイン	Cache-Control	Expires
W3 Total Cache	リソース毎にメニューで設定	リソース毎にメニューで設定
Head Cleaner	設定不可	2592000 秒 （プログラム埋め込み）
WP Minify	public （プログラムで設定）	1800 秒 （設定ファイル、URL で指定）

参考情報

• Web 2.0 アプリケーションのパフォーマンスを改善する 2009年12月8日
  • ブラウザのキャッシュ・メカニズムと HTTP ヘッダフィールドの設定値が詳細に解説されています。
• [Studying HTTP] HTTP Caching
  • RFC2616 をベースに、キャッシュ・モデルが解説されています。

6.ガベージコレクションとプリロード

一定期間更新されず古くなったキャッシュは、ガベージコレクションによって削除されます。これによりごみファイルの増大を防止しているのです。各プラグインは、このガベージコレクション間隔の推奨値を持っています。

プラグイン	ページ・キャッシュ	データベース・キャッシュ	オブジェクト・キャッシュ
W3 Total Cache	3600 秒	3600 秒	3600 秒
WP Super Cache	3600 秒	－	－
DB Cache Reloaded	－	300 秒	－
WP File Cache	－	－	設定なし（無期限？）

キャッシュファイルが存在しないページにアクセスがあった場合には、ユーザーにより新規に作成されるわけですが、そのときは動的ページを作成する以上に時間がかかります。これを嫌って、W3 Total Cache と WP Super Cache は、全ページを対象に予めシステムによってキャッシュを作成する プリロード という機能を持っています （ココまで来ると、「動的にページを生成する」 という WordPress 本来のメリットとつじつまが合わなくなりますネ ）。

それぞれのプラグインはプリロード方式に関して、以下の様に異なるポリシーを持っています。

プラグイン	プリロード方式
W3 Total Cache	sitemap.xml の優先順位に従い、900秒毎に10ページずつ （値はそれぞれメニューで設定） 作成する
WP Super Cache	指定時間 （最小値30分） 毎に各ページ4秒の間隔を空け、新しいページから順に作成する

7.サイトに適した選び方

さてまとめですが、以上の特性から次のような選び方をするのが良いのではないかと思います。

読み込み、書き込みともアクセスが多い、あなたのサイト

迷わず W3 Total Cache をとことん使い込むのが良いでしょう。

書き込みが少なく、アクセスも多くない、私のサイト

ページ・キャッシュか、データベース・キャッシュ + オブジェクト・キャッシュの組み合わせが良いでしょう。ただし、ページ・キャッシュだけで W3 Total Cache を使うと、規模が大きい分、新規のキャッシュ生成時に余計に時間がかかるので、WP Super Cache をお勧めします。リソース・キャッシュは Head Cleaner か WP Minify で、キャッシュ制御は .htaccess で賄うのが吉です。

2011年7月7日（七夕）追記

現在は WP Widget Cache と併用し、WP Super Cache の有効時間を1時間（3600秒）に、WP Widget Cache の有効時間を12時間（43200秒、「カレンダー」はキャッシュなし、「最近のコメント」はコメント投稿時に更新）に設定しています。本サイトのトップページ場合、キャッシュなし状態で通常90〜100クエリが、30〜40クエリにまで減ります。

プリロードをしておきたい、あなた

Movable Type に乗り換えるのが最も良い気がしますが、どうしてもというなら、更新タイミングをサーバー負荷の低い深夜に来るように調整するのが良いでしょう。またオブジェクト・キャッシュと組み合わせることで、更新負荷を下げることも検討しましょう。

いろいろ試してみた、あなたからの情報を募集します

W3 Total Cache、WP Super Cache はデバッグの仕組みが充実していて、「どう設定したら、こうなった」 というのが検証できるようになっています。「この設定が効果アリ！」 みたいな情報がありましたら、書き込みをお待ちしております 。

参考情報

各プラグインのベンチマークに興味がある人向けに、参考情報を載せておきます。

• WordPress load test part 2 – amendment W3 Total Cache 2010年1月12日
• WordPress Cache Plugin Benchmarks 2010年3月4日
• WordPress Caching: What’s the best Caching Plugin? 2010年10月18日
• Hyper Cache + DB Cache Reloaded + Wp Minify = The SuperWordPress 2010年10月15日

最後に、本エントリーをまとめるに当たって検証した各プラグインのバージョンを記しておきます。

• W3 Total Cache Version 0.9.1.3 / Updated: 2010-9-17
• WP Super Cache Version 0.9.9.7 / Updated 2010-11-23
• DB Cache Reloaded Version 2.1 / Updated 2010-6-21
• WP File Cache Version 1.2.8.2 / Updated 2010-4-7
• WP Widget Cache Version 0.25.4 / Updated 2010-8-31
• Head Cleaner Version 1.3.14 / Updated: 2010-10-29
• WP Minify Version 1.0.3 / Updated 2010-11-22