Putting a CDN in front of Magento Open Source or Adobe Commerce is roughly 90 minutes of work on a store that already runs Varnish, and it moves 85–95% of delivered bytes off your origin. A store serving 10 million page views a month at ~1.9 MB per view pushes about 19 TB; from a cloud origin at $0.085/GB that is roughly $1,615 in egress, and a correctly configured Magento CDN cuts it to under $250 including CDN fees. The work is not installing anything. It is deciding, path by path, what the edge is allowed to cache — and making sure checkout is never one of those paths.
The target architecture: browser to CDN edge, edge to origin shield, shield to Varnish, Varnish to PHP-FPM. Varnish keeps doing full-page caching with Magento's tag-based invalidation. The CDN absorbs static assets, catalog media, and the public HTML variants, so Varnish only sees misses and purges instead of every request.
Two rules drive everything else. Magento's public pages already declare their own cacheability through Cache-Control and the X-Magento-Vary cookie, and private data arrives separately through the customer section endpoint as JSON. That separation is what makes an ecommerce CDN safe here — you are not caching a logged-in cart, you are caching the HTML shell that renders around it.
Write the rules before you touch the dashboard. Magento's paths are predictable enough that five classes cover a standard store.
| Path class | Edge TTL | Cache key additions | Cookies forwarded |
|---|---|---|---|
| Versioned static (static/version…) | 1 year, immutable | None | None |
| Catalog media and resized derivatives | 30 days | Normalized Accept bucket | None |
| Category and product HTML | Honor origin (86400 default) | Store view, currency, X-Magento-Vary | X-Magento-Vary only |
| Customer section load endpoint | Bypass | n/a | All |
| checkout, customer, cart, wishlist, payment returns, admin | Bypass, no-store | n/a | All |
The single most important line in that table is the last one: any rule that caches a path under checkout or customer will eventually serve one shopper's session to another, so make bypass the default and cacheability the exception.
In Admin, set Base URL for Static View Files and Base URL for User Media Files to your CDN hostname over HTTPS. Deploy static content again so the version directory changes, then flush the Magento cache from the CLI. Why: versioned static paths are immutable by construction, which is what lets you set a one-year TTL without ever purging them.
Set the CDN origin to your Varnish entry point, enable an origin shield in the region closest to your infrastructure, and turn on connection reuse to origin. Why: Magento purges by tag pattern, and without a shield every edge location revalidates independently after an invalidation, which turns one product save into a burst of PHP renders.
Strip every cookie except X-Magento-Vary from the cache key on HTML paths, and strip all cookies on static and media paths. Drop marketing parameters (utm_source, gclid, fbclid) from the key entirely; allow-list only the layered navigation and pagination parameters your theme actually uses. Why: an unfiltered key on a store with faceted navigation fragments the cache into thousands of near-identical objects and drops the hit ratio into the 40% range.
Enable format negotiation at the edge, but normalize the Accept header into three buckets before it reaches the key: AVIF-capable, WebP-capable, and neither. Serve the derivative Magento already generated in the media cache directory, and let the edge handle the format conversion. A product grid of 24 images at 180 KB each in JPEG lands around 70–95 KB each in AVIF in 2026 measurements, which is where most of the egress reduction actually comes from.
Magento issues PURGE requests with an X-Magento-Tags-Pattern header. Varnish understands them; most CDNs do not. Map product and category saves to URL-based purges or surrogate keys through a purge module, and set a 15-minute safety TTL on HTML so a missed purge self-heals. Why: stale prices are the one cache bug that costs real money.
Run a HEAD request from your HTTP client against four URLs and read the response headers.
Then watch two metrics for 24 hours: edge cache hit ratio by content type (target above 92% for static and media, 60–80% for HTML on a catalog with heavy faceting) and origin bytes served, which should fall by roughly the same proportion.
Rollback is two moves: repoint the storefront DNS record back to origin (60-second TTL, so it drains in about two minutes), then revert the static and media Base URLs in Admin and flush the Magento cache. Static assets keep resolving from the CDN hostname until DNS expires, which is harmless because they are immutable.
| Symptom | Cause | Fix |
|---|---|---|
| Cart count shows another shopper's items | Customer section endpoint got cached | Add explicit bypass, purge everything, verify Set-Cookie passes through |
| Hit ratio stuck near 45% on HTML | Session cookie or tracking parameters in the cache key | Strip cookies down to X-Magento-Vary, allow-list parameters |
| CSS and JS return 404 after deploy | Static version bumped, edge holds old HTML referencing it | Purge HTML paths as part of the deploy pipeline, not the assets |
| Price changes take hours to appear | Tag-pattern purges not reaching the edge | Map tags to surrogate keys, add a 15-minute safety TTL |
| Origin CPU spikes after every catalog import | Mass invalidation with no shield or stale serving | Enable origin shield plus stale-while-revalidate of 600 seconds |
Four of these five failures come from the cache key or the purge path, not from the CDN itself — budget your debugging time accordingly.
The honest trade-off: an edge in front of Varnish adds a hop, so an uncached checkout POST gains roughly 5–20 ms depending on shield placement. You are trading a few milliseconds on the lowest-volume, highest-value requests for 85–95% offload on everything else. On a catalog with aggressive personalization or per-customer pricing, HTML caching may be off the table entirely and only the static and media classes will pay off — still 70–80% of bytes on most storefronts.
Worked estimate, assumptions stated: 10M page views/month, 1.9 MB average transfer, 19 TB total egress, 92% cacheable. Direct from a cloud origin at $0.085/GB that is about $1,615/month. With a CDN, origin egress drops to roughly 1.5 TB (~$130) and the remaining 17.5 TB is billed at CDN rates.
BlazingCDN prices that traffic on a flat pay-as-you-go schedule: as of 2026, $100/month covers up to 25 TB with additional gigabytes at $0.004, $350/month covers up to 100 TB at $0.0035/GB, and rates fall to $2 per TB above 2,000 TB. For the 19 TB Magento store above, total delivery cost lands near $230/month against $1,615 from origin — with stability and fault tolerance comparable to Amazon CloudFront at a materially lower cost per terabyte, which is where the math matters for enterprise catalogs. Compare that against the per-TB CDN pricing for ecommerce traffic you are quoted elsewhere; Bunny.net and CDN77 sit in the same league on price, and Fastly wins if you need full VCL at the edge for Magento tag purging out of the box.
No. Checkout, cart, customer account, and payment return paths must bypass the CDN with Cache-Control no-store. Magento delivers all private data through the customer section JSON endpoint, which also bypasses. Public catalog HTML is cacheable because the private layer loads separately in the browser after the shell renders.
Yes, in most deployments. Varnish is what receives Magento's tag-pattern purge requests and holds the authoritative full-page cache. The CDN sits in front and absorbs repeat traffic, but removing Varnish means every edge miss becomes a PHP render, and mass catalog updates will saturate origin CPU.
Above 92% for versioned static assets and catalog media, and 60–80% for category and product HTML on a store with faceted navigation. Ratios below 50% on HTML almost always mean session cookies or tracking parameters are still part of the cache key rather than a CDN limitation.
About 90 minutes on a store already running Varnish: 20 minutes to define cache classes, 15 to repoint static and media base URLs and redeploy, 20 for origin, shield and cache key configuration, and the rest for validation. Purge integration for tag-based invalidation adds a few hours if no module exists.
Before you configure a single rule, pull 30 days of origin egress from your cloud bill and split it by content type using access logs. Most teams discover that catalog media alone is 55–70% of the total and that HTML is under 10% — which tells you exactly where to spend your 90 minutes. Then re-run the same split a week after cutover and compare origin bytes served, not just hit ratio. If media offload is below 90%, your Accept normalization or your media path rule is wrong, and that is a 10-minute fix worth several hundred dollars a month.