CDN Caching Strategies for Shopify Stores

A Gold Coast surf brand was running a flash sale that drove 8,000 concurrent visitors to a single landing page. Shopify’s CDN handled the traffic well enough, but the merchant’s real-time inventory widget, served from an app, started timing out under load. By the time we got the call the sale was 40 minutes in and conversion was visibly tanking. The fix was a Cloudflare layer in front of Shopify with a tight cache rule on the inventory endpoint. The next sale six weeks later moved twice the volume with zero timeouts. CDN caching on Shopify is more nuanced than most merchants realise, and getting it right is the difference between a fast store and a fragile one.

What Shopify’s default CDN actually does

Shopify uses Fastly as its primary CDN, with edge nodes across Australia, Asia and the rest of the world. Out of the box, Fastly caches your storefront HTML for visitors who are not logged in, your theme assets aggressively, and your product images at the edge with on-the-fly resizing. For a vanilla Shopify store this default behaviour is already strong. Page response times under 200 milliseconds from Sydney are common.

The caching gets nuanced once your store includes anything personalised. Logged-in customers, cart contents in the header, geolocation-based currency, or any cookie that varies the response can disable HTML caching entirely. When that happens, every page load hits Shopify’s origin and the response time triples or more. Understanding which of your touches break the cache is the first step in a caching strategy.

When to layer Cloudflare on top

Shopify’s Fastly cache is excellent for storefront content, but it offers little control. You cannot define your own cache rules, set surrogate keys, or run custom logic at the edge. Layering Cloudflare in front gives you those controls without replacing the underlying CDN.

Common reasons to add Cloudflare include:

• Caching API responses from your apps or custom backend at the edge, with TTLs you control.
• Implementing bot management, rate limiting, and DDoS protection beyond what Shopify provides.
• Running Workers to inject A/B test variants, redirect logic, or geolocation headers without hitting origin.
• Serving static marketing pages or landing pages from Cloudflare Pages with the same domain as your Shopify store.
• Adding country-level routing for international expansion before you split into multiple Shopify storefronts.

The setup is not trivial. Cloudflare in front of Shopify must be configured carefully so checkout, customer accounts, and webhook traffic bypass the proxy completely. Our walkthrough of Cloudflare in front of Shopify covers the configuration that works, and our companion piece on Cloudflare proxy with Shopify covers the edge cases that quietly break checkout if you skip them.

Cache TTLs by template

Not every page on a Shopify store needs the same cache lifetime. The right TTL depends on how often the underlying content changes and how tolerant you are of brief staleness after a change. A starting framework for most merchants:

• Homepage: short TTL of 60 to 300 seconds, because hero banners and featured collections rotate frequently and you want changes to appear quickly.
• Collection pages: medium TTL of 300 to 900 seconds, because product order and availability change with stock movements.
• Product pages: medium TTL of 300 to 900 seconds, with active purge on inventory changes to avoid showing sold-out items as available.
• Static pages like About, Shipping, Privacy: long TTL of 3,600 seconds or more, because changes are rare and editorial.
• Blog and content pages: long TTL of 3,600 seconds, because publication cadence is slow and immediate freshness is not critical.

These are starting points, not gospel. The right values for your store depend on your editorial rhythm and how often inventory shifts. Measure cache hit ratios in Cloudflare analytics and tune from there. A healthy Shopify storefront sitting behind Cloudflare should run cache hit ratios above 85 per cent on storefront HTML.

Surrogate keys for precise invalidation

The blunt approach to cache invalidation is to purge everything when anything changes. This works but defeats the purpose of having a cache. Surrogate keys let you tag cached responses with metadata, then purge only the tagged subset when a specific resource updates.

For a Shopify storefront proxied through Cloudflare, you might tag every product page with a key like product-12345, every collection page with collection-67890, and the homepage with homepage-default. When product 12345 updates, you purge only responses tagged with that key. Other pages stay warm.

Cloudflare Enterprise plans support cache tags natively. On lower tiers, you can implement a similar pattern with Workers that maintain their own purge index in Workers KV. The complexity is real but the payoff for high-traffic stores is significant. Cache hit ratios above 95 per cent become achievable without sacrificing freshness.

Webhook-driven purge

The right way to invalidate cache when content changes is to drive purges from Shopify webhooks. Subscribe to product/update, product/delete, collection/update, inventory_levels/update, and any other events that should trigger a freshness pass.

When a webhook fires, your purge service translates the affected resource into the cache tags that need invalidating, then calls the Cloudflare purge API. The whole cycle takes a few hundred milliseconds, and customers see fresh content within seconds of the change in Shopify admin.

Build the purge service with idempotency in mind. Shopify retries webhooks if your endpoint does not return a 200 quickly enough, so design for repeated calls without double-purging. Log every purge with the triggering event and the keys touched, so you can audit later when a stale page surfaces.

Edge SSR and beyond

For headless Shopify storefronts built on Hydrogen or other frameworks, the caching story extends further. Edge-side rendering lets you generate HTML at the Cloudflare or Oxygen edge, blending cached fragments with personalised content in a single response. The complexity is higher but the performance ceiling is also higher.

Useful patterns include holding the product page shell in cache while fetching real-time inventory and price in parallel, then composing the final HTML before sending to the customer. Or serving a fully cached page for non-logged-in visitors while a separate edge function injects the personalised header for logged-in customers. These patterns require careful engineering but they let you reach response times that pure Liquid stores cannot match.

Image and asset caching

Shopify’s image CDN handles resizing and format negotiation automatically. WebP and AVIF are served when the browser supports them, with PNG and JPEG as fallbacks. The cache lifetime on images is essentially permanent, with the URL changing when the source asset changes.

What you control is the request pattern. Request the right dimensions for the layout, not the original full-resolution file. Use srcset and sizes attributes properly so the browser picks the best variant. Our guide to Shopify image optimisation covers the request patterns that minimise bytes without sacrificing visual quality.

Monitoring cache effectiveness

A caching strategy without monitoring is a guess. Track cache hit ratio, origin response time, edge response time, and purge frequency. Cloudflare provides this data in its analytics dashboard, and you should pull it into your own monitoring tool for trend analysis.

Watch for declining hit ratios over time. A drop usually means either a new cookie has been introduced that varies the response, or a new template is missing from your cache configuration. Catch these regressions early before they affect customers at scale.

Where to start

The Gold Coast brand we mentioned earlier still runs Cloudflare in front of Shopify and now treats CDN caching as a core part of their performance practice. The investment paid back inside two sale cycles. If you want help designing a caching strategy that fits your store, our team has shipped these configurations for Australian merchants of every size. Take a look at our Sydney web hosting services or start a project if you suspect your cache layer has room to do more.