ブログキャッシュをCloudflareへ移行：プラグイン設定の落とし穴

前回はドメインのDNS解決をCloudflareに向け、LiteSpeed CacheでもCDNの切り替えを完了させました。ただこの時点では、ブログにはまだ2つの問題が残っています。Cloudflare無料版はデフォルトでHTMLページをキャッシュしないこと、そしてLiteSpeedの中でQUIC.cloudのクラウド利用枠に依存している一部の機能が、枠の不足によって不具合を起こすことです。今回はこの2つの問題を一つずつ確認していきます。

なぜさらにプラグインを入れる必要があるのか

Cloudflare無料版はデフォルトで画像、CSS、JSといった静的リソースしかキャッシュせず、HTMLページはキャッシュしません。何もしなければ、訪問者がブログの記事を開くたびにリクエストは実サーバーまで戻ってページを生成することになり、このレイヤーではCloudflareが本当の意味で機能していないことになります。

解決策は無料プラグインを一つ入れることです：Super Page Cache for Cloudflare。このプラグインはAPIを通じてCloudflareの管理画面上に自動でキャッシュルールを設定し、HTMLページもエッジノードにキャッシュされるようにします。同時にかなり賢く、ログイン中のユーザーやコメントを投稿した訪問者を自動で識別してキャッシュを回避させ、管理画面やコメント機能がおかしくなることを防ぎます。

このプラグインを使わずに、単純にCloudflareの管理画面で手動で「すべてをキャッシュする」を有効にしても、確かにHTMLをキャッシュさせることはできますが、ログインCookieを含むリクエスト（/wp-admin/のパスなど）を除外するルールを自分で設定する必要があり、少しでも漏れがあると管理画面やログイン状態の表示がおかしくなります。プラグインを使えばこの手間を省けます。

インストール方法は簡単です。WordPressの管理画面 → プラグイン → 新規追加で、Super Page Cache for Cloudflareを検索し、インストールして有効化します。その後プラグインの設定ページに入り、CloudflareアカウントのメールアドレスとAPIトークン（前回LiteSpeedで使ったものと同じトークンで構いません）を入力し、ドメインを選んで保存し、「Enable Page Caching」をクリックしてページキャッシュを有効にします。

LiteSpeedのページ最適化：オフにすべきもの、残してよいもの

ここが今回の確認作業の核心部分です。Page Optimizationの利用枠を使い切ってしまったため、LiteSpeedの中でクラウド生成に依存している機能をそのままオンにしておいても、エラーが出て見た目が崩れるだけで、クラウドリソースにリクエストできずページのスタイルが欠けたりレイアウトが崩れたりする結果になります。以下、その機能が「ローカル処理」なのか「クラウド処理」なのかで分類します。

判断の基準は実は単純です。「生成」「クラウドでの非同期スタイル読み込み」といった説明がついている機能は、基本的にQUIC.cloudのサーバー側で計算した結果を受け取る仕組みになっているため、利用枠が足りなければ詰まったりエラーになったりします。一方「最小化」「結合」といった単純なコードの圧縮やまとめ作業は、ローカルサーバー自身で完結できるため、利用枠とは関係がありません。

CSS結合とJS結合については補足しておきます。この2つ自体はクラウドの利用枠を消費しませんが、実際の効果としては、異なるページに必要なスタイルやスクリプトを1つのファイルに無理やりまとめてしまうことになりやすく、ブログに多言語版があったり構造の差が大きいページがあったりすると、結合後に一部のページでレイアウトのずれが出る場合があります。安全策として、今回はこの2つを直接オフにすることにしました。ブログの構造が単一で、ページ同士が高度に統一されている場合は、オンのままにして効果を試してみるのもよいでしょう。

画像最適化：利用枠に余裕があれば触らなくてよい

これは一緒に誤ってオフにしてしまいやすい項目です。QUIC.cloudの利用枠は項目ごとに別々に計算されているため、Page Optimizationを使い切ったからといって、画像最適化の利用枠まで使い切ったことにはなりません。確認した結果、画像最適化のほうにまだかなり余裕があるなら、そのまま動かし続けて問題ありません。

