Cloudflare Cache Rules: Speed Up Your Site & Cut Bandwidth

Cloudflare Cache Rules give you fine-grained control over how content is cached at Cloudflare's global edge network — spanning more than 300 locations worldwide. When configured correctly, Cache Rules ensure that visitors receive content from the nearest edge server rather than triggering a round trip to your origin hosting server on every request. The result is a measurably faster website, significantly reduced bandwidth consumption on your hosting plan, and a less-burdened origin server. This guide walks through practical Cache Rule setups from the basics to advanced patterns, including ready-to-use expressions you can copy directly into your Cloudflare dashboard.

How Cloudflare Cache Rules Work

Cache Rules are conditional directives that tell Cloudflare how to handle requests matching specific criteria: whether to cache the response, how long to keep it, and whether to pass requests through to the origin without caching at all. Cloudflare processes rules top-to-bottom based on the order you define, stopping at the first matching rule unless configured otherwise.

When a user requests a page, the flow works as follows:

1. The request arrives at the nearest Cloudflare edge data center.
2. Cloudflare checks whether a fresh cached copy exists (a Cache HIT).
3. If a HIT exists, the cached response is returned immediately — no origin request made.
4. If a MISS occurs, Cloudflare forwards the request to your origin, stores the response in cache, then returns it to the user.
5. Subsequent requests for the same resource within the TTL window will all be HIT responses.

Key concepts to understand before building rules:

• Cache Hit Ratio — the percentage of requests served from cache. Higher is better. Aim for 80%+ for content-heavy sites.
• Edge TTL — how long Cloudflare keeps the cached copy before checking with origin again.
• Browser TTL — how long the visitor's browser keeps its own local copy.
• CF-Cache-Status header — inspect this on every response to see whether caching is working as intended (HIT, MISS, BYPASS, DYNAMIC, EXPIRED).

Accessing Cache Rules in the Cloudflare Dashboard

To create or manage Cache Rules, navigate to your zone in the Cloudflare dashboard and follow these steps:

1. Log in to dash.cloudflare.com and select your domain (zone).
2. Click Caching in the left sidebar.
3. Select Cache Rules.
4. Click Create rule to add a new rule.
5. Give the rule a descriptive name such as "Cache Static Assets - 1 Month" or "Bypass WP Admin".
6. Build your matching expression and configure cache behavior options.
7. Click Deploy to activate the rule immediately.

The Free plan supports 10 Cache Rules per zone, which covers the needs of the vast majority of websites. Rules are evaluated in listed order, so rule priority matters when conditions overlap.

Rule 1: Cache All Static Assets Aggressively

The single highest-impact Cache Rule you can create is one that caches all static file types for as long as possible. Static assets — images, stylesheets, scripts, fonts — rarely change, and serving them from Cloudflare's edge instead of your hosting server dramatically reduces bandwidth consumption and improves page load times globally.

Expression:

(http.request.uri.path.extension in {"jpg" "jpeg" "png" "gif" "webp" "svg" "ico" "css" "js" "woff" "woff2" "ttf" "eot" "mp4" "mp3" "pdf" "zip"})

Cache Behavior Settings:

• Eligibility: Eligible for cache
• Edge TTL: Override origin — 1 month (2,592,000 seconds)
• Browser TTL: Override origin — 1 month

With an Edge TTL of one month, Cloudflare will serve these files without contacting your origin for 30 days. If you deploy a CSS or JS update, use Cloudflare's Purge Cache feature (Custom Purge with specific URLs) to invalidate the old copies immediately rather than waiting for TTL expiry.

Rule 2: Bypass Cache for WordPress Admin and Authenticated Users

One of the most common mistakes when setting up Cloudflare caching is failing to exclude the WordPress admin area and authenticated user sessions. Caching these areas causes login failures, users seeing each other's admin panels, and stale form submissions. This Bypass rule must be in place before enabling any aggressive caching on a WordPress site.

