Cache Rules vs Workers Cache API for conditional HTML caching on Cloudflare

Question

We run a zone where most traffic is HTML pages generated at the origin. Some responses are safe to cache at the edge (anonymous, cacheable status codes), while others must never be cached (responses carrying Set-Cookie or personalized content). The goal is fine-grained, conditional cache control without serving stale personalized pages.

Two documented paths seem available. Cache Rules (the newer replacement for legacy Page Rules) can set cache eligibility, edge TTL, and bypass-on-cookie through dashboard configuration, with no per-request compute cost. The Workers Cache API (caches.default) plus cf properties like cacheKey and cacheTtlByStatus allow programmatic decisions per response, but add invocation cost, code to maintain, and latency on misses.

What is unclear is where the practical line sits: Cache Rules matching appears limited to URL patterns and a fixed set of request fields, so it may not express "cache only 200 responses without Set-Cookie" the way a Worker can. Feature parity between the two also seems to be evolving, and plan limits differ.

Before committing, I would check cf-cache-status on test URLs and review cache analytics hit ratio by content type to confirm misses are the real bottleneck.

Can Cache Rules express response-conditional logic (status code, absence of Set-Cookie), or does that require a Worker?
For high-traffic zones, at what hit ratio does the Worker's per-request cost outweigh the flexibility?
Is there a documented migration path from legacy Page Rules to Cache Rules without behavior changes?

Tasadduq Burney · Answer

Answer
Cache Rules cannot inspect response‑level data such as HTTP status code or the presence of a Set‑Cookie header, so they cannot express the rule “cache only 200 responses without Set‑Cookie”. A Cloudflare Worker using the Cache API is required for that logic.
When does a Worker become cost‑effective?
For high‑traffic zones the per‑request CPU cost of a Worker is noticeable only when the edge‑cache miss ratio exceeds roughly 15‑20 % (i.e., hit ratio < 80‑85 %). Below that threshold the added latency and cost are usually negligible compared with the flexibility gain.
Migration from Page Rules to Cache Rules
Cloudflare provides a one‑click “Migrate Page Rules to Cache Rules” tool in the dashboard. It reproduces matching logic, TTL, cache level and bypass‑on‑cookie settings for pure caching rules. Behavior is preserved as long as the rule does not rely on legacy actions such as URL forwarding, Always Online, or custom headers.
Verification steps (only what you need)

Check current caching behavior: curl -I -H "Host: example.com" https://example.com/your-html-path and look at the cf-cache-status header (HIT, MISS, BYPASS, EXPIRED).
In the Cloudflare dashboard open Analytics → Cache Analytics, filter by content type = HTML, and note the hit ratio. Compare it to the 80‑85 % threshold.
To test migration, enable a legacy Page Rule, click “Migrate Page Rules”, create the matching Cache Rule, then repeat step 1 for both cached and non‑cached requests to confirm identical cf-cache-status and response headers.

Missing diagnostic detail: If you do not know the observed HTML miss ratio (or hit ratio), please provide that number; it determines whether the Worker’s per‑request cost outweighs its flexibility.

Cache Rules vs Workers Cache API for conditional HTML caching on Cloudflare

1 answer

Answer

When does a Worker become cost‑effective?

Migration from Page Rules to Cache Rules

Verification steps (only what you need)

Your perspective belongs here.

0 question comments