Is page speed eroding revenue or showing outdated prices on product pages? Merchants often blame platforms when the real culprit is mismatched browser caching and CDN TTL policies. This guide provides actionable TTL templates, invalidation workflows and diagnostics specific to e-commerce so pages load faster without showing stale inventory or wrong prices.
Key takeaways: what to know in 1 minute
- Set short CDN TTLs for dynamic product endpoints and short browser cache for HTML to avoid stale prices while using longer TTLs for static assets.
- Use cache tagging and purge APIs to automate invalidation when inventory or price changes.
- Adopt a hybrid approach: edge TTLs (CDN) can be longer than browser TTLs when using stale-while-revalidate and origin revalidation.
- Monitor hit ratio and TTFB; aim for >70% edge hit ratio on static assets and sub-200ms TTFB from edge.
- Estimate costs: small stores often pay < $50/month extra to reduce origin requests; multi-CDN or aggressive purge patterns increase costs.
Browser caching step-by-step for ecommerce
Step 1: classify assets by volatility
- Static assets: images, fonts, versioned JS/CSS, change rarely.
- Semi-static assets: category pages, marketing banners, change periodically.
- Dynamic assets: product price, inventory API, cart, checkout, change frequently or per session.
- Static assets: Cache-Control: public, max-age=31536000, immutable; set long CDN TTL and rely on cache-busting via fingerprinting.
- Semi-static pages: Cache-Control: public, max-age=3600, stale-while-revalidate=60, stale-if-error=86400; set CDN TTL to 1–4 hours.
- Dynamic endpoints: Cache-Control: private, max-age=0, must-revalidate OR set short max-age (5–30s) with revalidation to origin for freshness.
- Use asset fingerprinting (file.hash.js) for JS/CSS/images to allow long browser TTLs without cache-busting headaches.
- Use ETag or Last-Modified for APIs and HTML with conditional GET to reduce payloads while ensuring freshness.
Step 4: deploy and smoke-test
- Push headers via CDN or origin.
- Test with curl and browser devtools for Cache-Control, Age, and CF-Cache-Status or equivalent.
- Validate that product price updates propagate within the expected window.
Simple CDN TTL guide for beginners
Understanding TTL layers briefly
- Browser TTL (max-age) controls client caching.
- CDN TTL controls how long an edge location serves an object before rechecking origin.
- Origin policy (headers) is the source of truth; CDNs typically respect or override via rules.
Quick-start TTL values (beginner-friendly)
- Images, fonts: CDN TTL 1 year, browser max-age 1 year.
- CSS/JS: CDN TTL 1 year (if fingerprinted), browser max-age 1 year.
- HTML pages (product/category): CDN TTL 60–600s depending on change frequency; browser max-age 0–60s with stale-while-revalidate.
- Price/inventory API: CDN TTL 5–30s or no-cache with short max-age and ETag.
Example vendor links for configuration
How to fix CDN stale cache ecommerce
Symptoms of stale cache
- Product pages showing old prices after a price change.
- “Add to cart” failing because stock level is incorrect.
- Admin changes not reflected on the storefront after expected propagation window.
- Use the CDN purge API to purge by tag or URL immediately.
- If purge is slow or expensive, serve a cache-control override for affected endpoints: Cache-Control: no-cache, must-revalidate for a short window.
- Implement origin-triggered purge: when price or inventory changes, call the CDN purge endpoint with the affected tags.
Preventive measures
- Implement cache tagging: tag product assets with product_id so purges target only affected items.
- Avoid global purges; prefer tag-based or URL-based purges to save cost and reduce edge churn.
- Add monitoring and alerts: detect mismatch between origin and edge by sampling product pages every minute.
Compare CDN TTL vs browser cache ecommerce
Core differences
- CDN TTL controls edge storage; browser cache controls client-side storage.
- CDN TTL is typically global and affects many users; browser TTL affects an individual user only.
- Browser cache can delay seeing updates for repeat visitors; CDN cache can delay updates for all visitors until purge or TTL expiry.
When to prefer one over the other
- Prefer longer CDN TTL with short browser TTL when expecting rapid backend updates but wanting to reduce origin load: the edge can serve stale-while-revalidate while browsers fetch fresher HTML.
- Prefer longer browser TTL for static, fingerprinted assets to reduce repeat downloads.
Practical comparison table: recommended TTLs (CDN vs browser)
| Asset type |
Suggested browser max-age |
Suggested CDN TTL |
Invalidation method |
Notes |
| Product images (fingerprinted) |
31536000 (1y) |
31536000 (1y) |
Versioned URL |
Use immutable flag |
| CSS / JS (fingerprinted) |
31536000 (1y) |
31536000 (1y) |
Versioned URL |
Long TTL safe if fingerprinted |
| Category pages |
60–300s |
300–900s |
Purge by tag on content update |
Use stale-while-revalidate |
| Product page HTML |
0–60s |
60–300s |
Tag purge on price/stock change |
Short browser TTL prevents stale views |
| Price API / inventory API |
0–15s |
5–30s |
Cache key per sku, purge via API |
Prefer conditional GETs/ETags |
| Checkout / cart pages |
private, max-age=0 |
no-cache |
No cache at edge or session-scoped |
Never cache checkout responses |
Why CDN TTL affects product pricing pages
- Product pricing is high volatility data; long edge TTLs cause the same old price to be served to many users, creating price mismatches and potential compliance issues.
- Pricing changes often trigger conversion-sensitive behavior; even small delays (minutes) can cost sales or cause customer trust issues.
- CDNs cache at edge nodes geographically; a stale item can persist regionally until TTL expiration or targeted purge occurs.
Practical rule
- Treat price and inventory endpoints as first-class dynamic endpoints: either bypass edge cache entirely or set very short TTLs plus automated purge/tagging.
Best CDN TTL strategy for US ecommerce
US-specific considerations
- US stores typically see concentrated traffic across multiple regions; ensure TTLs reflect both GC and regional update windows.
- Aim for edge hit ratio by leveraging regional POPs and origin shielding (origin shield reduces origin requests and lowers costs).
- Consider compliance windows for promotions tied to time zones; purge schedules should align with promotion start/stop times.
Recommended US starter strategy
- Static assets: CDN TTL 1 year.
- Marketing banners or limited-time promotions: CDN TTL aligned to promotion length; use short TTL + tag purge at campaign end.
- Product pages: CDN TTL 60–300s with tag-based invalidation on price/inventory change.
- APIs: CDN TTL 5–30s with conditional requests and origin shielding to reduce origin load.
Multi-region TTL nuance
- For stores serving both US and global customers, consider geo-aware TTLs: shorter TTLs in high-change regions (where promotions/stock change faster) and slightly longer TTLs elsewhere, but always purge globally if price parity is required.
TTL workflow: from update to fresh edge
🖥️
Update origin
Price/stock changes in CMS or ERP
➡️
🔁
Trigger purge
Call CDN purge API by tag or URL
➡️
🌐
Edge revalidate
Edge requests fresh origin content
✅
🛒
Visitors see updated content
Fresh price and stock served globally
Signs your ecommerce cache configuration failing
- Repeated customer complaints about wrong prices.
- Low CDN cache hit ratio on static assets (below 60%).
- High origin CPU or bandwidth spikes when promotions launch.
- Metrics diverging: origin shows updated price but edge serves old price (Age header high).
- Frequent manual purges or firefighting after content changes.
Diagnostic checklist
- Check response headers: Age, Cache-Control, CF-Cache-Status or X-Cache.
- Compare origin vs edge with curl using the same URL and different host headers/POP (when supported).
- Audit purge volume and frequency: frequent full-site purges are a red flag.
CDN caching cost estimate for small stores
Cost drivers
- Number of purges (API calls can be metered).
- Origin egress for cache misses.
- Requests per month at edge (bandwidth cost + request cost).
- Multi-CDN or additional features (WAF, image optimization) add incremental costs.
Example estimate (small store: 50k monthly visits)
- Bandwidth: 500 GB served from CDN ≈ $20–$50 depending on provider and region.
- Purge API: few providers include a free tier; heavy purging (thousands/month) may add $10–$100.
- Edge compute (if using edge workers): $0–$50 depending on execution volume.
Net result: caching properly often reduces origin costs; a conservative extra spend of $20–$100/month typically yields faster pages and lower origin bills.
Advantages, risks and common mistakes
✅ Benefits / when to apply
- Faster pages and better Core Web Vitals for shoppers.
- Lower origin load and reduced hosting costs.
- Better conversion rates when checkout and product images are fast.
⚠️ Errors to avoid / risks
- Caching checkout or cart responses.
- Global long TTLs for price or inventory endpoints.
- Reliance on manual purges instead of automated tag-based invalidation.
Frequently asked questions
How long should CDN TTL be for product pages?
Set CDN TTL between 60 and 300 seconds for product HTML in most stores; shorten for high-frequency pricing updates or use tag-based invalidation.
Can browsers be trusted to refresh product prices?
Browsers cache per user; do not rely solely on browser cache for dynamic prices. Use short browser max-age for HTML and let the browser revalidate frequently.
What is the best purge strategy for price updates?
Use automated tag-based purges targeting product_id or SKU to limit edge churn and cost; call the CDN purge API on price/inventory change.
Should the checkout page be cached at the CDN?
No. Checkout and cart pages must be uncacheable or cached per-session with strict controls to prevent data leakage.
Track edge hit ratio, origin request rate, TTFB from edge, and Core Web Vitals (LCP, CLS, FID). Aim for <200ms TTFB and >70% edge hit ratio on static assets.
Does stale-while-revalidate work for e-commerce?
Yes, for semi-static pages. Use small windows (30–60s) and ensure critical dynamic endpoints bypass or use conditional GETs.
How to balance cache cost vs freshness?
Use short TTLs for price/inventory plus aggressive tagging/purging for changes. This keeps costs low while maintaining freshness. Monitor purge frequency and origin egress to tune.
Is cache tagging supported across CDNs?
Most modern CDNs (Cloudflare, Fastly, Akamai) support tagging or surrogate-keys; consult provider docs: Cloudflare, Fastly.
Your next steps:
- Audit current headers and CDN rules: list assets and current max-age, Age, and X-Cache headers.
- Implement fingerprinting for static assets and set long browser TTLs; set product HTML/CDN TTL to 60–300s and automate tag-based purge on updates.
- Monitor edge hit ratio, origin requests and TTFB for 7 days and adjust TTLs by asset class.
