#コーディング
WordPress Transients APIで処理を部分的にキャッシュしよう

WordPressでサイトを制作する際、動的に出力内容が変わる箇所が多数出てきます。そのためのCMSですから、当然ですね。
しかし、ものによっては、閲覧頻度が高い割にそこまで内容が頻繁に変わらない…という箇所が出てきます。
ブログ一覧
例えば、弊社TOPのブログ一覧は当てはまります。TOPページのため閲覧頻度は非常に高いですが、ブログの更新ペースは週一本程度を目安としているため、ほとんどのアクセスは他のアクセスと全く同じ光景になります。しかし、閲覧されるたびにデータベースのアクセスは発生するため、余計な負荷が発生していると言えます。

キャッシュプラグインの不安

W3 Total Cache
こういった事情に対応できるものとして、キャッシュプラグインがあります。これらの基本的な挙動は「最終的に生成されたHTMLをキャッシュして、暫くの間同ページへのアクセスにはキャッシュを直接返す」というものです。実際はオプション項目や競合プラグインが多数存在するため、もっと複雑なのですが、大まかにはこんな感じです。
問題なく動きさえすれば、これら単体でサーバー応答速度を一気に改善できる強力なプラグインなのですが、わかりやすい問題として、想定しない表示が発生しやすいことが挙げられます。
SPアクセス
PCとスマートフォンによってサーバーサイドで表示を変える実装をしていた場合、最初にスマートフォンでアクセスがあり、
PCでアクセス
次にPCでアクセスがあったとき、キャッシュしたスマホ表示がそのままでてしまう…といった現象がよくあるケースです。
WooCommerceによるECサイトだったりすると、あるユーザーの会員ページが他のユーザーに表示されて個人情報が流出するなど、もっと深刻なことが起きることもあります。
勿論、オプションを調整するなどして対応出来ることも多いです。上のPCスマホの例でしたら、デバイスによってキャッシュを分けるといった対策が考えられるでしょう。しかし、繊細な挙動のサイトほど不安が大きくなっていくのが現実です。

Transients APIで自力でささやかキャッシュ

キャッシュプラグインがこちらを不安にさせる本質的な問題は、影響範囲の広さに対してブラックボックス過ぎることにあります。
それならば、キャッシュしても問題なさそうな箇所に自力でキャッシュ処理をかけることで解決できると言えます。
プラグイン任せが一般的な処理を自作はちょっと…と思われるかもしれませんが、実はWordPressには「Transients API」という、キャッシュ関連の処理を簡単かつ十分に行える関数群が標準実装されています。これらを活用すれば現実的に実装していくことが可能です。
Transients API

キャッシュを格納するset_transient

キャッシュの名称、格納する値、保存期間(秒)を指定することで、WP内のDBに指定した値が指定期間だけ格納されます。
格納できる値ですが、文字列、配列、オブジェクトまで、何でも入れることができます。

キャッシュを取り出すget_transient

set_transientにて指定したキャッシュ名を渡すことで、格納したキャッシュをそのまま返します。
キャッシュを生成していなかったり、期限切れ等で存在しない場合はfalseが返ってくるので、IF文と組み合わせるのも簡単です。

キャッシュを削除するdelete_transient

set_transientにて指定したキャッシュ名を渡すことで、格納中のキャッシュを即座に削除できます。

WordPressのフックと組み合わせることで、より柔軟なキャッシュ管理を実現させられます。
アクションフック「save_post」に削除処理を引っ掛けることで、投稿が保存・更新された時にキャッシュが一新されます。これならば、投稿のループ表示はキャッシュでまかないつつ、更新があったら即座に反映、といったような挙動を実現できます。
 
キャッシュ特有のリスク自体は自作してもなくなることはありませんが、自作ならば「どこをどのようにキャッシュしているか」をハッキリさせられるので、安定性を維持したままの高速化がより図りやすいと思います。上手く活用していきたいですね。

CONTACT

この度は当社へご興味お持ちいただき
ありがとうございます。
Webに関するお悩みございましたら、
是非一度お気軽にご相談ください。
平日10:00~19:00