サーバ全体的に動的なコンテンツが増えていることと、回線が細いのでなるべく高速化したい、ということでクライアント向けのキャッシュがどうなっているのかFirefoxのLive Http Headerを使ってサイト全体をざっとチェックしてみました。
結構no-cacheやLast-Modifiedを返していなかったりとクライアントでキャッシュ出来ていないものが多いことが確認出来たため、apacheに設定を追加・変更してレス ポンスを向上させてみました。
SSIを使っているページやblogは(まだ調整は残っているものの)割とあっさり終わったのですが、少しはまったのが WordPressとMediaWiki。
どちらもほぼno-cacheを返してきます。調べると以下のような感じ。
- WordPress -- ログイン状態を維持している人にはno-cacheが常に出る仕様。設定変更しても一向にno-cacheがなくならないため少し迷った。(これ自体はおかしな動作ではないです。私がヌケていただけ)
- WP-Cache -- プラグイン自体を無効化しても設定でDisableしないとキャッシュファイルが常に出来るという謎の仕様。
- WordPress -- ログインしていなくても、内部でキャッシュされていようと、全く変更がなかろうと304 Not Modifledを返さ(せ)ない?。。。らしい
- MediaWiki -- というかCategoryTreeプラグイン。デフォルトではページ内に貼り付けるとno-cacheになる仕様。設定変更でキャッシュされるようになった。(ただしカテゴリのリストがダイナミックに読まれる)
- $MW/extensions/CategoryTree/CategoryTree.php:45行目
$wgCategoryTreeDisableCache = false;
$wgCategoryTreeDynamicTag = true;
$wgCategoryTreeHTTPCache = true;
少しソースを見てみたのですがWordPressはmod_expiresで無理やりクライアントに覚えさせるしかない模様?
- .htaccessに"ExpiresByType text/html A3600"等と追加。3600は秒数。
RSS Feedはちゃんと304を返す処理があるのに。プラグインなどで不具合が出るとか理由があるのかもしれない。実現自体はWP-Cacheかwp-include/classes.phpをいじればいけそうな気がします。
これって、意外なWordPressの弱点。。。なのかな?私の理解不足なんでしょうが、クライアントキャッシュは効果が大きいので勘違い・事実誤認だといいのですが。
なにかおかしいとか、こんなことしたらいいよとか、ご存知の方は是非教えてくださいませ。
以上、チューニングで少し全体が速くなったかもしれないです。
#この記事はもう一つのブログから移動してきました。