Cloudflare Edge初回アクセスを速くする：NitroPack＆Cache Rules&Tiered Cache

2025年10月1日 2025年12月2日

nissy

「UX劣化に伴うコンバージョン率の低下に気づいていない」、「LCPやTTFBの劣化がキャッシュ設計の問題であることに気付くことなく、コンテンツやサーバーのせいにしてしまう」、「PageSpeed Insightsのスコア改善にばかり目が行き、体感速度やCloudflare Edge PoPヒット率の本質を見落としている」などの改善として、この記事は寄与します。

最初に、キャッシュ運用のPreload Cache Warmup（キャッシュ生成）から考えます。

Preload Cache Warmupとは？コンバージョン率との関係性

Preload Cache Warmupは、キャッシュパージ(削除)後、ユーザー訪問よりも速く事前に初回アクセスを行い、CDNのEdgeでCacheを配置するために行います。その後、訪問するすべてのユーザーにCache Hitをもたらすためです。

狙いどうりの訪問者が
狙いどうりのURL(拡張子種類別(メインドキュメントhtml/css/js/画像/フォント))で
狙いどうりのキャッシュEdge(ロケーション)で
狙いどうりのユーザーエージェントで
（狙いどうりのURLクエリパラメータで）
狙いどうりのページコンテンツで

ログインセッションなどのセキュリティ上の機微情報を除き、セキュアに、できるだけ多くの訪問者にCache Hitを返せるようにすることが目的です。

コンバージョン率が不安定な場合、他社があまり手を付けていない安定対策としての技術分野であるため、希少な差別化になります。

Preload Cache Warmup対象URL選定

Webサイトの全てのページに対してCache Warmupをすることが理想ですが、大規模サイトである場合、XMLサイトマップを起点に取得したアセット(css/js/画像/フォント)を含む全URLは数が多いです。この場合、Warmupだけで多くの時間を必要としてしまうため、推奨できません。

そのため、売上やコンバージョンに貢献するページだけ、GA4や追跡ツールなどで絞り出し、そのURLにおけるユーザーエージェントなどのバリアントパターン調査を行い、調査結果に応じたバリアントパターンで集中的にPreload Cache Warmupすることが推奨されます。

これにより、訪問者がモバイルで訪問した際、キャッシュが格納されているCDNエッジから、訪問者のユーザーエージェントに応じたモバイル用のキャッシュをレスポンス出来るようになります。

Cache Warmupでは、Varyヘッダーで指定したバリアントに応じたリクエストヘッダーを付与します。そして事前のGETリクエストを必要なURLに対して行うことで、CDNにキャッシュを乗せて、Cache Missを減らし、Cache Hit率100%を目指します。

広告キャンペーン開始直前のPreload Cache Warmupはメリットが多い

広告キャンペーン開始直前のタイミングで、ランディングページなどの重要URLに対し、fetchによるCache WarmupのGETリクエストでCDNのEdgeにキャッシュを生成するという事が挙げられます。

ユーザー体験が初回訪問者の段階で既に向上している状態にできる
Google広告の品質スコアが改善され、キャンペーン開始直後のGoogle広告アルゴリズムに良い影響を与える可能性
結果的にコンバージョン率の向上に寄与する可能性

Preload Cache Warmupによりオリジンサーバ負荷も減る

Prelaod Cache warmupを行うと「設計した場所にcacheを載せる」ことになります。Preload Cache warmupにより、Cache Hit率が上がるとオリジンサーバへのhttp(s)リクエストが減り、ユーザーへのレスポンスが早くなります。

Preload Cache Warmupが効きにくい代表的なケース

画像ファイルなどアセットファイルの容量が大きすぎる
- 画像は .webp などに変えて軽量な画像に変える
- height、widthを設定する
- モバイルとデスクトップの双方向け画像を読み込まない様にする
- LCP Image Preload扱いしてfetchpriority="high"にする
youtubeなどのiframeが重たい
- ビデオファサード（モバイルでビューの中にyoutubeが入ってきた際は画像で表示、ユーザーのタップにより初めてyoutubeで表示する）の採用

👉️【INP理解】ブラウザアドレスバーURL入力からWebページ表示の全工程と調査で記載した、ブラウザにおける「ダウンロード」、「構文解析」、「javascript実行」、「スタイル計算」、「レイアウト」、「描画」の工程で何らかのボトルネックがあると前工程で詰まってしまい、Preload Cache Warmupが効きにくくなります。

実際、効いてますが、前工程による遅延ボトルネックで効果が無いと誤解されやすいのが「Preload Cache Warmup」です。

