Cloudflare Cache Rules vs the Alternatives: Which to Choose in 2026

Cloudflare Cache Rules launched as a dedicated interface for managing edge cache behavior, but they sit alongside several older and alternative mechanisms. If you're hosting sites behind Cloudflare or managing client infrastructure, you've likely wondered whether to migrate from Page Rules, write custom Workers logic, or lean on origin server caching instead. This guide compares the leading options with a clear decision framework.

Understanding the Landscape

Cloudflare offers multiple ways to control what gets cached at the edge and for how long:

• Cache Rules – the current recommended interface for cache configuration
• Page Rules – the legacy rule engine that combines caching, redirects, and other behaviors
• Cloudflare Workers – JavaScript at the edge with full Cache API access
• Origin Cache-Control headers – server-side directives that Cloudflare respects by default
• Configuration Rules – newer rule engine for settings like origin cache control and Polish

Each approach has distinct trade-offs in flexibility, performance, maintenance burden, and cost.

Cloudflare Cache Rules

Cache Rules are the native, purpose-built interface for edge caching introduced to replace the caching subset of Page Rules. They provide granular matching conditions and cache actions without the overhead of scripting.

When Cache Rules Make Sense

• You need to override default cache behavior for specific paths, query strings, or file types
• You want to cache HTML or other dynamic content at the edge
• Your caching logic is declarative: if request matches X, apply cache TTL Y
• You prefer a GUI-driven workflow with rule ordering and clear precedence
• You want Free or Pro plan features without Worker invocation costs

Strengths

• No execution overhead: rules evaluate before the request hits a Worker or origin
• Predictable cost: included in all plans with generous limits
• Clear UI: drag-and-drop ordering, filter builder, and simulation tools
• Eligibility control: set cache TTL, bypass cache, or respect origin headers per rule
• Query string handling: normalize, ignore, or include specific parameters in cache keys

Limitations

• Static logic only: you cannot read cookies, perform calculations, or make conditional decisions beyond the filter criteria
• No custom cache keys beyond query strings: cannot key by header values or request body
• Rule limits: Free plans cap at a small number of Cache Rules; Pro and Business tiers offer more
• No response modification: Cache Rules cannot alter response headers or body before caching

Example Configuration

