CDN caching strategies to scale high-traffic ecommerce sites

CDN caching strategies that actually scale high-traffic ecommerce sites

Most ecommerce teams assume that adding a CDN (content delivery network, a globally distributed layer of servers that serves cached copies of your site closer to visitors) will fix their performance problems. It will not, not on its own. A CDN with poor cache configuration just moves the bottleneck closer to the user while the origin server still drowns during a flash sale. This article covers the CDN caching strategies that actually reduce origin server load, keep product pages fast under pressure, and do not accidentally serve stale prices to the wrong customer.

A CDN is not a performance strategy. It is infrastructure. The strategy is everything you configure inside it.

Why most ecommerce cdn setups underperform

Most ecommerce CDN setups have a cache hit rate below 50%, which means more than half of all requests still reach the origin server. That defeats the purpose. The typical cause is not a bad CDN choice. It is default settings left untouched, query strings that fragment the cache, and cookie headers that force the CDN to treat every request as unique.

WooCommerce sites are particularly prone to this. The WooCommerce session cookie, set on first visit, signals to most CDN configurations that the request is personalised and should bypass the cache entirely. On a site with 10,000 daily visitors, that can mean 10,000 origin hits for pages that are identical for 9,800 of those visitors.

The fix is not complicated, but it requires deliberate configuration. You need to decide, per URL pattern, what is actually personalised and what only looks personalised because of a cookie that should not be there.

Cloudflare’s 2023 data showed that ecommerce sites using properly configured cache rules saw a 60-70% reduction in origin requests compared to sites using default CDN settings. The gap is not marginal.

The four cdn caching strategies that matter for ecommerce

The four strategies that cover most ecommerce caching needs are: static asset caching, full-page caching for anonymous users, fragment caching for dynamic sections, and stale-while-revalidate for high-churn content. Each solves a different problem, and using only one of them is why most setups underperform.

Static asset caching is the easiest win. Images, CSS, JavaScript, fonts: these change rarely and can be cached at the edge (the CDN’s geographically distributed servers, called edge nodes) for days or weeks. A TTL (time to live, the duration a cached copy is considered valid) of 30 days for versioned assets is reasonable and common.

Full-page caching for anonymous users is where most ecommerce teams leave performance on the table. A product page for a logged-out visitor is identical across all requests. Cache it. The objection is usually “but what about stock levels?” which is a real concern, but one solved by cache invalidation, not by skipping the cache entirely.

Fragment caching, sometimes called edge-side includes or partial caching, lets you cache the static shell of a page while keeping specific sections dynamic. The product description is cached. The stock badge is not. This requires more setup but pays off on high-traffic product pages.

Stale-while-revalidate is a cache-control directive that tells the CDN to serve a slightly outdated cached copy while fetching a fresh one in the background. For category pages that update a few times per day, this is the right trade-off. The user gets a fast response. The cache refreshes without a visible delay.

Decision box

• Best if: your site has significant anonymous traffic, product pages that change infrequently, and a clear separation between static and personalised content
• Not ideal if: every page is heavily personalised, prices change per user in real time, or your platform does not support cache-control header customisation
• Likely overkill when: you have fewer than 5,000 monthly visitors and a single-region audience, where a well-configured origin server handles load without a CDN layer

How to handle cache invalidation without breaking product pages

Cache invalidation, the process of telling the CDN to discard a cached copy and fetch a fresh one, is where most ecommerce caching strategies fall apart. The common failure mode is either invalidating too aggressively (which kills your cache hit rate) or not invalidating at all (which serves outdated prices or sold-out products).

The practical approach is tag-based invalidation. You assign cache tags to pages based on the data they contain. A product page for item SKU-4421 gets the tag “product-4421”. When that product’s price or stock changes, you purge only pages tagged with “product-4421”. Cloudflare Cache Tags and Fastly’s surrogate keys both support this pattern.

In projects with large product catalogues, the temptation is to purge entire categories when one product changes. That is usually unnecessary and expensive in terms of cache warm-up time. Granular tag-based purging keeps the cache warm for the 99% of products that did not change.

For custom ecommerce development, building the invalidation hooks into the product update workflow from the start saves significant rework later. Retrofitting cache invalidation into a platform that was not designed for it is one of those tasks that always takes three times longer than estimated.

One pattern worth knowing: if your platform cannot support tag-based purging, a short TTL (60 to 300 seconds) combined with stale-while-revalidate gives you a reasonable fallback. You accept slightly stale data in exchange for a cache that stays warm.

Caching personalised content and cart state correctly

Personalised content and cart state should not be cached at the CDN layer. That is the direct answer, and it is also where the nuance lives. The goal is not to cache everything. It is to cache as much as possible while keeping the personalised parts genuinely dynamic.

The standard approach is to split the page into a cacheable shell and a dynamic fragment. The shell, which includes the header layout, navigation structure, product description, and footer, is cached at the edge. The cart count, user greeting, and personalised recommendations are fetched client-side via a separate API call after the page loads.

This pattern is sometimes called “cache then hydrate.” The user sees a fast page load because the shell is served from the edge. The personalised elements appear a fraction of a second later, loaded via JavaScript. For most ecommerce use cases, this is imperceptible.