Core Web Vitals対策でボトルネックを減らしつつセットで行うことで、UX（ユーザー体験）向上として強力な威力を発揮します。

Preload Cache warmupを実施するタイミング

広告キャンペーン開始直前
- トラフィック急増前に重要ページをEdgeに載せておく
コンテンツ更新によるキャッシュ削除の後（キャッシュパージ(削除)は、完全自動化出来るケースが多い）
- キャッシュ（再）生成のためPreload Cache warmupが必要
コンテンツ新規追加の後
キャッシュのチューニング作業中
Cache Evictionの後
- Cache Warmer 開発をした実観測の経験に基づいて言えることとして、CDNには容量限界があるため、TTLでCDN上のキャッシュ期限を1年と設定していても、アクセス頻度が低いオブジェクトは数時間でキャッシュを削除されてしまうことは多いです。安価なCDNプランほどキャッシュ容量が小さい・Evictionが起きやすい・詳細制御や観測機能が弱いと考えられます（Cloudflareのコスパは良い意味で異常だと考えています）。

など。

NitroPackではPreload Cache Warmupをどうやるか？

NitroPackのCache warmup機能は、選択肢の1つになります。機能として、リクエストURLの選定方式が以下の2種類となります。

NitroPack Preload (Cache) warmupのリクエストURL選定方式（2種類）

Standard
- ヒューリスティック解析によりWebサイト内で人気のあるURLをリストアップ、リストアップされたURLに対してwarmupリクエストを実施。
Sitemap
- XMLサイトマップを登録することで、自動でwarmupリクエストを実施。
- XMLサイトマップ上に記載されている個々のコンテンツ更新日の最新化など、常に正しく機能維持されていること。

NitroPackは、世界中のCloudflare Edgeへのwarmupを出来ているか？

結論として出来ません。NitroPackのCache Warmupは、日本のNRTやKIXのCloudflare Edge の Warmupを出来ません。

検証は、👉️NitroPackのPreload warmupはCloudflare Edgeのキャッシュを暖めるか？にて実施しました。

Preload Cache Warmupとセキュリティ

Preload Cache Warmupは、機能暴走が発生した場合、リクエスト先ドメインのURL一覧を高精度に網羅したDoS攻撃になりうる技術です。高度なGEO分散Warmupまで行って暴走した場合、もはやDDoS攻撃です。少なからず、自爆の危険性があることを自覚しておいて損はないと思われます。

Webサイトへの致命的なダメージ（＝経営ダメージ）に繋がります。Cache Warmerは、脳死で何も考えないと大したことなさそうに感じられますが、精度とセキュリティを意識した選定が経営のために重要です。

WAFを使っている場合、Warmup専用のFetch Proxyを認証機能付きで構築し、WAFで許可する必要があります。基本的にはCloudflare WorkersやAWS LambdaaEdgeなどのサーバレスを使います。

Preload Cache Warmupリクエスト先URLリストとバリアント

Preload Cache warmupの原理自体は非常にシンプルですが、warmupリクエスト送信パターンの洗い出しを行わないとCache Hit率を改善出来ません。

Preload Cache Warmupは、1個1個のURLページに対して1回だけのリクエストを行うわけではないです。1個のURLページに対し、モバイル/デスクトップとして異なるユーザーエージェントによる複数回のWarmupリクエストを実施します。デバイス種類別などバリアントパターンを調査し、バリアントパターンを網羅するようにWarmupリクエストすることが望まれます。

よくあるCache Warmerの現実【薄い効果】

以下、Github上の様々なCache Warmerを試して把握できた事実です。

1個のURLページの中にはサブリンクとしてのアセット（css/js/画像/フォント）があり、世の中の大多数のCache Warmerはアセットではなく1個のURLページだけをWarmupする仕様です。UX向上として重要なアセット（css/js/画像/フォント）をWarmup出来ないため、この場合、Cache Warmupによる恩恵をしっかり得られません。

キャッシュヒット率を初回訪問から爆上げするCache Warmerを開発しました

アセットをWarmupできないとWarmup効果は、かなり下がるため、XMLサイトマップをもとにアセットを含む高精度Cache Warmerを開発しました。

👉️キャッシュHit率を初回訪問から爆上げ「高精度CacheWarm&Checker Nissy」モニター募集

ローカルn8nによるCache Warmupであるため、実行する地域のCDN Edge PoPだけをWarmupすることになります。CDNのEdge PoPは世界中に存在するため、GEO分散Cache Warmupが必要な場合、アーキテクチャのレベルがまったく変わります。

