「ブログのキャッシュをCloudflareに移行する」シリーズの第1回です。このブログを3年ほど続けてきましたが、最近AIのアドバイスを参考にフロントエンドの設定をいろいろ調整した結果、QUIC.cloudのキャッシュサービスの無料枠を予定より早く使い切ってしまいました。今回はまだ操作の話はせず、一点だけはっきりさせておきます。なぜ追加料金を払ったり額度のリセットを待つのではなく、CDNキャッシュをCloudflareに切り替えることを選んだのか、という点です。今回変えるのはキャッシュと高速化のレイヤーだけで、サイト本体は元のサーバー上でそのまま動き続けます。
使い切ったのは、あくまで一部
誤解しやすいポイントがあります。額度を使い切った＝LiteSpeed Cacheプラグイン全体が機能しなくなった、と思いがちですが、実際はそうではありません。QUIC.cloudが提供しているのは、それぞれ独立して課金される複数のクラウドサービスです。Page Optimization（ページ最適化。クリティカルCSSの生成、CCSS、UCSSなどを含む）、画像最適化（圧縮、WebP生成）、そしてCDNノードによる高速化です。これらの額度はそれぞれ別々に計算されているため、一つを使い切ったからといって全体が止まるわけではありません。
実際の状況としては、Page Optimizationの額度は使い切ってしまいましたが、画像最適化のほうはまだかなり残っていました。これは重要なポイントです。なぜなら、Cloudflareに切り替えた後にどのクラウド機能をオフにし、どれを残して使い続けるかを判断する基準になるからです——具体的な内容は後の記事で扱います。
QUIC.cloudとCloudflare、CDNのこのレイヤーは両方同時にオンにできない
最初に整理しておくべき問題は、両方を同時に使って互いに補い合えるかどうかです。答えは「完全にはできない」です——どの層を「使う」かによります。両者のCDNノードによる高速化機能は同時に有効にできませんが、QUIC.cloud配下の画像最適化やクリティカルCSS生成といったクラウド補助サービスは、CDN機能をオフにした状態であれば、引き続き単独で利用できます。
理由は、CDNノードによる高速化というこのレイヤーの仕組みが本質的にリバースプロキシだからです。ドメインのDNS解決は、同じ時点では一箇所しか指せません。Cloudflareに渡せば、トラフィックは全てCloudflareのノードを経由するようになり、QUIC.cloudのCDNノードにはリクエストが届かなくなり、実質的に機能しなくなります。このレイヤーで同時稼働が許されないのは、何らかのエラーが直接発生するからではなく、仕組みの上でそもそも同時に機能しえないからです——両者のCDNノードが同時にドメイン解決の最前面に立つことはできません。
つまりこれは「どちらが優れているか」という選択の問題ではなく、仕組みのレベルでCDNノードによる高速化のレイヤーが同時稼働を許さないということです。ただし、両者には役割分担という形での共存があります。外部CDN、DNS、セキュリティ防御はすべてCloudflareに任せ、QUIC.cloudは純粋なクラウド補助ツールとして降格させ、まだ余裕がある画像最適化のような項目だけを担当させる、という形です。これが今回のキャッシュ移行で最終的に採用した方針です。
切り替えた後、パフォーマンスはどう変わるか
これはキャッシュを切り替える前にきちんと理解しておくべきポイントです。Cloudflareへの切り替えは単純に「速くなる」「遅くなる」と一言で言えるものではなく、いくつかの観点でそれぞれ良くなる面と悪くなる面があり、まとめて見て初めて全体像がわかります。
| 観点 | 変化の方向 | 理由 |
|---|---|---|
| 静的リソースの読み込み（画像、CSS、JS） | 速くなる、または同程度 | Cloudflareのグローバルノード数はQUIC.cloud無料版を大きく上回り、ルーティングと配信能力が高い |
| 動的コンテンツの応答（HTMLの最初の応答） | デフォルトでは遅くなるが、設定で改善可能 | Cloudflare無料版はデフォルトでHTMLをキャッシュせず、リクエストが実サーバーまで戻る |
| フロントエンドの細かい最適化（CCSS、LQIPなど） | ローカルサーバーに依存 | これらの機能はQUIC.cloudのクラウド額度に依存しており、CDNの選択とは無関係 |
| アクセス負荷とセキュリティ防御 | 大幅に向上 | Cloudflareは無料のDDoS防御とWAFルールを提供し、悪意のあるトラフィックをエッジ側で遮断できる |
動的コンテンツのこの一項目が肝心です。QUIC.cloudとLiteSpeedは同じ会社の製品で、連携することでWordPressが動的に生成するHTMLページもグローバルノードにキャッシュできます。Cloudflare無料版はデフォルトで静的ファイルしかキャッシュしないため、ユーザーがトップページを開くたびにリクエストが実サーバーまで戻って処理されることになり、サーバーの性能が標準的なものだと、最初の応答までの時間が伸びてしまいます。
この問題は解決不可能ではなく、追加の設定で対応できます。Cloudflareの管理画面でCache Rulesを使って「すべてをキャッシュする」を強制的に有効にする方法もありますし、プラグインを組み合わせてサイト全体のHTMLキャッシュをうまく実現する方法もあります（これは第3回で扱う内容です）。つまり、Cloudflare無料版の動的コンテンツキャッシュ能力は最初から備わっているものではなく、自分で手を加えて補う必要があるということです。
どんなサイトがこの切り替えに向いているか
これはこの方法がすべての人に向いているかどうかを決めるポイントです。普通の個人ブログや企業の公式サイトのように、コンテンツの更新頻度が低いサイトは、Cloudflareとサイト全体キャッシュプラグインの組み合わせに非常に向いていて、切り替えてもパフォーマンスはほとんど感じられないほど変わらず、セキュリティ面は大きく向上します。
一方で、頻繁に更新されるECサイト（WooCommerceなど）や、強い対話性を持つアプリケーションで、複雑なキャッシュルールの設定に手間をかけたくない場合は、QUIC.cloudが持つ元々の互換性のほうが今でも気楽な選択肢かもしれません。なぜなら、QUIC.cloudとLiteSpeedは同じ体系の製品であり、HTMLキャッシュ能力を補うための追加プラグインが不要だからです。
このブログは前者のタイプに当たります。コンテンツの更新はそれほど頻繁ではなく、アクセス数もフラッシュセール級の同時接続に対応する必要はありません。そのため、最終的な判断としてCloudflareに権限の比重を移し、LiteSpeedはローカルツールとして格下げし、サーバー側のコード圧縮と画像最適化に専念させることにしました。
最終的に決めた方針
整理すると、今回のキャッシュ移行で決めた役割分担は次のようになります。
- Cloudflare：外部CDN、DNS解決、セキュリティ防御を一手に担い、追加のプラグインを通じてサイト全体のHTML静的キャッシュを実現する
- LiteSpeed Cache：ローカルツールの役割に戻り、サーバー側のCSS/JS圧縮、データベース最適化を担当する
- QUIC.cloud：CDN機能はオフにするが、まだ余裕のある画像最適化の額度は残し、このクラウドサービスを引き続き活用する
この役割分担によって、無料であることとパフォーマンスの両方を両立させています。次回は具体的な操作方法、すなわちドメインのDNS設定をCloudflareに切り替える手順から、LiteSpeed側での連携設定まで、この方針を一歩ずつ実現していく流れを説明します。
系列文章：ブログキャッシュをCloudflareへ移行
