Word PressのキャッシュプラグインをQuickCache Proに変更しました

QuickCache Pro

目次

QuickCache ProにAuto Cache Engineが実装されたので更新した

キャッシュプラグインを変えました。以前からこっちのほうでは実験中だったのでさほど大きな問題は出ないと思いますが、一時的に不安定になったりするかもしれません。なんか今までとは変わったなーとか思ったら教えてください。

QuickCacheは元々フリーの優秀なキャッシュプラグインだったのですが、2013年11月21日版(v131121)からフリーのLite版と15ドルのPro版に別れLite版では今まで使えていた機能がいきなり使えなくなりました。詳しくは以下の記事あたりを。

Sukima Windows Plus : WordPressのキャッシュプラグイン「Quick Cache」が有料化したせいで大変な目にあった

要するにアレでした。有料にするならば従来の無料版に対するAdvancedという位置づけにするべきで、無料版に機能制限をかけるというのは少々お行儀が悪い。でもこれまでに他の代表的なキャッシュプラグインでは色々トラブルがあり、今更また乗り換える気もしなかったのでまあ15ドルなら払ってやるかみたいな感じで当時購入しました。今でもLite版を導入するくらいならばWP Super Cacheとかのほうがまだマシです。

主には安定性とAuto-Cache Engine(サイトマップを参照したキャッシュのプリロード)を買っていたんですが、初期のPro版では未実装でした(アレな点その2)。まあコアな機能だしすぐに実装されるだろと思ったらめっちゃ放置され仕方なく古いバージョンを使い続けていました。しかしメンテナンスされないものを使い続けるのはセキュリティリスクが高まっていくので自分でパッチあてたりしながら待ってたんですね。

で、やっと今月になってPro版にAuto-Cache Engineが実装された(v140605)ため更新しました。買い切りとはいえ半年以上待たされたのはなんだかなあという感じです。というわけでしばらく様子見。

それにしても上の記事のように古いバージョンを使い続けているユーザはまだ多いはずです。これが後々大問題に発展しなければいいなと思います。

キャッシュってなに(蛇足)

そもそもキャッシュってなんだよみたいなところから説明すると長くなるのですが、なんかする気になったので書きます。いまさらな人は読み飛ばしてください。

Webページの表示の仕組み

Word PressはPHPで書かれているブログソフトウェアです。一般的にこういったプログラムとWebブラウザは次のようなやりとりを経てページを表示しています(ものすごい簡単に書いています)。

  1. ブラウザからURLへアクセスがされる。
  2. プログラムが色々やってHTMLコードを作る。
  3. プログラムがブラウザへHTMLコードを出力する。
  4. ブラウザが表示する。

例えば今サイト内ランキング1位になっているFF14の釣りページのURLは、

FF14 新生エオルゼア 園芸師のレベル上げ 50まで FF14 新生エオルゼア 採掘師のレベル上げ 50まで えっ、い...

このように拡張子が.htmlではありますが実際にソースコードを手書きで全部書いているわけではありません。本文のテキストだけ書けばあとはWord Pressが自動で生成してくれているわけです。記事自体も生成してくれますが、他にもカテゴリページやトップページの更新やRSSの更新なども自動でやってくれるので超楽ちんなわけです。こういうのを広義では動的コンテンツといいます。反対語は静的コンテンツで、これは昔ながらの手書きHTMLとほぼ同義です。

動的コンテンツにおける問題

このように動的コンテンツには大きなメリットがありますが、一方で問題もあります。

その1つ、それは上の2番目にあたる部分で要するに「HTMLを作るまでにプログラムが色々処理するため時間がかかる」という問題です。例えばこのブログで素直に1ページを動的に出力しようとすると表示までに約30秒近くかかります。これではサイトとしてお話になりません。

そこでキャッシュという考え方

そこで登場するのがキャッシュという仕組みです。これもものすごく簡単に表現すると「使いまわせるものはとっておいてあとでまた使う」という考え方です。

もしかしたら「ブラウザのキャッシュ」という言葉は聞いたことがあるかもしれません。これは非常にわかりやすく、画像などは基本的に毎回同じものが表示されるわけですからこれをブラウザ側で(=PC側で)とっておいて、わざわざダウンロードしないようにしようというものです。ダウンロードしなければそれだけページの表示が早くなります。スタイルシートとかJavaScriptとかもこれに該当します。

そういったキャッシュの考え方をソフトウェアのレベルに適用すると使いまわせるものは目には見えにくいですが他にもたくさんあります。それらのキャッシュを実現してくれるものをアクセラレーターとか言います。PHPアクセラレーターでググると例えばAPCなど、代表的なものが紹介されているはずです。

ブログエンジンで言うところのキャッシュ

このように「使いまわせるものは使いまわす」というところを突き詰めていくと「誰かがページにアクセスしたら、その回で作ったページを保存しておいて次の人にはそれを表示してもらえば速いのでは?」というところに行き着きます。

これがWord Pressを始めとするブログエンジン等で言われるキャッシュの仕組みです。結果として同じHTMLコードを複数の訪問者が見るわけですから非常に合理的です。これで表示までの時間が数秒まで縮まります。

しかし初回アクセス時にはやはり時間がかかるわけです。

キャッシュのプリロード

さらに考えを詰めていくと「アクセスされなくてもあらかじめページを作っておいて、アクセスがあったら既成品を表示させれば初回アクセスも速くなるのでは」となります。こういった仕組みは「キャッシュのプリロード」というような用語で表現されます。Quick Cache ProのAuto-Cache Engineはこれに該当します。

Quick Cache Proの場合はサイトマップのXMLを元に定期的にプリロードするロジックで、15分ごとにおおむね最近のページや重要なページをロードしてくれています。他にも「古いけどアクセス数は多いからプリロードしたいページ」なども個別に設定できます。そうしてようやく今の表示スピードが確保できているわけです。これ以上はマシンスペックとか高速な回線につながっている専用サーバー(要するにお金)がないと難しいですね。

キャッシュの問題点

ここまでで勘の良い人は気づいたかもしれません。「使い回したらいけないものもあるんじゃないの」と。もちろんあります。そしてこれがキャッシュプラグインが抱えている問題です。

「動的に生成するべきところをキャッシュしてしまった。」なんていうのが一番ありがちな例です。例えばモバイル向けのテーマで表示されたものをキャッシュしてPCのブラウザにも見せてしまうとか。

そういう単純なものであればまだ良いですが、Word Pressのように色んな人が色んな環境で色んなプラグインを入れて運用しているようなものだと、どうしてもプラグインやテーマとの競合が起きてしまったりします。これらを1プラグインの開発者が把握しきるのは難しく、仮に把握できたところで「どうしようもない」こともあります。

このへんはオープンソースで色んな使い方ができるWord Pressを使っている以上は仕方のない問題であり、自分の運用に合わせて何を使うか使わないかの落とし所を探っていくしかありません。

あ、ちなみに画像やメディアファイルのキャッシュの話に戻りますが、これはサーバー側で「何日保存しろ」というメッセージをHTTPのヘッダに載せています。「Expiresヘッダー」とかでググると良いでしょう。

例えばこれを7日に設定すればその環境では7日間新たにダウンロードされることはなくなるわけですが、途中で画像の内容を変えた場合でも更新されないことになります。そういう場合はソーシャルゲームとかでもファイル名を変えつまりURLを変えてやることで別のファイルとして認識させるとかいうことをやっているはずです。艦これがいつも「キャッシュクリアして!」って言ってるのは様々な都合でこれが出来ないからでしょう。

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
QR Code Business Card