NitroPackのwarmupはUnitedKingdom周辺地域で網羅すべきバリアントを満たす仕様

NitroPackは、欧州でホスティングしているWEBサーバに対してPreload warmupを行う場合に限り、コンテンツ圧縮（エンコーディング）を含め、ユーザー体験に影響する主要なバリアントに対応するよう設計されていて精度は高いと言えます。しかし、UK（英国）からリクエストが行われるため、日本国内のユーザーを模したPreload warmupではないため、日本国内でホスティングしているWEBサーバに対してはWarmup効果が有りません。

キャッシュ対象として検討するバリアント

No.	バリアント	概要	例	NitroPack
01	User-Agent	デバイスの種類（PC、スマートフォン、タブレット）やブラウザによって異なるコンテンツのキャッシュを生成させる	モバイルとデスクトップでHTML/CSS/JSを出し分け。 Vary: User-Agent	モバイル／デスクトップ
02	Accept-Encoding	サーバーがサポートする圧縮形式（Gzip, Brotliなど）によって異なるエンコーディングバージョンのコンテンツのキャッシュを生成させる	Accept-Encoding: gzip Accept-Encoding: br	両方に自動で対応している。
03	Cookie/認証	ログイン状態やユーザー設定に基づく各パターンのコンテンツのキャッシュを生成させる。 ※ログイン認証済みコンテンツの(エッジ)キャッシュ化は、必ず避ける必要があるため、パーソナライズされていないPublicなCookieを対象とすることが基本。	言語設定や地域設定のCookie	動的コンテンツのクッキー対応（EX:言語と通貨）、Cookie除外、共に可能
04	クエリパラメータ	URLのクエリパラメータでコンテンツを出し別けている場合、パターン別のコンテンツのキャッシュを生成させる。 ※全クエリパラメータではなく、Publicなクエリパラメータのみが対象。	`?utm_source=...`などの追跡用ではない、コンテンツ表示に関わる`?sort=price`や`?view=list`など	デフォルトで無視されるパラメータが既に有り※直下Informationにリンクを記載。必要に応じて、個別に無視(除外)設定可能。
05	言語	Accept-LanguageヘッダーやURLパス/サブドメインによって異なるコンテンツのキャッシュを生成させる	日本語（`/ja/`）と英語（`/en/`）のページなど	XMLサイトマップに記載されていれば自動で対応。

除外登録は、（クエリパラメータを含む）URL、cssファイル、javascriptファイル、javascriptのソースコードの一部（ブロックの先頭1行など）、画像ファイル、Cookieなどで柔軟に出来ます。Cookie除外はNitroPack Straterプランではできないです。

Information

Ignored Parameters | NitroPack Help Center

NitroPackサーバの各AgentによるCache purge(Optimization)/Preload (Cache) warmupのhttp(s)リクエスト概要

日本のオリジンサーバにNitroPack(Starterプラン)を導入、APIを含むドキュメントを読み、リクエストログを見て、実際の最適化キャッシュを見てわかったことをまとめます。Starterプランレベルなのにjavascript/cssの最適化で行っていることが良い意味で半端ないです。CoreWebVitals改善への貢献度が高く、コスパの高いSaas製品であると断言出来ます。ここに記載したもの以外では、ハートビート、暗号化、キャッシュのバージョン管理などの実装も見られ、CoreWebVitalsは監視やセキュリティサービスに近い領域まで深く連携が必要なことがわかります。WordPressのNitroPackプラグイン内のSDKが最適化などの処理をしているので、自前で開発するならWEBサーバとは別で最適化処理専用サーバ(コンテナ)、DBにElastiCache、Egress削減を意識してCDNはCloudflareを使う、などがインフラ設計の検討事項の一部になると考えられます。

No.	ユーザーエージェント(UA)	メソッド	目的等	クエリ文字列	リクエストのパス	発信元
1	Nitro-Webhook-Agent	GET	キャッシュパージ(削除) ※最初にxmlサイトマップをGET。更新日時を確認。最新warmup以降で更新確認出来なければ ignore。	nitroWebhook=cache_clear	トップページ&XMLサイトマップ	UK
2	Nitro-Optimizer-Agent	GET	最適化（Critical生成、圧縮、遅延読み込み、CSS分割と段階的適用、ユーザー操作優先js制御、preloadアセット制御、UA種類別生成、HSTS、観測制御、Blob URLなど）	cssやjsの場合：ver= 除外の場合：ignorenitro=	メインドキュメント(html)、js、 css等の個々のファイルパス	UK
3	Nitro-Webhook-Agent	POST	NitroPackのPage Optimization Status で Complete(最適化完了)通知	nitroWebhook=cache_ready	トップページのみ	UK
4	Nitro-Warmup-Agent	POST	NitroPack Preload warmupでXMLサイトマップが登録/更新される	nitroWebhook=config	トップページのみ	UK
5	Nitro-Warmup-Agent	GET	xmlサイトマップ確認 ※更新日時を確認。最新warmup以降で更新確認出来なければ ignore。	無し	XMLサイトマップ	UK
6	Nitro-Warmup-Agent	GET	オリジンサーバ内のキャッシュ生成（モバイル/デスクトップ別）	除外の場合：ignorenitro=	メインドキュメント(html)の個々のファイルパス	UK
7	Nitro-Webhook-Agent	GET	NitroPackの各種設定変更。ヘルスチェック。	nitroWebhook=config	トップページのみ	UK

