Read and control cache behavior

Caching answers repeated requests near users and cuts work at the origin. It is correct only when the cache key separates every response variant that matters. Two users must never share a cached response that was personal to one of them.

Read the status before changing anything

Every proxied response carries CF-Cache-Status. Request a static asset twice:

curl -sI https://flaviocopes.com/img/og.png | grep -i cf-cache-status
# cf-cache-status: MISS
curl -sI https://flaviocopes.com/img/og.png | grep -i cf-cache-status
# cf-cache-status: HIT

MISS means Cloudflare fetched from the origin and stored a copy. HIT means the edge answered without touching the origin. You will also meet DYNAMIC, which means Cloudflare did not consider the response cacheable — HTML gets this by default, because Cloudflare caches by file extension unless you add Cache Rules.

Alongside the status, read Cache-Control (what the origin asked for), Age (how long the copy has been stored), and validators like ETag before adding any Cache Rules. They tell you what the current behavior is. Change configuration only after you can explain what you see.

What must never share a key

Never cache personalized or authorization-dependent responses under a shared key. A cached /account page is a data leak with a CDN in front of it. If a response depends on a cookie or an Authorization header, keep it out of the shared cache or make the differing input part of the key.

Prefer versioned URLs over purging

Purging is an operational tool, not a substitute for correct freshness rules. If you rename an asset on every release, old and new versions coexist and no purge is needed:

/assets/app.3f9c1a.css   cached forever, safe
/assets/app.css          needs purging on every deploy

The versioned name changes when the content changes, so a long max-age becomes harmless. Reach for a purge when something wrong was cached, not as a routine deploy step.

Now request one versioned asset twice and explain both cache statuses. Then change its URL and confirm the new URL starts at MISS — that is the behavior a global purge only approximates.