Concrete CMS のキャッシュ機能のまとめ

Concrete CMS は動的なCMSです。また、ページにさまざまなブロックをドラッグ＆ドロップで配置できるという仕組み上、データベースからさまざまな情報を取得して組み合わせた上でページを表示することになります。その結果、どうしても静的なHTMLファイルを配信するよりは動作が遅くなってしまいます。

そのため、表示を高速化するにはキャッシュの理解が不可欠です。よく、「Concrete CMS は遅い」という方がいらっしゃるのですが、よく聞いてみると全てのキャッシュがオフの状態で運用していたりします。正しくキャッシュの設定を行えば、表示速度は大きく改善するはずです。

しかし、キャッシュの仕組みは複雑で分かりにくいため、Concrete CMS の使用歴の長い方でもきちんと理解していないことがあります。本記事では、キャッシュについ正確に理解していただけるよう、まとめてみたいと思います。

Concrete CMS のキャッシュにはどのようなものがあるのか

ひとくちにキャッシュと言っても、Concrete CMS にはさまざまなキャッシュがあります。ここでは、それぞれのキャッシュの用途について解説します。

リクエストキャッシュ

Concrete CMS の内部的に使われているキャッシュ。データベースから何度も同じデータを繰り返し取得するのを防ぐ用途に使われており、1リクエスト中でのみ有効で、すぐ消えます。

エクスペンシブキャッシュ

翻訳やデータベース接続のためのDoctrine ORMライブラリなどで使われているキャッシュです。長期間保持される用途に適しており、一部のアドオンなどでも使用しています。

オーバーライドキャッシュ

Concrete CMS のオーバーライド（ concrete ディレクトリ内のファイルを application ディレクトリにコピーすることで挙動をカスタマイズできる仕組み）のためのキャッシュで、毎回 application ディレクトリ内にオーバーライドがあるかどうかをチェックすることによるオーバーヘッドをなくすために、何がオーバーライドされているかをキャッシュするしくみです。

ブロック出力キャッシュ

ページ内に配置されているブロックひとつひとつについて出力結果をキャッシュする仕組みです。特に「オートナビ」など、サイト内のたくさんのページからデータを取得して表示するようなブロックは、表示が遅くなる原因となります。ブロックキャッシュがあることで、各ブロックの出力結果が保持され、次回の表示から素早くブロックが表示できるようになります。

フルページキャッシュ

ブロック出力キャッシュがあってもなお、データベースから各ブロックの表示内容を取得して動的に表示していることには変わりありません。フルページキャッシュは、ページ全体の表示結果をまるごとキャッシュしておく仕組みです。これにより、データベースに一切アクセスすることなく表示が可能になりますので、静的ファイルと遜色ない速度でコンテンツの配信が可能になります。そのため、極力フルページキャッシュでコンテンツ配信できるようにチューニングすることが最も重要となります。

管理者はどのキャッシュ設定を確認すべきか

それぞれのキャッシュについて、設定でオンオフできるのかなどの情報を次の表にまとめてみました。

キャッシュ名	保存場所	管理者による設定の可否	推奨設定
リクエストキャッシュ	メモリ	設定できない	なし
エクスペンシブキャッシュ	ファイル	設定できない	なし
オーバーライドキャッシュ	ファイル	キャッシュ＆スピード設定の管理画面から有効化・無効化が可能	有効
ブロック出力キャッシュ	データベース	キャッシュ＆スピード設定の管理画面から有効化・無効化が可能。また、ブロック個別の設定変更も可能	有効
フルページキャッシュ	ファイル	キャッシュ＆スピード設定の管理画面から有効化・無効化が可能。また、ページ単位の設定変更も可能	有効

原則、全てのキャッシュは有効化して運用すべきです。さらに、ブロック出力キャッシュとフルページキャッシュは初期設定ではなく、チューニングすることが重要です。

ブロック出力キャッシュの設定方法

ブロック出力キャッシュは、ページ内の個別のブロックごとに設定を変更することが可能です。キャッシュ設定を変更するには、編集モードでブロックメニューを出し、「詳細」をクリックします。

詳細メニューの下部に「ブロックタイプのキャッシュ設定を上書きします。」という項目がありますので、チェックを入れてください。