Expression:

(http.request.uri.path contains "/wp-admin") or
(http.request.uri.path contains "/wp-login.php") or
(http.request.uri.path contains "/wp-cron.php") or
(http.cookie contains "wordpress_logged_in") or
(http.cookie contains "wp-settings")

Cache Behavior: Bypass cache

The cookie-based conditions are critical. By checking for the wordpress_logged_in cookie, Cloudflare will bypass the cache for the entire browsing session of any logged-in user — not just the admin panel pages. This prevents any possibility of one user seeing cached content that belongs to another authenticated user.

Rule 3: Cache HTML Pages with a Shorter TTL

By default, Cloudflare does not cache HTML responses because it treats them as potentially dynamic. For static blogs, documentation sites, or article pages that update infrequently, you can instruct Cloudflare to cache HTML with a shorter TTL to improve Cache Hit Ratio further while still reflecting updates within a reasonable timeframe.

Expression for blog/article pages:

(http.request.uri.path contains "/blog/") or
(http.request.uri.path contains "/article/") or
(http.request.uri.path matches "^/[a-z-]+-[0-9]{4}\.html$")

Cache Behavior Settings:

• Eligibility: Eligible for cache
• Edge TTL: Override origin — 4 hours (14,400 seconds)
• Browser TTL: Override origin — 30 minutes

A 4-hour Edge TTL suits blogs and news sites that publish once or twice daily. If you publish more frequently, reduce the TTL to 30–60 minutes. The shorter Browser TTL of 30 minutes ensures readers who return to a page after some time get fresh content without a full cache miss at the edge.

Cache Behavior Options Compared

Rule 4: Exclude UTM Parameters from Cache Key

A frequently overlooked optimization is Cache Key configuration. By default, Cloudflare treats URLs with different query strings as separate cache entries. This is correct for product filtering (e.g., ?color=blue vs ?color=red), but it creates unnecessary cache fragmentation for analytics tracking parameters like utm_source, fbclid, and gclid — parameters that do not change the page content at all.

In your Cache Rule, expand the Cache Key section and configure:

Query string: Exclude specific parameters
Parameters to exclude:
  utm_source, utm_medium, utm_campaign, utm_term,
  utm_content, utm_id, fbclid, gclid, _ga, _gl

With this configuration, /article?utm_source=newsletter and /article share the same cache entry. On sites with significant paid traffic, this single change can improve Cache Hit Ratio by 15–30 percentage points and proportionally reduce origin bandwidth usage.

Serve Stale While Revalidating

One of the most powerful caching patterns for perceived performance is "serve stale while revalidating." When enabled, Cloudflare immediately serves the cached copy — even if it has technically expired — while simultaneously fetching a fresh copy from the origin in the background. The user experiences zero additional latency at TTL expiry boundaries, which would otherwise cause occasional slow responses.

Enable this in your Cache Rule by toggling Serve stale content while revalidating. You can also express this behavior at the origin level:

Cache-Control: public, max-age=3600, stale-while-revalidate=86400

This header tells Cloudflare that once the 1-hour TTL expires, it may still serve the stale copy for up to 24 hours (86,400 seconds) while revalidating. The result is that users always get fast responses, and the freshness of the content degrades gracefully in the background rather than causing a hard cache miss delay.

Setting Cache-Control Headers at the Origin

For the most precise caching behavior, set Cache-Control headers directly from your origin server and let Cloudflare respect them. This approach keeps your caching policy in code rather than in the Cloudflare dashboard, making it easier to version-control and deploy alongside application changes.

In Apache's .htaccess:

<FilesMatch "\.(jpg|jpeg|png|gif|webp|ico|css|js|woff|woff2)$">
  Header set Cache-Control "public, max-age=2592000, immutable"
</FilesMatch>

<FilesMatch "\.html$">
  Header set Cache-Control "public, max-age=3600, stale-while-revalidate=86400"