発信元UKはCloudflareのログで確認しましたが、さらに根拠となるNitroPack公式公開IPアドレスは後述しています。

Warning

NitroPackのPreload warmupは、実際のユーザーヒットを模倣し、短時間で多数の URL にアクセスします。そのため、CPU使用率の急上昇に注意が必要です。 NitroPack公式には、トラフィック上位10～20%のURLを調べてカスタムXMLサイトマップを作成してNitroPack Preload warmupに登録する、もしくは、理想的なロジックではないですが上述「Standard」に変更するという2案が記載されています。

NitroPackのwarmup(リクエスト)機能は、NitroPackサーバが配置されているエリア（日本は含まれず）からwarmupリクエストが実施されます。日本のNitroPackユーザーであれば、各種Nitro-XXX-Agentへのリクエスト発信元は、基本的にUKです。

Information

NitroBot Bot Information | Cloudflare Radar

NitroPackによる最適化/NitroCDN

NitroPackのWarmupは、最適化されたメインドキュメント(html)をオリジンサーバ内にキャッシュ生成します。調査確認中ですが、おそらくキャッシュパージ（最適化を含む）の段階でメインドキュメント(html)に含まれる各種アセット(css,jvascriptファイルなど)はNitroCDNに配置されている可能性があります。事前にNitroPackで除外登録しておいたアセット(URL、css、javascript、画像、Cookieなど)は最適化から除外され、warmup以降も最適化されずオリジンサーバのオリジンコンテンツとして有り続けます。

※NitroPackによる最適化の除外有無に関わらず、Cloudflare Edgeに載せられますが、2025/11ころのCloudflare障害の前日から当日くらいにかけて、一時期、NitroCDNのアセットがCloudflareに載らない時が有りました。

NitroPack preload cache warmup

Information

NitroPackのwarmupは、デスクトップ、モバイルでユーザーによるWEBサイト訪問をシミュレートします。さらに、事前定義されたバリエーションCookieとその値によって実施される可能性があるリクエストもすべてWEBサイト訪問がシミュレートされます。

Cache Warmup (WordPress) | NitroPack Help Center

How NitroPack Works

日本など、NitroPackがwarmupリクエストを実行するUKのサーバのエリア外に有るCloudflareのエッジ（データセンター）は、リクエストがNitroPackから届かないため、日本はキャッシュパージ後、初回訪問のキャッシュミス発生が想定されます。尚、Cloudflare APOを使うと改善するらしく未検証ですが、とても興味があります。

日本国内からアセットを含むCache Warmupリクエストを実施出来る場合、Cloudflare スマート階層型キャッシュトポロジー（後述）を併用することでCloudflareのTier 1キャッシュが保証され、ユーザー体験の安定に寄与します。

Information

Cloudflareは世界中にデータセンターが有り、物理的にユーザーに近いデータセンターに静的コンテンツをキャッシュする。

Get started with Cache · Cloudflare Cache (CDN) docs

同じURLでもバリアント別（デバイス種類・圧縮方式・言語・Cookie・地域等）で異なるコンテンツを出力する場合、それぞれ別キャッシュとして対応する必要は、前述で理解いただけたと思います。

バリアントに合致するキャッシュがCloudflareエッジやNitroCDNに無いと、キャッシュミスが発生し、オリジンサーバへのリクエストが発生し、キャッシュHit率が低下します。NitroPackとCloudflareを利用する場合、以下の様なキャッシュ配置場所戦略をオススメします。記事更新のキャッシュパージは、NitroPackではWordPressプラグインで自動連携、Cloudflareのみ手動です（おそらくNitroPackのWebhookや Cloudflare APIを使って自動化出来ると考えられますが、まだ、そこまで開拓出来ていません）。