Cache everything under /api/public/* for one hour, ignoring all query strings:

Field: URI Path
Operator: starts with
Value: /api/public/

Then:
  Cache eligibility: Eligible for cache
  Cache TTL: 1 hour
  Query string handling: Ignore all

Page Rules

Page Rules are Cloudflare's original rule engine, combining caching, security, performance, and redirect settings in a single interface. They remain available but are largely superseded by specialized rule products.

When Page Rules Still Apply

• You're on a legacy configuration and migration isn't urgent
• You need to bundle multiple settings (cache + redirect + security level) in one rule
• Your site has fewer than the plan's Page Rule limit and you prefer familiar tooling

Strengths

• Bundled actions: one rule can set cache level, browser cache TTL, security level, and more
• Mature and stable: behavior is well-documented and unchanged for years
• Wildcard matching: simple glob patterns cover most use cases

Limitations

• Strict rule limits: Free plans include very few Page Rules; additional rules require paid plans
• No advanced matching: cannot filter by request method, header presence, or cookie values
• Rigid precedence: rules execute top to bottom; last match wins for conflicting settings
• Deprecated for caching: Cloudflare recommends migrating cache-specific logic to Cache Rules

Migration Path

Cloudflare's dashboard offers a migration tool to convert Page Rules into Cache Rules and Configuration Rules. The process preserves cache TTL, bypass cache, and cache level settings while splitting non-cache actions into separate rule types.

Cloudflare Workers

Workers are JavaScript functions that execute at Cloudflare's edge before requests reach your origin. They offer the Cache API for programmatic cache reads, writes, and purges.

When Workers Are the Right Choice

• You need conditional caching based on cookies, headers, or computed values
• You want to construct custom cache keys from arbitrary request properties
• You're building dynamic responses or modifying content before caching
• You need to integrate with external APIs or KV storage to determine cache behavior
• You require sub-request caching or parallel origin fetches

Strengths

• Full programmability: any logic JavaScript can express
• Custom cache keys: hash any combination of URL, headers, body, or geo data
• Response transformation: modify headers, rewrite HTML, or stitch multiple origins before caching
• Subrequests: fetch from multiple origins, cache each independently, and compose a single response
• KV and Durable Objects integration: persist state or configuration that influences cache decisions

Limitations

• Invocation cost: Workers incur per-request charges after free tier limits
• Complexity: requires JavaScript knowledge, testing, and version control
• Cold start potential: although minimal, execution latency exists
• Cache API nuances: you must explicitly call cache.put() and handle cache.match() yourself

Example Worker

Cache API responses for authenticated users with a custom cache key:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const cache = caches.default;
  const userId = request.headers.get('X-User-ID');

  // Custom cache key includes user ID
  const cacheKey = new Request(
    `${request.url}?user=${userId}`,
    request
  );

  let response = await cache.match(cacheKey);

  if (!response) {
    response = await fetch(request);
    const headers = new Headers(response.headers);
    headers.set('Cache-Control', 'public, max-age=300');
    response = new Response(response.body, {
      status: response.status,
      headers
    });
    event.waitUntil(cache.put(cacheKey, response.clone()));
  }

  return response;
}

Origin Cache-Control Headers

Your origin server can send Cache-Control, Expires, and ETag headers that Cloudflare respects by default. This approach keeps cache logic at the application layer.

When Origin Headers Are Best

• Your application framework already emits appropriate cache headers
• Cache rules vary by business logic that's easier to express in code than in edge rules
• You want a portable caching strategy that works across CDNs or without a CDN
• You're caching APIs where each endpoint has unique TTL requirements

Strengths

• Portability: works with any CDN or reverse proxy, not just Cloudflare
• Application-aware: your code knows when data changed, so it can set precise TTLs
• No rule limits: every response can have unique cache directives
• Standard compliance: uses HTTP standards understood by browsers and intermediaries

Limitations

• No central visibility: cache policy is scattered across application code
• Origin dependency: Cloudflare must honor what the origin sends; overriding requires Cache Rules or Workers
• Difficult auditing: changes require code deployments rather than dashboard edits
• Limited control: cannot selectively ignore query strings or normalize cache keys without edge logic

Example Nginx Configuration

Set cache headers for static assets:

location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
    expires 7d;
    add_header Cache-Control "public, immutable";
}

Comparison Table

Feature	Cache Rules	Page Rules	Workers	Origin Headers
Setup complexity	Low	Low	High	Medium
Execution cost	Included	Included	Per-request	Included
Rule/plan limits	Moderate	Strict	Generous	None
Custom cache keys	Query string only	No	Full control	No
Conditional logic	Filter-based	Pattern match	Any JavaScript	Application code
Response modification	No	No	Yes	Yes
Portable across CDNs	No	No	No	Yes
Best for	Declarative overrides	Legacy bundled rules	Complex logic	App-native caching

Decision Framework

Use Cache Rules when:

• Your caching needs fit declarative if-then logic
• You want to cache dynamic content without scripting
• You need to override origin headers for specific paths or file types
• You prefer GUI-based rule management

Use Page Rules when:

• You're already using them and don't need advanced features
• You need to bundle cache settings with redirects or security rules
• Your rule count stays within plan limits

Use Workers when:

• Cache decisions depend on cookies, computed values, or external data
• You need custom cache key construction beyond query strings
• You're transforming responses before caching
• You require integration with KV, Durable Objects, or external APIs

Use origin headers when:

• Cache policy is tightly coupled to application logic
• You want a CDN-agnostic approach
• Your framework emits correct headers by default
• You need per-endpoint TTL control without rule sprawl

Hybrid Approaches

Many production setups combine methods:

• Origin headers + Cache Rules: origin sets defaults; Cache Rules override for special cases (e.g., force cache for specific static assets, bypass for admin paths)
• Cache Rules + Workers: Cache Rules handle 90% of traffic with simple logic; Workers handle authenticated or geo-specific edge cases
• Configuration Rules + Cache Rules: use Configuration Rules to control origin cache control behavior, then apply Cache Rules for edge TTL overrides

This layered approach minimizes Worker invocations while preserving flexibility for complex scenarios.

Migration and Maintenance

If you're migrating from Page Rules:

1. Audit existing Page Rules in the Cloudflare dashboard
2. Use the built-in migration tool to convert cache-related rules to Cache Rules
3. Test the new rules with Cloudflare's rule simulation tool
4. Monitor cache hit rates and edge response times after cutover
5. Delete legacy Page Rules once the migration is validated

If you're adopting Workers:

1. Start with non-critical paths to test Worker behavior and latency
2. Implement proper error handling and fallback to origin
3. Use waitUntil() for cache writes to avoid blocking the response
4. Monitor invocation counts and adjust logic to stay within budget
5. Version your Workers code in Git and use Wrangler for deployments

Common Pitfalls

• Over-caching HTML: caching HTML can break authenticated experiences; use Vary headers or custom Workers logic
• Ignoring cache key normalization: failing to ignore irrelevant query parameters inflates cache size and reduces hit rate
• Conflicting rules: Cache Rules and Page Rules can overlap; ensure you understand precedence and disable redundant rules
• Not testing purge behavior: verify that cache purge (by URL, tag, or prefix) works as expected after rule changes
• Forgetting Browser Cache TTL: edge cache and browser cache are separate; control both for optimal performance

Conclusion

Cloudflare Cache Rules are the current recommended path for most edge caching needs, offering a balance of power, simplicity, and cost. Page Rules remain functional but lack the advanced matching and dedicated UI of Cache Rules. Workers provide maximum flexibility for complex scenarios but add cost and maintenance overhead. Origin cache headers remain the most portable approach and work well when cache logic belongs in the application.

For typical hosting and site optimization work, start with Cache Rules for declarative overrides, respect origin headers where possible, and reserve Workers for authenticated caching or custom key logic. This layered strategy keeps your edge configuration maintainable, cost-effective, and easy to audit as your infrastructure evolves.

Related posts

• Advanced Let's Encrypt Wildcard: Pro Tips for 2026
• CloudLinux LVE for Beginners: A Practical Starter Guide
• What Are Core Web Vitals? How to Improve LCP, FID & CLS in 2026
• SSH Hardening Mistakes: What Everyone Gets Wrong on Their VPS