すると、詳細なブロックキャッシュの設定画面が出てきます。

デフォルトでどの項目にチェックが入っているかなどは、ブロックタイプごとの初期設定が反映されています。例えば、上記のスクリーンショットの「TOPナビゲーションバー」ブロックの場合、

• ブロックの出力をキャッシュする
• ログインユーザーにもブロックの出力をキャッシュする
• POSTリクエストでもブロックの出力をキャッシュする
• キャッシュの保持期間は300秒（5分）

ということが分かります。

まずチューニングしたいのは、 キャッシュの保持期間 です。TOPナビゲーションバーに表示されるようなサイト内の主要なページは、通常Webサイトを運用しているなかで、めったに変更されることはないと思います。ですから、5分という設定は短すぎますので、少なくとも24時間、可能であれば1ヶ月など長い期間に変更するべきでしょう。もしサイトの構造を変えたときは、キャッシュクリアをすれば即座に反映されますので、キャッシュクリアさえ忘れなければ十分に長い期間にして問題ないのです。他にも、「次へ」「前へ」ナビブロックなども、時系列順で設定していれば、すでに公開した記事の日付を頻繁に変更するような特殊な運用をしていない限り、長期間キャッシュして何の問題もありません。

そのほかに、オートナビなど、ユーザーの権限によって出力内容が変わる可能性があるブロックタイプは、ログインユーザーには出力をキャッシュしない設定になっています。しかし、このことが会員制サイトの表示速度を低下させる原因になります。ログインユーザーによって表示されるページが変わらないナビゲーションであれば、ログインユーザーにもキャッシュする設定に変更することで表示速度が向上します。

検索ブロックなど、ユーザーの入力によって表示が変わるブロックタイプは、出力をキャッシュしない設定になっています。また、フォームの送信は通常POSTメソッドで送信されますが、その際にキャッシュしたくないブロックもあります。この２つの設定はチューニングの余地はあまりないので気にしなくて構いません。

下記にブロックタイプごとのデフォルト設定を表示しますので、チューニングの参考にしてください。キャッシュ保持期間の「0」は、クリアされない限り永遠にキャッシュが保持され続けるという意味になります。

ブロック名	出力キャッシュ	POSTリクエストでもキャッシュを表示	ログインユーザーにもキャッシュを表示	キャッシュ保持期間
アコーディオン	有効	有効	有効	0
オートナビ	有効	有効	無効	300
ボード	無効	無効	無効	0
パンくず	有効	有効	有効	0
カレンダー	無効	無効	無効	0
カレンダーイベント	無効	無効	無効	0
記事	有効	有効	無効	0
コメント欄	無効	無効	無効	0
日付ナビ	無効	無効	無効	0
ドキュメントライブラリ	無効	無効	無効	0
イベントリスト	無効	無効	無効	0
Express エントリー詳細	無効	無効	無効	0
Express エントリーリスト	無効	無効	無効	0
外部フォーム	無効	無効	無効	0
FAQ	有効	有効	有効	0
特色	有効	有効	有効	0
特集リンク	有効	有効	有効	300
ファイル	有効	有効	有効	0
フォーム	無効	無効	無効	0
ギャラリー	有効	有効	無効	0
Googleマップ	有効	有効	無効	0
ヒーロー画像	有効	有効	有効	300
水平線	有効	有効	有効	0
HTML	有効	有効	有効	0
画像	有効	有効	無効	0
画像スライダー	有効	有効	無効	0
最新のフォーム	無効	無効	無効	0
レガシーフォーム	無効	無効	無効	0
「次へ」「前へ」ナビ	有効	有効	有効	300
ページ属性表示	有効	有効	無効	0
ページリスト	有効	有効	無効	300
ページタイトル	有効	有効	無効	0
RSS表示	有効	有効	有効	3600
検索	無効	無効	無効	0
このページをシェア	有効	有効	有効	0
ソーシャルリンク	有効	有効	有効	0
アンケート	無効	無効	無効	0
言語切り替え	有効	無効	有効	3600
タグ	有効	無効	無効	0
紹介	有効	有効	有効	0
トップナビゲーションバー	有効	有効	有効	300
トピックリスト	無効	無効	無効	0
ビデオプレイヤー	有効	有効	無効	0
YouTubeビデオ	有効	有効	無効	0

