CDN Cache Settings Explained: TTL, Purge, and Cache-Control for Faster Sites

Overview

If you manage a website on cloud hosting, a static site platform, or a modern website builder with CDN support, cache settings have an outsized effect on performance. They influence how often the CDN has to return to the origin, how quickly users receive repeat content, and how safely you can update pages, scripts, and media without serving outdated versions.

The challenge is that CDN interfaces often use overlapping terms. One dashboard exposes edge cache TTL. Another uses browser TTL. A third highlights cache rules, surrogate controls, or origin directives. Underneath those labels, the same practical questions still matter:

• What should be cached?
• For how long?
• Who controls that behavior: the origin, the CDN, or the browser?
• How do you force fresh content when needed?

A useful mental model is to think of caching as a chain. Your origin server generates the response. The CDN may keep a copy at the edge. The visitor’s browser may then keep its own local copy. Good cache strategy works when those layers cooperate rather than conflict.

For most sites, the goal is not to cache everything forever. The goal is to cache predictable assets aggressively, cache HTML carefully, and make updates reliable. That balance matters whether you run a brochure site, an ecommerce storefront, a documentation portal, or WordPress cloud hosting behind a CDN.

Core framework

Here is the framework to keep in mind whenever you adjust CDN performance settings.

1. Understand the three layers: origin, edge, and browser

Origin is your application or web server. It creates the response and usually sends HTTP headers.

Edge is the CDN cache node closest to the user. It may store a copy of the response so repeat requests do not hit the origin.

Browser is the user’s local cache. It can reuse a file without contacting the CDN at all, depending on headers and browser behavior.

If you only change one layer and ignore the others, debugging becomes confusing. For example, you may purge the CDN but still see an old file because the browser cached it locally. Or you may set long browser caching on a script that changes frequently, causing users to keep an outdated asset even after the CDN is refreshed.

2. Know what TTL actually means

TTL stands for time to live. In caching, it means how long a response is considered fresh before it must be revalidated or fetched again.

There is no single TTL in practice. You may encounter:

• Edge cache TTL: how long the CDN stores the object.
• Browser cache TTL: how long the visitor’s browser stores the object.
• Default TTL: a fallback value the CDN uses if the origin sends no explicit instructions.
• Maximum TTL: an upper limit imposed by the CDN.
• Minimum TTL: a lower bound the CDN may enforce in some cache rules.

That is why a simple “set TTL to one hour” recommendation is incomplete. You need to know which cache layer that TTL applies to.

3. Use Cache-Control as your primary language

The Cache-Control header is the most important instruction set for modern caching behavior. It tells browsers and intermediaries how a response may be cached.

Common directives include:

• public: the response may be cached by shared caches such as CDNs.
• private: the response is intended for a single user and should not usually be stored in shared caches.
• max-age=...: freshness lifetime for the browser.
• s-maxage=...: freshness lifetime for shared caches such as CDNs.
• no-cache: the response may be stored, but it must be revalidated before reuse.
• no-store: do not store the response.
• must-revalidate: stale responses should not be used without successful revalidation.
• immutable: the asset is not expected to change during its lifetime, useful for versioned static files.

When supported by your CDN, s-maxage is especially useful because it lets you tell the edge and the browser to behave differently. For example, you can allow the CDN to cache for longer than the browser, or vice versa.

4. Match cache policy to content type

The most reliable CDN cache strategy starts by separating content into categories.

Static versioned assets such as hashed CSS, JavaScript bundles, fonts, and build-generated images are usually safe for long TTL values. If the file name changes when content changes, you can cache these very aggressively.

Static but occasionally replaced assets such as a logo at a fixed URL need more caution. A long TTL may be fine, but updates require a purge or file renaming strategy.

HTML documents are more sensitive because they often reference changing content, metadata, or personalization. Cache HTML more conservatively unless you have a clear invalidation plan.

API responses should be cached only when safe. Public read-heavy endpoints may benefit from edge caching. Authenticated or user-specific responses usually should not be placed in shared cache.