The cart endpoint itself should never be cached. It must always hit the origin. The same applies to checkout pages, account pages, and any URL that contains session-specific data. Configure your CDN to bypass the cache for these URL patterns explicitly, not by accident.

One thing that catches teams out: some CDNs will cache a 302 redirect response if you are not careful. If your login redirect or cart redirect gets cached at the edge, you will spend an uncomfortable afternoon explaining to a client why anonymous visitors are being sent to someone else’s account page.

TTL settings and cache-control headers: what to set and why

Cache-control headers are the instructions your server sends to the CDN (and to browsers) about how long to keep a cached copy. Getting these wrong is the single most common cause of both stale content and poor cache hit rates. The two are opposite problems caused by the same misconfiguration.

A reasonable starting point for ecommerce:

• Versioned static assets (CSS, JS with hash in filename): Cache-Control: public, max-age=2592000 (30 days)
• Product images: Cache-Control: public, max-age=604800 (7 days), with CDN-level purge on update
• Product pages (anonymous): Cache-Control: public, s-maxage=300, stale-while-revalidate=60 (5 minutes at edge, serve stale for 60 seconds while refreshing)
• Category pages: Cache-Control: public, s-maxage=600, stale-while-revalidate=120
• Cart, checkout, account pages: Cache-Control: private, no-store

The s-maxage directive is specifically for shared caches like CDNs, while max-age applies to both CDNs and browsers. Using s-maxage lets you set a longer browser cache while keeping the CDN TTL shorter, which is useful when you want fast repeat visits but also want the CDN to refresh frequently.

According to the HTTP Archive Web Almanac 2023, roughly 27% of cacheable ecommerce responses are served with no cache-control header at all, leaving the CDN to guess. CDNs are not good at guessing. They either cache everything or nothing, and neither outcome is what you want.

The vary header is another common source of confusion. If your server sends Vary: Cookie on product pages, the CDN will create a separate cache entry for every unique cookie combination. On a WooCommerce site, that means almost no caching at all. Strip the vary header for pages you want cached, and handle personalisation at the client side instead.

Running CDN caching in production without surprises

Running CDN caching in production without surprises requires treating cache configuration as a first-class part of your deployment process, not an afterthought. The most common production incident pattern is a deployment that updates templates or prices but does not trigger cache invalidation, leaving the CDN serving the old version for hours.

Build cache purge steps into your deployment pipeline. When a new version of a template deploys, purge the relevant cache tags or URL patterns automatically. When a product price updates in the CMS, the webhook that saves the change should also fire the purge request. These are not complex integrations, but they need to be designed in, not bolted on.

Staging environments are another trap. Teams test caching behaviour on staging, where the CDN is often configured differently or disabled entirely, then deploy to production and discover that the cache behaves nothing like they expected. Test cache-control headers in production with a small percentage of traffic before rolling out fully.

What to monitor monthly

• Cache hit rate per URL pattern: target above 80% for product and category pages
• Origin request volume: a sudden spike usually means a cache configuration broke, not a traffic surge
• Time to first byte (TTFB) from edge nodes: should be under 100ms for cached responses
• Purge latency: how long between a product update and the CDN serving the new version
• Error rate on cache bypass routes: cart and checkout endpoints should have zero CDN caching errors

One observation from production work: the first time a team looks at their actual cache hit rate, the number is almost always lower than anyone expected. A rate of 30-40% is common on sites that assumed they were “using a CDN.” Getting that number above 75% typically takes one focused sprint of configuration work, not a platform migration.

CDN caching strategies for ecommerce are not about choosing the right CDN provider. They are about cache hit rate, TTL configuration, and invalidation logic. According to Cloudflare’s 2023 performance data, properly configured cache rules reduce origin requests by 60-70% compared to default settings. Studio Ubique builds and configures ecommerce platforms where caching is part of the architecture from the start, not added after the first traffic incident.

FAQs

What is a good cache hit rate for an ecommerce site?

A cache hit rate above 80% for product and category pages is a reasonable target for most ecommerce sites with significant anonymous traffic. Below 60% usually means query string fragmentation, cookie-based cache bypass, or missing cache-control headers are undermining the CDN configuration.

Can I cache WooCommerce product pages with a cdn?

Yes, but you need to strip or ignore the WooCommerce session cookie for anonymous users before the CDN will cache product pages. Most CDN providers let you configure cookie ignore rules per URL pattern. Without this step, the CDN treats every anonymous visitor as a unique session and bypasses the cache entirely.

How often should I purge my CDN cache for product updates?

Purge on change, not on a schedule. Use tag-based or key-based invalidation so that only the pages containing the updated product are purged. Scheduled full-cache purges are a blunt instrument that warms up slowly and leaves your origin exposed during the warm-up period.

What is the difference between max-age and s-maxage in cache-control headers?

max-age applies to both browsers and shared caches like CDNs. s-maxage applies only to shared caches and overrides max-age for CDNs. Using s-maxage lets you set a short CDN TTL for frequent refreshes while keeping a longer browser cache for repeat visitors, which is useful for product pages that change occasionally.

Should cart and checkout pages ever be cached by a CDN?

No. Cart and checkout pages contain session-specific data and must always be served from the origin. Configure your CDN to explicitly bypass the cache for these URL patterns using Cache-Control: private, no-store, and verify the bypass is working in production, not just in staging.