CDN Strategy: Cache Rules, Purging and What to Serve

A content delivery network helps in proportion to its hit rate, and hit rate is determined by cache rules you write rather than by which provider you chose. This guide covers those rules, drawing on FISTA Solutions' web and mobile work.

What should be served from the edge?

More than most origins allow, once the rules are set deliberately.

Content	Cache approach
Hashed assets	Immutable, very long lifetime
Images and media	Long lifetime, versioned URLs
Public HTML	Short lifetime with revalidation
Personalised HTML	Cached base, edge-applied variation
API responses	Short lifetime where idempotent
Authenticated content	Usually not, unless keyed carefully

How should cache headers be set?

Deliberately, per content type, rather than inheriting whatever the framework produces.

Most origins default to conservative headers that mark almost everything uncacheable, which means the network is a hop with no benefit. Setting them explicitly is the single change that makes a CDN worthwhile.

Separate the browser lifetime from the edge lifetime. A short browser cache with a long edge cache gives fast repeat visits and quick propagation of changes, which is usually what you want.

Why are hashed assets the easy win?

Because their content never changes: a new version produces a new filename.

That allows a very long cache lifetime with no invalidation problem at all, and it covers the bulk of a typical page's bytes. Build tooling produces these automatically in most stacks.

If your assets are not content-hashed, that is the first change to make. It converts the hardest caching problem into a solved one.

How do you cache HTML without serving stale pages?

Short edge lifetimes with stale-while-revalidate, so the edge serves immediately and refreshes behind the request.

That gives most of the performance benefit with a freshness window measured in seconds or minutes rather than the uncached alternative.

Where pages vary by user, cache the shared base and apply variation at the edge from request signals: geography, device, language, experiment assignment. That preserves cacheability while personalising. See edge computing for web.

What does origin shielding do?

Designates one edge location to fetch from the origin on behalf of the others.

Without it, a cold cache means every edge location requests the same resource from the origin simultaneously, which multiplies origin load by the number of locations at exactly the worst moment.

This matters most after a purge or a deployment, which is when caches are coldest and traffic is unchanged. Enable it for any origin that would struggle with that multiplier.

How should purging be structured?

By tag or surrogate key, so a change to a piece of content purges everything derived from it.

URL-based purging requires knowing every affected URL, which for a page composed from several content items means maintaining that mapping yourself. That mapping is where invalidation gaps come from.

Tag responses with the identifiers of the content they contain, then purge by identifier. The CDN handles the rest, and content changes propagate without anyone enumerating pages.

What about authenticated or personalised content?

Cache it only with a key that includes the authentication context, or not at all.

The failure mode — one user receiving another's cached page — is serious and it happens when a page varies by user and the key does not. Verify with a deliberate test rather than by reasoning.

The safer pattern is caching the public shell and loading personalised parts separately, which preserves hit rate on the expensive part without the risk. See caching strategy guide.

What are the common mistakes?

Inheriting default cache headers. Assets without content hashes. HTML marked uncacheable. URL-based purging for composed pages. No origin shield. And caching authenticated pages on the path alone.

How do you test it?

Measure hit rate by content type, test purge propagation, test cold-cache origin load, and test that authenticated content cannot cross users.

Hit rate by type is the diagnostic that matters: an overall figure hides that HTML is never cached while assets always are.

What does it cost to operate?

Bandwidth and request charges, usually less than the origin capacity saved. At high traffic the saving is substantial; at low traffic the CDN is bought for latency rather than cost.

Purge volume can carry a cost on some plans, which is worth checking if your content changes frequently.

What should you measure?

Hit rate by content type and by location, origin request volume, latency by geography, and time from a content change to it being visible.

Does this apply to AI responses?

Partly. Generated responses are usually personalised and not edge-cacheable, but the surrounding page, assets, and any shared reference content are.

Where the same question is asked repeatedly, caching at the application layer is more appropriate than at the edge, because the matching logic is semantic rather than path-based.

When is this the wrong approach?

For an internal application with users in one location and no static assets worth distributing, a CDN adds a hop and a configuration surface for little benefit. It earns its cost with geographic spread or with substantial static content.

What should you do first?

Measure your hit rate broken down by content type. If HTML is near zero, setting deliberate cache headers on it is the largest improvement available.

How FISTA Solutions helps

FISTA Solutions builds and operates production systems through web and mobile, AI enablement, and staff augmentation: cache rules written per content type rather than inherited, purging structured by content tags so invalidation has no gaps, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To scope this work, message FISTA on WhatsApp, or read caching strategy guide.