Admin pages, checkout flows, account dashboards, and personalized views should generally bypass shared caching.

5. Treat purge as an exception, not your whole strategy

Purge clears cached content from the CDN before TTL expires. It is useful, but it should not be the only way your site stays current. If every deploy depends on manual purges, you are carrying avoidable operational risk.

In a mature setup, purge supports your cache design rather than replacing it. Typical patterns include:

• Purge a single asset after replacing a fixed-URL image.
• Purge HTML paths after publishing content changes.
• Purge everything only for broad emergencies or major deployment mistakes.

When possible, version assets instead of repeatedly purging them. File versioning scales better and reduces the chance of users seeing mixed old and new resources.

6. Favor predictability over maximum aggressiveness

Fast web hosting and hosting with CDN benefits depend on consistency. A slightly shorter TTL with clear behavior is often better than a very long TTL that produces stale pages, support tickets, and difficult debugging. The best setting is the one your team can understand, maintain, and revisit as the site changes.

Practical examples

The following examples show how to apply the framework in common real-world scenarios.

Example 1: Versioned site assets

Suppose your build process creates files like app.8f3a2c.js and styles.b7d91a.css. These are ideal CDN candidates because the file name changes when the content changes.

A practical policy is:

• Long browser TTL
• Long edge TTL
• public and possibly immutable

This works because you are not editing the file at the same URL. When you deploy a new version, users request a different file name, so there is no need to purge the old object immediately.

This approach is common in static site hosting and modern frontend deployments because it gives strong performance without sacrificing freshness. If you are comparing architectures, Static Site Hosting vs Traditional Web Hosting: Cost, Speed, and Maintenance provides helpful context.

Example 2: Homepage HTML for a marketing site

Your homepage changes a few times per week. You want speed, but you also want updates to appear soon after publishing.

A practical policy is:

• Shorter edge TTL than for static assets
• Very short browser TTL or revalidation-friendly behavior
• Targeted purge after publishing major changes

This keeps the homepage fast for repeat requests at the CDN while reducing the chance that users keep an outdated HTML document in local browser cache for too long.

Example 3: Blog posts that change rarely

Individual article pages often remain stable after publication. These can usually tolerate a longer edge TTL than highly dynamic pages, especially if comments and related-content modules are not personalized.

A useful pattern is:

• Moderate to long edge TTL
• Moderate browser TTL
• Selective purge by URL when updating old posts

This is a good compromise for content-heavy sites using cloud hosting for developers or editorial teams who want simpler operations.

Example 4: Ecommerce product pages

Product pages may look static, but they often include changing stock status, prices, shipping estimates, or promotional elements. Here, aggressive full-page caching can create real business problems if not designed carefully.

A cautious policy is:

• Cache static assets aggressively
• Cache HTML conservatively unless product data is separately refreshed
• Bypass caching for cart, checkout, and account pages

If your stack supports edge-side composition or API caching for selected fragments, you can cache some parts while keeping sensitive sections fresh. If not, it is safer to limit HTML caching than to optimize into inconsistency.

Example 5: WordPress behind a CDN

WordPress cloud hosting often combines plugin-level page caching, server cache, and CDN cache. That can work well, but only if responsibilities are clear.

A practical sequence is:

1. Define what the origin sends in Cache-Control.
2. Decide whether the CDN should honor origin headers or override them for certain paths.
3. Exclude logged-in areas, preview routes, admin paths, and sensitive endpoints from shared caching.
4. Make sure publish and update events trigger the right purge actions.

If your main concern is resilience as well as speed, pair caching choices with strong backup workflows. Related reading: Best Hosting for WordPress Sites That Need Fast Backups and Easy Restores and Website Restore Time Benchmarks: What a Good Backup System Should Deliver.

Example 6: Replacing a fixed URL image

Many teams upload a new logo.png to the same path. If that file has a long TTL, users may continue seeing the old logo.

You have three options:

• Rename the file and update references.
• Purge that asset from the CDN.
• Reduce cache TTL for fixed-path assets that are updated in place.

The cleanest answer is usually versioning. Purge is the fallback when renaming is not practical.