セキュリティを考慮したトークン認証付きでCloudflareへのCache Warmするやり方は、👉Core Web Vitals検証用：海外からcurl＆Firefoxを叩く最安構成でご紹介しています。

キャッシュ配置場所戦略

運用継続することで、これらの最適な戦略が見えてきました。運用もコストも大きな負担がなく現実的です。尚、オリジンサーバ側では.htaccessに記載する保持期間を除き、一切キャッシュ機能を使っていません。

NitroCDN
- NitroPack最適化対象アセット(css/js/画像/フォントなど)
  - css/jsの圧縮や最適化など、NitroPackの得意分野に特化して利用
Cloudflare Edge PoP
- NitroPack最適化対象外の静的アセット(css/js/画像/faviconなど)、NitroPackによってオリジンサーバ内に生成された最適化済メインドキュメント(html)
  - CDNの基本である画像キャッシュを最重視。
  - メインドキュメント(html)は、セキュリティ性を優先してキャッシュしない方針とすることも尊い選択肢。

検証用curl

# Desktop想定
curl -I https://example.com/ \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 Chrome/124 Safari/537.36"

# Mobile想定
curl -I https://example.com/ \
  -H "User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Version/17.0 Mobile/15E148 Safari/604.1"

curl確認ポイント

x-nitro-cache
- HIT：NitroPack のキャッシュから配信。
- MISS：NitroPack のキャッシュが無く、オリジンから配信。

cf-cache-status（PoPでのキャッシュヒット状況）
- DYNAMIC：コンテンツが設定的にCloudflareキャッシュ対象外。拡張子による識別。
- BYPASS：本来Cloudflareキャッシュしたいが、オリジンサーバの Cache-Control/Cookie/Authorization などの条件で回避。
- HIT：Cloudflareエッジのキャッシュから配信。
- MISS：Cloudflareキャッシュに無く、オリジンから取得して配信。
- EXPIRED：Cloudflareキャッシュにあったが期限切れ。オリジンから取得して配信。
- STALE：期限切れのCloudflareキャッシュを配信（オリジンに到達できない等）。
- REVALIDATED：古いが If-Modified-Since / If-None-Match で再検証してCloudflareキャッシュから配信。
- UPDATING：オリジンサーバにて更新中で期限切れだがCloudflareキャッシュから配信。とても人気があるキャッシュリソースでよく見られる事象。
- NONE / UNKNOWN：Cloudflareキャッシュ対象外の応答（Workers が直接応答、WAFカスタムルールによるブロック/リダイレクト等でキャッシュに到達しない等）

参照元：How to Check if NitroPack is Serving Optimized Pages to Visitors

参照元：Cloudflare cache responses · Cloudflare Cache (CDN) docs

NitroPack公式公開IPアドレスと地域推測 2025/10/1現在

NitroPack公式で公開されているIPアドレスは、How to Allowlist NitroPack’s IP Addressesより確認できます。

※公開されているIPアドレス情報に基づく推測です。

NitroPack 公開IP	推定地域
178.62.81.205	欧州
46.101.77.196	欧州
178.62.71.222	欧州
159.65.180.53	欧州
34.89.113.53	欧州
34.147.235.168	欧州
35.246.2.61	欧州
104.154.182.50	欧州

公開されている情報の限りでは日本が存在しないため、NitroPackのpreload cache warmupを行っても日本でキャッシュミスが起きます。実際に、オリジンサーバへコンテンツリクエストしているケースをにしラボでは確認済です。ページビューが少ないWebサイトほど目立ちます。

NitroPack Preload Cache Warmup と Cloudflareスマート階層型キャッシュトポロジー

ここから、GEO分散ではないNitroPackのPreload warmupをCloudflareでどのように補完していくか？という視点で読み進めてください。

Tiered Cache / Argo / Smarter Tiered Cache Topologyは、密接に関係していて異なる機能の様です。

階層型キャッシュ（Tiered Cache）は、Cloudflareのデータセンターを下位層と上位層の階層に分割することで機能します。下位層（通常は訪問者に最も近いデータセンター）にコンテンツがキャッシュされていない場合、下位層は上位層にコンテンツがあるかどうかを確認する必要があります。上位層にコンテンツがない場合、上位層のみがオリジンにコンテンツを要求できます。この仕組みにより、オリジンにコンテンツを要求できるデータセンターの数を制限することで帯域幅効率が向上し、オリジンの負荷が軽減され、ウェブサイトの運用コストが向上します。