フルページキャッシュの設定方法

フルページキャッシュは、管理画面の「キャッシュと表示速度設定」の設定から複雑になっています。ここでは、推奨される設定を紹介します。

フルページキャッシュは、原則「有効 - 該当のページ上のブロックで許可されていれば」を選択してください。フルページキャッシュは、完全に静的なHTMLとしてキャッシュされてしまうので、もしあるページでフルページキャッシュが有効になっている場合、そのページの中にユーザーの入力により動的に内容が変わるようなブロックが設置されていたとしても、そのブロックは一切動作しなくなってしまいます。この副作用を回避するための設定が「有効 - 該当のページ上のブロックで許可されていれば」で、フォームブロックなど動的なブロックがページ内にある場合にはフルページキャッシュが作られなくなります。

フルページキャッシュの有効期限は、デフォルトで6時間となっていますが、可能であれば長めに設定しましょう。スクリーンショットでは24時間（1440分）に設定しています。ただし、長すぎるのも問題があるかもしれません。もし「手動で削除したときまたはキャッシュがクリアされた時のみ」を選択すると、キャッシュの有効期間は最長設定の1年間となります。一見、「何か変更があった場合はキャッシュクリアすればいいではないか」と思うかもしれませんが、実はフルページキャッシュの有効期間は、Cache-Control レスポンスヘッダの値と連動しています。これは、Webページを閲覧したユーザーのブラウザにも、同じ長さのキャッシュが残り続けるということを意味します。ユーザーのブラウザキャッシュは、CMSから遠隔でクリアする手段はありませんので、フルページキャッシュの有効期間はあまりにも長すぎないようにするのをお勧めします（なお、ブロックキャッシュはユーザーのブラウザキャッシュと連動しないので、必要であれば 0 を設定して永遠に残り続ける設定にしても問題は発生しない）。

ブロックキャッシュの有効期限を尊重するオプションは、「有効」にすることを推奨します。これは、例えばフルページキャッシュの有効期限が24時間（1440分）になっていたとしても、ページの中にページリストブロックが設置されていた場合、ページリストブロックのキャッシュ有効期間である5分に合わせて、フルページキャッシュの有効期間も自動的に5分となる仕組みです。この設定を活用することで、ある程度フルページキャッシュ全体の有効期間を長めにしておいても、頻繁に更新されてほしいページのフルページキャッシュの有効期間が自動的に短めになることが期待できます。

また、フルページキャッシュはページ単位でも設定を上書きすることができます。各ページにアクセスし、ツールバーのギアボタンから「キャッシュ」メニューをクリックすることで設定画面を出すことができます。

この画面で「このページをキャッシュする」を選択して保存すると、フルページキャッシュの全体設定や、ページ内のブロックの設定に関わらず、フルページキャッシュを強制的に作成させることができます。また、キャッシュの有効期間設定をページ単位で変更することもできます。

この機能は、トップページなどアクセスが多く、かつ常に最新情報に更新されていてほしいページで短めのフルページキャッシュを作りたい時に適しています。例えばアクセスの少ない下層ページでキャッシュを5分作成しても、5分以内に別の人がアクセスしてこない限り、そのキャッシュはだれの表示も高速化することなく消えてしまいます。そのため、全体のキャッシュ有効時間はできるだけ長くすることが望ましいのですが、アクセスの多いページは有効期間を短くしても十分にキャッシュの恩恵を受けられることが期待できます。

また、急にSNSで特定のページがバズった時に、サーバー負荷を抑えるためにアクセスが急増した特定のページに一時的に長めのキャッシュを作ると言った用途にも重宝します。

この画面ではさらに「キャッシュステータス」欄で実際にフルページキャッシュが作られているかどうかも確認できます。サイト内の主要なページのキャッシュステータスを確認し、ほとんどキャッシュが作られていないことが分かったら、フルページキャッシュ設定や、キャッシュの作成を阻害するブロックがないか確認することをおすすめします。

Concrete CMS のキャッシュで気をつけること

ここまで Concrete CMS のキャッシュ機能と設定方法について解説してきました。最後に、キャッシュ関連でよくある誤解や、気をつけるべき点についてご紹介します。