Example 7: APIs consumed by a public frontend

If an API endpoint returns the same public content to every visitor, CDN caching may help. If the endpoint depends on authentication, session state, or per-user context, shared caching becomes risky.

When in doubt, start conservative. Cache only clearly public read endpoints and confirm that headers, cookies, and query strings are not causing cache confusion.

For broader implementation decisions, Best CDN for Small Business Websites: Features, Pricing, and Setup Difficulty can help frame tradeoffs among simplicity, control, and setup overhead.

Common mistakes

Most cache problems come from a handful of repeated patterns.

Confusing browser cache with CDN cache

You purge the CDN, refresh the page, and still see old content. Often the browser is the real cause. Test with a private window, disabled cache in developer tools, or a versioned URL before assuming the purge failed.

Applying one TTL to everything

Images, HTML, scripts, APIs, and user dashboards should not all share the same policy. A blanket rule is easy to set and hard to live with.

Using long TTL on unversioned assets

Long-lived caching is safest when file names change with content. Without versioning, stale asset issues become much more likely.

Purging everything after every deploy

Global purges can create cache cold starts, extra origin load, and uneven user experience. Prefer targeted invalidation and versioned asset URLs.

Caching personalized responses

Any page that depends on login state, cookies, or user-specific data should be reviewed carefully before shared caching is enabled. Mistakes here are not just inconvenient; they can become security incidents.

For a broader operational view, review Cloud Storage Security Checklist for Backups, Media, and Website Assets.

Ignoring query strings, cookies, and headers in cache keys

Even a sound TTL policy can fail if the cache key is wrong. If the CDN treats too many request variations as unique, your hit ratio suffers. If it ignores meaningful variations, users may receive the wrong content.

Letting CDN overrides hide weak origin configuration

It is tempting to solve everything in the CDN dashboard, but a stable system starts with predictable origin headers. Use overrides selectively, not as a substitute for understanding the origin response.

Forgetting the deployment workflow

Cache rules should fit how your site is built and released. If your team uses one-click deployment hosting or automated build pipelines, the best cache strategy usually includes asset versioning, post-deploy purges for selected routes, and rollback-friendly procedures. If you are planning a platform change, How to Move a Website to Cloud Hosting Without Downtime is a useful companion guide.

When to revisit

Cache settings should be reviewed whenever the underlying site architecture or publishing pattern changes. This is not a set-once task. It is a lightweight part of performance maintenance.

Revisit your CDN cache rules when:

• You change hosting platforms or move to managed cloud hosting.
• You introduce a new website builder, framework, or deployment process.
• You switch from traditional hosting to static site hosting.
• You add personalization, ecommerce, memberships, or user dashboards.
• You adopt new asset pipelines that support fingerprinted file names.
• You notice stale content complaints, inconsistent page updates, or weak cache hit ratios.
• Browser caching standards, CDN controls, or origin header behavior change in your stack.

A practical review checklist looks like this:

1. List your content types: HTML, assets, media, APIs, admin paths, user areas.
2. Assign a cache policy to each type instead of using one global rule.
3. Confirm origin headers for representative URLs.
4. Check whether the CDN honors, overrides, or supplements those headers.
5. Test publish and deploy workflows to see what actually becomes stale.
6. Document purge procedures for urgent fixes.
7. Record which paths must never be shared-cached.

It also helps to keep CDN work connected to adjacent infrastructure tasks. DNS changes, domain cutovers, and hosting migrations often affect cache behavior indirectly, so a broader operational checklist can reduce surprises. See Domain, DNS, and Hosting Setup Checklist for New Websites.

If you want one enduring rule to return to, use this: cache aggressively only where content is predictable, and design freshness deliberately everywhere else. That principle scales across cloud site builder setups, developer-managed stacks, and storage-focused hosting environments alike.

Before you leave, consider documenting your current answers to four questions: which URLs are safe to cache, how long they should live at the edge, how long they should live in the browser, and what event should invalidate them. Once those answers are written down, CDN cache settings become much easier to operate and much easier to revisit when your site changes.