• 自動リクエスト最適化（Auto Request Cron）：オンのまま
• 自動クラウド取得（Auto Pull Cron）：オンのまま

こうしておくと、新しくアップロードした画像は引き続きQUIC.cloudのクラウドに送られて非可逆圧縮され、WebP形式が生成されます。圧縮済みの画像は自分のサーバーに保存され、その後Cloudflareを通じて読者に配信されます——つまりQUIC.cloudの余っている利用枠で画像のスリム化を行い、Cloudflareの無料の帯域で高速配信を行うという、両者の強みをそれぞれ活かす形になります。

ただし、確認した結果、画像最適化の利用枠もすでに使い切っている、または使い切りそうな場合は、これら2つのスイッチもオフにしておくべきです。そうしないと、プラグインがバックグラウンドで失敗するとわかっているリクエストを繰り返し送信し続け、サーバーのリソースを無駄に消費してしまいます。

データベース最適化：触らなくてよい

データベースのクリーンアップ（記事のリビジョンの整理、スパムコメントの削除、テーブルの最適化）は完全にローカルサーバー上で動作するもので、CDNの選択やクラウドの利用枠とは無関係です。この部分は元々の使い方をそのまま続ければよく、今回の調整に合わせて何かを変える必要はありません。

2つのプラグインがどう役割分担し、競合を避けるか

Super Page Cache for Cloudflareをインストールした後、WordPressの管理画面でおそらく「Multiple Caching Plugins Detected」（複数のキャッシュプラグインが検出されました）という通知が表示され、LiteSpeed Cacheが同時に有効になっていることを知らせてきます。この通知自体は間違っていません——通常であれば、2つのキャッシュプラグインを同時に有効にするのは推奨されません。それぞれがローカルキャッシュの生成を競い合い、衝突しやすくなるからです。

ただ今回の状況は違います。2つのプラグインの役割はあらかじめ意図的に分けられており、重複していません。

重複を避けるため、Super Page Cache for Cloudflareの設定では、フロントエンドのコード最適化に関わる項目（HTML最小化、Googleフォントの最適化、アセットマネージャーなど）はすべてオフのままにしておき、この部分の作業は完全にLiteSpeedに任せることを推奨します。同様に、遅延読み込み関連の項目もオフのままにします。LiteSpeed側で既に画像の遅延読み込みを処理しているためです。

実際にオンにしておく必要があるのは、プラグイン内のLiteSpeed Cache settingsという連携用の項目群です。役割は、LiteSpeedがローカルで何らかのキャッシュをクリアした際、Super Page Cacheが連動してCloudflare側の対応するキャッシュもクリアするようにすることです。ここで最も注目すべきは「単一記事のキャッシュをAPI経由でリフレッシュする」という項目です。これをオンにしておくと、古い記事を1本修正した際、Cloudflareのノード上でキャッシュがクリアされるのはその記事だけになり、ブログ内の他の数百本の記事はキャッシュされた状態を保ち続けます。1本の記事を修正したことでサイト全体のキャッシュが無効になることはなく、CDNのヒット率を高い水準で維持できます。

その通知が表示されたら、そのまま閉じてしまって構いません。悩む必要はありません。2つのプラグインは今、互いに連携している状態であり、仕事を取り合っているわけではありません。

変更が終わったら、キャッシュを一度クリアしておく

すべての設定変更が終わったら、WordPress管理画面の上部にあるLiteSpeedのアイコンにマウスを乗せ、「すべてクリア」をクリックします。Cloudflare APIとの連携が済んでいるため、この操作によってローカルサーバーのキャッシュとCloudflareのエッジノード上の古いキャッシュが同時にクリアされ、以降訪問者が目にするのは最新の設定で生成されたページであることが保証されます。

今回はプラグインのレイヤーで衝突しやすい細かい部分を一通り確認しました。次回は検証フェーズです。ブラウザの開発者ツールを使ってキャッシュが本当にCloudflareにヒットしているかを確認する方法、そしてヘッダーの表示がおかしいときにどの方向から原因を調べればよいかについて説明します。