Ecommerce Caching Strategy: What to Cache, Where and for How Long
How to design ecommerce caching: CDN and page caching, APIs and product data, search, in-memory caches, invalidation, stale data and cache warming.
Quick answer
An ecommerce caching strategy decides what can be cached, where (browser, CDN or edge, application, data layer) and for how long. Cache static assets and images aggressively, cache public pages and API responses with short lifetimes and purge on change, treat prices and stock as volatile, never cache carts, checkout or account data in shared caches, vary caches only by coarse segments such as market and currency, invalidate by tags or events, warm caches before peaks and monitor hit ratios and stale-content incidents.
Where This Fits
Caching is one part of performance and scale. See website performance optimization, Shopify performance, ecommerce scalability and, for PWAs, ecommerce PWA caching.
Caching Layers
| Layer | What to cache | Typical control |
|---|---|---|
| Browser | Versioned assets, images, fonts | Cache-Control headers, file name hashing |
| CDN or edge | Images, assets, public pages, public API GETs | TTLs, purge by URL or tag, stale-while-revalidate |
| Application | Rendered fragments, navigation, computed data, sessions | In-memory or distributed cache |
| Data | Expensive queries, read replicas, search indexes | Query cache, replication, indexing pipelines |
What Is Safe to Cache
| Content | Cache? | Notes |
|---|---|---|
| Static assets and images | Yes, long-lived | Versioned file names |
| Category and product pages | Yes, short-lived | Purge on product, price or stock changes |
| Prices | Briefly, or fetch fresh | Confirm at cart and checkout |
| Stock availability | Very briefly | Confirm before committing |
| Search results | Popular queries, short-lived | Vary by market and filters |
| Cart, checkout, account | No (shared caches) | Private, per user |
| B2B customer prices | Only with customer-specific keys | Often better uncached at the edge |
CDN and Page Caching
Hosted platforms cache much of the storefront at the edge. Custom and headless storefronts should render catalog pages statically or on the server with caching, use stale-while-revalidate to keep responses fast, and purge by tag when products change, so a price update clears every page showing that product.
API and Product Data Caching
Product APIs can be cached at the edge or in the application for public data. Cache keys must include everything that changes the response: market, currency, language, customer group. Keep TTLs short for anything containing price or availability, and invalidate on catalog events.
Pages fast, but prices sometimes wrong?
ZSpace can audit your caching layers and design keys, lifetimes and invalidation that keep pages fast and data correct.
Search
Search engines are themselves a kind of cache: indexes built from catalog data. Keep indexes updated by events, cache results for popular queries briefly, and fetch live prices and availability for result cards where accuracy matters. See site search.
In-Memory Caches
In custom applications, in-memory data stores such as Redis or equivalents hold sessions, rate-limit counters, computed navigation and hot query results. Set TTLs on every key, plan memory limits and eviction, and make sure the application still works (more slowly) if the cache is unavailable.
Invalidation
- Time-to-live for everything, even when you also purge
- Purge by tag (product ID, category) on change events
- Event-driven updates from PIM, pricing and inventory
- Versioned asset URLs instead of purging assets
- Avoid purging everything on every change
- Test invalidation as carefully as caching
Stale Data
Decide how stale each type of data may be. A product description can be minutes old; a price shown at checkout cannot. Where staleness matters, confirm at the decision point: revalidate the cart at checkout, check stock before payment and show updated totals clearly.
Personalization and Caching
Personalization and caching pull in opposite directions. Keep the main page cacheable and personalize small fragments client-side or with edge logic, vary caches only by coarse attributes (market, currency, language, signed in or not), and never mix personal data into shared caches. See personalization.
Cache Warming
After deployments, cache purges or before a sale, warm caches for top pages and API responses so the first wave of traffic does not hit the origin at once. Combine with load testing. See scalability.
Monitoring
- Hit ratio by layer and route
- Origin request rate and latency
- Purge and invalidation volumes
- Stale content incidents (wrong price or stock shown)
- Cache memory and eviction rates
Worked Example
An illustrative scenario, not a client case: a headless store caches product pages for an hour at the edge, including prices. After a price change for a sale, some shoppers see old prices on product pages but new prices in the cart. The team keeps the page shell cached, loads price and availability from a short-lived API response, and purges pages by product tag when prices change. Pages stay fast and price mismatches stop.
Common Mistakes
- Caching carts or account pages in shared caches
- Cache keys missing currency or market
- Long TTLs on prices
- Purging the whole cache on every change
- No fallback when the cache is down
- Personalization that makes every page uncacheable
Ready to tune caching for speed and accuracy?
Talk to ZSpace about performance and caching architecture, Shopify and Hydrogen performance and speed-focused CRO.
Conclusion
Good caching keeps stores fast and correct: cache what is public and stable, keep volatile data fresh, invalidate deliberately, confirm at decision points and monitor. Related: performance optimization and observability.
Common questions
Static assets, images, public pages such as product and category pages (with care for prices and stock), public API responses, search results for common queries, computed data such as navigation trees, and expensive database queries.