さらに、Tiered Cache はオリジンサーバーへの接続を集中させ、ネットワーク上の全拠点ではなく少数のデータセンターからの接続に絞り込みます。これにより、サーバーリソースを使用するオープン接続の数が減少します。

Tiered Cache · Cloudflare Cache (CDN) docs

Cloudflareの「階層型キャッシュ（Tiered Cache）」は、エッジ群を下位層T2と上位層T1の階層に別け、下位層T2 PoP（ユーザー最寄りエッジ）がMISSしたら、上位層T1 PoPにキャッシュを取りに行く、上位層にも無ければ最後にオリジンにコンテンツを取りに行きます。


# キャッシュ設計の全体像

[User (Browser)/NitroPack Preload warmup]
    │
    ▼
[Cloudflare Edge PoP/ 下位層 T2 (ユーザーに最も近い位置にあるデータセンター)]
    │ (Cache MISSなら上位層 T1へ)
    ▼
[Cloudflare / 上位層 T1（オリジンごとに1つ）]
    │ (Cache MISSならメインドキュメントはオリジンサーバ、アセットは NitroCDNへ)
    ▼
[NitroCDN (css/js/画像/フォントのアセットのみ）]
    │ (Cache MISSならオリジンへ)
    ▼
[オリジンサーバ(LoadBalancer有でも同じキャッシュ構成で考えてOK)]

①メインドキュメント(html)→オリジンサーバ内にNitroPackによる最適化済キャッシュが生成される。
②css,js,画像,font→最適化されNitroCDN（https://cdn-ileamdm.nitrocdn.com/...）上にキャッシュ生成。
③LCP画像→オリジンサーバ内でそのまま残留。LCP Image Preload機能は自作であるため、LCP画像はCloudflareに任せる設計としてNitroPack側で最適化除外）

各下位層T2 PoP の初回キャッシュミス時、オリジンサーバではなく上位層T1から下位層T2がキャッシュを取得することでTTFBを短縮出来る仕組みとなります。

スマート階層型キャッシュトポロジーは、「Tiered CacheがArgoのパフォーマンスとルーティングデータを使用し、オリジンに最適な単一の上位階層を動的に見つける」といった機能を示しているようです。NitroPackのPreload warmupを行うサーバが日本に無くても、スマート階層型キャッシュトポロジーが「下位層 T2」と「上位層 T1」のミスマッチを避けてくれます。

Information

Smarter Tiered Cache Topology（スマートな階層型キャッシュトロポジー）の生成の紹介

Cloudflareドキュメントを参考に、計測と運用をしてきた限りではスマート階層型キャッシュトポロジーは地理エリアごとに上位層のT1が存在する為、グローバルで複数T1状態となっていてHit率の改善余地が有る様です。

地域ごとに上位層のT1が複数存在する状況から、オリジンに最適な上位層をグローバルで1つだけとすることでHit率の向上に寄与する機能は別で、おそらく、これがArgo Smart Routingではないかという現状の見解です。

私の環境はCloudflare freeプランで、Argoは動いていない、階層型キャッシュのみ有効、この状態でNitroPackのPreload warmupは、日本のCloudflareのEdge を一切暖められません。

NitroPackのサポートボットでは、CloudflareのAPOを使ってNitroPackとCloudflareの整合性を確保してください、と言った返答をもらっています。具体的な調査と結論は下記の記事で公開しています。

Information

NitroPackのPreload warmupはCloudflare Edgeのキャッシュを暖めるか？

スマート階層型キャッシュトポロジー設定

（特定のドメイン）ゾーン単位の設定となります。

Cloudflare > (特定ドメインの)ゾーン > Caching > 階層型キャッシュ > 階層型キャッシュトポロジー > スマート階層型キャッシュトポロジー > 有効化。

スマート階層型キャッシュトポロジーの例外

オリジンがエニーキャスト、またはリージョナルユニキャストネットワーク構成である場合、Cloudflareから見てオリジン所在地不明となるため、最適な上位層 T1を選択できないです。大規模なプロジェクトに限られると考えられます。

Cloudflareにおけるキャッシュミス対策

メインドキュメント(html)は、Cloudflareをキャッシュ配置の本拠地とする設計にしているめ、次の機能を設定します。

「NitroPack の各種最適化」、「Cloudflare スマート階層型キャッシュトポロジー」に加えて「Cloudflare Cache Rules」を組み合わせて運用することで、キャッシュヒット率を改善できます。

モバイルとデスクトップでhtml構造の差がないという状況で、NitroPackキャッシュパージにより画像ファイルが早期にCloudflare Edgeに乗るため、素のメインドキュメントhtmlでLCP/INP/CLSのスコアが良い状況と相性が良いです。

Cache Rules

Information

キャッシュキーを使う場合、「Cache Deception アーマー」による「Web Cache Deception 攻撃」に対する保護を有効化することを強く推奨します。

Warning

この設定は最低限の検証を終えた段階のものです。絶対に本番環境で利用しないでください。キャッシュルールの設定は、正しく行わないと意図せず公開するべきではない情報公開につながる可能性があります。ログイン済みユーザーのセッション情報、記事プレビュー、下書き状態記事、その他の編集中画面、ユーザー毎の個々のページなど、セキュリティを考慮した精緻な設計が必要です。検証終了版は、お問い合わせください。

「スマホとPCで同じURLにアクセスしても、Cloudflareが同じキャッシュを返す場合、レイアウト崩れや不要な再レンダリングが発生します。デバイス種類別のHit率を上げるため、Cloudflare Cache Rulesでモバイル/デスクトップ/タブレットで別となるキャッシュキーを設定し、NitroPackのデバイス別キャッシュとの整合性を確保します。

Danger

キャッシュルールは、後勝ちであるため安全を最優先し、デバイス別キャッシュを1番目に除外付きで配置、その後にキャッシュバイパスを設定します。競合する設定については最後に一致したルールが優先されます。「キャッシュバイパスが必ず後勝ちするセキュリティ性を最優先した設計」はユーザーに対するサービス提供側のセキュリティ責任です。

Cloudflare Cache Rules（NitroPack / WordPress）の設定と解説

上位から順番にCache Rule 5個を紹介します。

※運用性とセキュリティの確保には、さらなるチューニングが必要です。

1) 公開ページのみ「デバイス別キャッシュキー」によるキャッシュ