グローバルエリア内のブロックでも、出力キャッシュは個別に作成される

グローバルエリアは、中身が全ページで同じになる特殊なエリアです。しかし、キャッシュは共有されません。これは、たとえばオートナビブロックでは「ナビゲーションの中の現在のページを分かりやすくする」などの処理が入っていることがあるように、全く同じブロックが入っていてもページごとに表示が異なる場合があるためです。

1箇所でキャッシュができれば全ページで高速化するだろう、と誤解されることがありますが、ページ単位ということを意識して、必要であればキャッシュの有効期間を長くすることで対応しましょう。

フルページキャッシュはログインユーザーには一律で無効になる

フルページキャッシュは、ページ全体を静的ファイル化するものですので、ブロック単位の権限による表示の出しわけとは全く相容れない機能です。そのため、ログイン中のユーザーに対しては一律でフルページキャッシュがオフになる仕組みになっています。閲覧にログインが必要な会員サイトでは、フルページキャッシュに頼らずブロックキャッシュを駆使して対応しましょう。

複数台構成の場合は、キャッシュの保存場所を変更する

エクスペンシブキャッシュ、オーバーライドキャッシュ、フルページキャッシュの３つは、デフォルトでサーバー上にキャッシュファイルが生成されます。そのため、アクセスを分散させるために複数台構成で運用している場合、それぞれのサーバーにキャッシュが分散し、キャッシュ効率が悪くなってしまいます。また、管理画面からキャッシュクリアを行っても、どれかひとつのサーバー上のキャッシュファイルしか削除されないため、残りのサーバーのキャッシュが残ったままになってしまうという問題があります。

そのため、複数台構成の場合は、キャッシュは外部サービスに保存するように設定するのが一般的です。キャッシュ目的で外部サービスを使用する場合、 Redis を使用することが多いでしょう。Redisは、キャッシュのために使用されることが多い、オープンソースのインメモリーNoSQLサーバーです。

キャッシュにRedisを使うための設定方法については、公式ドキュメントの Using a Redis Server ページを参考にしてください。

CDNとの連携

大量のトラフィックをさばくために、CDNを使用することも多いと思います。多くのCDNは Cache-Control レスポンスヘッダーの値をもとに、キャッシュするかどうかや、キャッシュの有効期間をコントロールすることができる機能があります。そのため、CDNの使用時にはフルページキャッシュの設定が特に重要です。ただしくフルページキャッシュが設定されていないと、CDNでもほとんどキャッシュが使われておらず、導入効果がほとんどなくなってしまい無駄になることもあります。一方、適切に設定すれば、ページごとにCDNで何分キャッシュが保持されるかといった細かい設定が、CMSの画面上で行うことができ、大変便利です。

特殊なブロックの出力キャッシュ

Concrete CMS には、他のブロックを内包する特殊なブロックがいくつかあります。

スタック は、管理画面から作成できる特殊なページです。この中身のブロックはサイト内のどのページにも設置でき、その中身が同期するという仕組みになっています。

レイアウト は、ページ内のエリアを横方向に分割できる機能です。似た様な機能に コンテナー があり、レイアウトよりも柔軟なデザインでエリアを分割することができます。

スタックは内部的には「スタック表示」ブロックとして処理されており、をページに設置した場合、スタック全体としてブロック出力キャッシュを持ちます。キャッシュ設定は、スタック内のブロックに依存します。全ての内部ブロックがキャッシュを許可している場合のみキャッシュが作成され、全ての内部ブロックの中で一番短い有効期間が採用されます。

同様に、レイアウトは「エリアレイアウト」コンテナーは「コンテナー」というブロックとして処理されており、スタックと同じく内部のブロックに沿ったキャッシュ設定になります。

キャッシュのデバッグに便利なアドオン

キャッシュのデバッグの際に便利なアドオンとして、弊社では Toolbar Block Outline という無料アドオンをマーケットプレイスに登録しています。

このアドオンを使用すると、ツールバーにボタンが追加され、クリックするとページ上の全てのブロックのキャッシュ設定を一覧表示できるようになります。フルページキャッシュの作成を妨げている原因のブロックを探すのに便利です。