Edge, CDN, and advanced caching strategy

Part 4 of the Magento 2 Performance/DevOps series — the origin should rarely work hard.

The goal: serve from the edge

Magento's full-page cache (FPC) already removes most dynamic rendering from the request path. A CDN in front of it moves that cached response even closer to the shopper and keeps the origin out of the hot path entirely. Done well, a category page is served from an edge node in milliseconds; done poorly, you serve stale prices or leak customer data across sessions.

FPC and cache tags

Magento tags cached pages with cache tags (per product, category, store) so a single product save invalidates exactly the pages that mention it. The CDN must understand these tags:

• Purge by tag — when Magento emits an invalidation, the CDN drops the matching edge entries. This is the mechanism that keeps content fresh without flushing everything.
• Respect Cache-Control — Magento sets appropriate headers per route; the CDN should honor them rather than applying a blanket TTL that serves cart pages publicly.

What must never be cached at the edge

• Customer-specific pages — cart, checkout, account. Edge-caching these leaks one shopper's session to another. Exclude by route and by the presence of session cookies.
• CSRF/forms — anything that issues a token should not be served from a shared cache.
• Admin — obviously never at the public edge.

A sensible layering

1. CDN edge — static assets (with long TTL + content hashes) and public FPC pages (short TTL, tag-based purge).
2. Magento FPC — the source of truth for dynamic pages.
3. Redis — session and block cache, fast and local.
4. Varnish (if in front of Magento) — another FPC layer with tag support. (See the standalone cache post for Varnish specifics.)

The point is each layer has a job and an invalidation rule; a cache with no invalidation plan is a stale-content bug waiting to happen.

Pitfalls

• Blanket long TTL on everything. Prices change, stock changes; a 24h TTL serves wrong data. Use short TTLs + tag purges.
• Caching pages that read the session. Session leakage is a security incident, not a perf win.
• No purge wiring. If the CDN never receives invalidations, you are serving stale until TTL expiry. Verify purges arrive.
• Forgetting cacheable block holes. A personalized block inside a cached page needs a hole-punch or it renders stale per-user content.

What's next

Edge caching handles steady load; the last post asks whether the system survives a spike — capacity and load testing.

Next in this series: Capacity and load testing — /blog/magento2-capacity-load-testing