目的：メインドキュメント(html)もCloudflare Edgeにキャッシュして、Desktop / Mobile などを別キーで安定HIT。

受信リクエストが一致する場合：カスタムフィルタ式

※ sample.com は環境に応じて変えてください。コメント投稿者は考慮していません。

(http.host contains "sample.com")
and not (starts_with(http.request.uri.path, "/wp-admin/"))
and not (starts_with(http.request.uri.path, "/wp-login")) 
and not (starts_with(http.request.uri.path, "/wp-json/"))
and not (ends_with(http.request.uri.path, "/feed/"))
and not (ends_with(lower(http.request.uri.path), "sitemap.xml"))
and not (http.request.uri.path contains ".php")
and not (http.request.uri.query contains "nocache")
and not (http.request.uri.query contains "s=")
and not (http.request.uri.query contains "p=")
and not (http.cookie contains "wordpress_logged_in_")
and not (http.cookie contains "wordpress_sec_")

キャッシュの適格性：キャッシュの対象

エッジTTL：キャッシュ制御ヘッダーを無視し、この TTL を使用します→2時間

ブラウザTTL：キャッシュをバイパスする

キャッシュキー：

Cache Deception アーマー → 有効化
デバイスの種類別のキャッシュ → モバイル／タブレット/デスクトップでデバイス別のHit率を突き詰めたい場合に有効化。
クエリー文字列を無視する → 無効

Warning

「クエリー文字列を無視する」を有効化する際は、Cloudflare公式ドキュメント　Cache Everything while ignoring query strings　を参考にして検討が必要です。

クエリ文字列の並べ替え → 有効化
- クエリパラメータの順序に関係なく、同じクエリパラメータを持つリクエストを同様に処理。

解説：

NitroPack がデバイス別最適化（モバイル/デスクトップ向けメインドキュメントのHTML）されたキャッシュをオリジンサーバ内に作るため、Cloudflare側もデバイス種類別にキャッシュ対応しないとHTML誤配が発生し、スコア乱高下の元になります。
- モバイル判定の基準がNitroPackとCloudflareの双方で合致しているか？確認が必要です。
- エッジTTLでオリジンの no-store/no-cache を上書き、メインドキュメント(html)をCloudflareエッジでHITさせる。
ブラウザTTLのキャッシュバイパスは、サービス提供側でキャッシュを制御しにくい状況を避けるため。利用しないようにしています。
カスタムフィルタ式において、and not による除外で「プレビュー画面」など、/wp-admin/ではないが公開されるべきではないパラメータクエリをキャッシュさせない様に、セキュリティ確保が最重要です。
- 【注意】REST APIのエンドポイントの除外は未記載です。
- Cache Ruleの除外設定を適切に行ったうえでCacheすることは難易度が比較的に高いため、2)以下のBYPASSルールだけを採用し、セキュリティのリスクを避けることも正しい戦略だと考えられます。