</FilesMatch>

In PHP for dynamic pages:

<?php
// Article page — cache for 1 hour, serve stale for 24 hours during revalidation
header('Cache-Control: public, max-age=3600, s-maxage=14400, stale-while-revalidate=86400');
header('Vary: Accept-Encoding');
?>

The s-maxage directive overrides max-age specifically for shared caches like CDNs, allowing you to set a longer edge TTL (4 hours in this example) while keeping the browser TTL shorter (1 hour).

Verifying That Caching Is Working

After deploying your Cache Rules, verify their behavior using curl to inspect response headers directly without browser interference:

curl -I https://yoursite.com/images/hero.jpg

Look for the CF-Cache-Status header in the output. Expected values and their meanings:

• HIT — served from Cloudflare edge cache. This is what you want for static assets.
• MISS — not in cache yet; fetched from origin but will be cached now.
• BYPASS — a Bypass rule matched; passed through to origin intentionally.
• DYNAMIC — Cloudflare determined the content is dynamic and did not cache it.
• EXPIRED — was cached but TTL has passed; being revalidated.
• REVALIDATED — stale content was revalidated and confirmed still fresh.

If you see DYNAMIC on a file that should be cached, check whether your origin is sending Cache-Control: no-store or private in its response headers — these override your Cache Rules unless you use "Ignore cache-control" behavior.

For an aggregate view, visit Caching > Overview in the Cloudflare dashboard. The Cache Hit Ratio graph shows you the percentage of requests served from cache over time, and the Bandwidth Saved metric quantifies how much origin bandwidth your rules are protecting.

Purging Cache After Content Updates

When you publish new content or deploy a CSS/JS update, you need to invalidate the old cached copies before the TTL expires naturally. Cloudflare provides several purge options:

Manual purge via Dashboard: Navigate to Caching > Configuration, click Purge Cache, and select either Purge Everything (clears all cached content) or Custom Purge (specify individual URLs).

Automated purge via API — ideal for CMS deployments:

curl -X POST \
  "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://yoursite.com/blog/updated-article.html",
                    "https://yoursite.com/css/main.css"]}'

WordPress users can integrate automatic cache purging through Cloudflare's official WordPress plugin, which hooks into post save/publish events and purges the relevant URL (and optionally the homepage and category pages) automatically on each update.

Frequently Asked Questions

What is the difference between Cloudflare Cache Rules and Page Rules?

Page Rules is the legacy system that Cloudflare is gradually deprecating. It supports only 3 rules on the Free plan and uses wildcard (*) pattern matching. Cache Rules is the modern replacement built on Cloudflare's Ruleset Engine, which allows complex matching on URL path, hostname, cookies, and request headers. Cache Rules are recommended for all new configurations as they provide more capabilities and will be supported long term.

Will a Bypass Cache rule make my website slower?

Bypass Cache does not inherently slow down your website. It simply means that matching requests pass through to the origin server rather than being served from Cloudflare's edge. For admin panels, login pages, and checkout flows that require real-time data, bypassing the cache is the correct behavior. Caching these pages would risk users seeing stale data or being unable to complete authentication flows.

How long should I set Cache TTL for static assets?

For static assets that rarely change — images (.jpg, .png, .webp), fonts (.woff2), and CSS/JS files that include a version hash in the filename — a Cache TTL of 1 month (2,592,000 seconds) to 1 year (31,536,000 seconds) is appropriate. If your CSS or JS files do not include a version hash in the filename, use a shorter TTL such as 1 week to ensure users receive updated files after deployments.

How many Cache Rules are available on the Free plan?

Cloudflare's Free plan supports 10 Cache Rules per zone, which is sufficient for most websites. The Pro plan supports 25 rules and the Business plan supports 50 rules. If you need many rules for a complex site such as a large e-commerce store, consider upgrading or consolidating rules using broader expressions that cover multiple URL patterns in a single rule.