Information

※ Cache by Device Typeを参考に設定します。

2) 管理画面・ログインクッキー・プレビュー画面・エンドポイント関係等は常にBYPASS

目的：記事編集画面のプレビュー・ログインクッキー・管理画面系を絶対にキャッシュしない（セキュリティ確保）。

受信リクエストが一致する場合：カスタムフィルタ式

(starts_with(http.request.uri.path, "/wp-admin/"))
or (starts_with(http.request.uri.path, "/wp-login"))
or (starts_with(http.request.uri.path, "/wp-json/"))
or (ends_with(http.request.uri.path, "/feed/"))
or (ends_with(lower(http.request.uri.path), "sitemap.xml"))
or (http.request.uri.path contains ".php")
or (http.request.uri.query contains "p=")
or (http.request.uri.query contains "nocache")
or (http.cookie contains "wordpress_logged_in_")
or (http.cookie contains "wordpress_sec_")

キャッシュの適格性：キャッシュをバイパスする

3) マーケティング系トラッキングパラメータをBYPASS

目的：マーケティングや追跡系のトラッキングパラメータを含むURLはキャッシュしない（Google広告、Facebook広告、その他のUTMパラメータなど）

対象例：utm_source, utm_medium, utm_campaign, utm_term, utm_content, gclid, fbclid など。

受信リクエストが一致する場合（式のプレビュー）

(http.host contains "sample.com")
and (
  http.request.uri.query contains "utm_source="
  or http.request.uri.query contains "utm_medium="
  or http.request.uri.query contains "utm_campaign="
  or http.request.uri.query contains "utm_term="
  or http.request.uri.query contains "utm_content="
  or http.request.uri.query contains "gclid=" #Google
  or http.request.uri.query contains "fbclid=" #Instagram(Meta)
  or http.request.uri.query contains "twclid=" #X(Twitter)
  or http.request.uri.query contains "ttclid=" #TikTok
  or http.request.uri.query contains "msclkid=" #Microsoft
  or http.request.uri.query contains "dclid=" #Google Marketing Platform
)

キャッシュの適格性：キャッシュをバイパスする

4) NitroPack の内部クエリをBYPASS

目的：NitroPackによるページ最適化やPurge CacheのリクエストがCloudflareによってキャッシュされないようにする。※日々の運用で基本的に発生していないですが、念の為。

受信リクエストが一致する場合：カスタムフィルタ式

受信リクエストが一致する場合（式のプレビュー）

lower(http.request.uri.query) contains "nitro"

キャッシュの適格性：キャッシュをバイパスする

解説：

実際に curl -I やhttp(s)リクエストのログで NitroPackが付ける内部クエリを観測してユーザーエージェントなどを確認するとより良い記載が可能です。
- grepによるNitroPackプラグイン内のクエリパラメータ調査も有効です。
s=（検索）をここでは混ぜないで、検索は次ルールで扱います。

5) WordPress内の検索を BYPASS

目的：検索結果は都度生成されるため、BYPASSします。

受信リクエストが一致する場合：カスタムフィルタ式

(http.request.uri.query contains "s=")

キャッシュの適格性：キャッシュをバイパスする

Cache Reserve

Cloudflare R2上の永続的なデータストア。Tiered Cache と併用することで、上位層 T1 PoPにも無い時の最後のキャッシュ倉庫になり、オリジン到達とエグレスを更に削減可能。リクエスト数が多くなければ比較的に安いため、多層フォールバック対策として導入検討しやすいです。

[End User] → [T2] → [T1] → (MISS) → [Cache Reserve] → (MISS) → [Origin]
                       ↑      　           ↓
                       └────────(HITならT1へ返却)

ストレージ	0.015ドル / GB/月
クラス A オペレーション (writes)	100万リクエストあたり4.50ドル
クラス B オペレーション (reads)	100万リクエストあたり0.36ドル

参照元：Cache Reserve · Cloudflare Cache (CDN) docs

Information

AWS’s Egregious Egress ← Cloudflare Co-founder & CEO of Cloudflare Matthew Prince 氏のAWSエグレス料金（アウトバウンドのネットワーク転送料金）に関する世界的に有名な話

にしラボ式のCore Web Viltals対応

👉PageSpeedモバイルスコア100を実現したFCP/LCP/TBT/CLSにしラボ式施策22

📩CoreWebVitals改善相談

👉CoreWebVitals改善相談

カテゴリー: CoreWebVitals

タグ: CDN CloudFlare NitroPack PageSpeed Insights Preload Cache Web高速化パフォーマンスチューニング