CDN and Caching Architecture
Why caching architecture matters
Section titled “Why caching architecture matters”Your site’s perceived speed depends more on caching than on raw server performance. A well-configured CDN serves most requests from edge locations close to the user, avoiding round trips to your origin server entirely. A misconfigured cache delivers stale content, leaks personalized data, or forces every request back to origin — negating the entire benefit. Understanding the caching layer is critical for both performance and correctness.
CDN overview
Section titled “CDN overview”Optimizely Cloud includes a CDN (Content Delivery Network) powered by a global edge network. The CDN sits between your users and your application, caching responses at points of presence (PoPs) around the world.
Request flow
Section titled “Request flow”User → Nearest CDN Edge → (Cache Hit?) → Return Cached Response ↓ (Cache Miss) Origin Server → Generate Response → Cache at Edge → ReturnWhen a user requests a page, the CDN checks its local cache first. If the content is cached and still valid (not expired), the response is served directly from the edge with no origin request. If the cache is empty or expired, the CDN forwards the request to your application, caches the response, and serves it.
Geographic distribution
Section titled “Geographic distribution”The CDN operates PoPs across major metropolitan areas worldwide. Each PoP maintains its own cache, so content is cached independently at each location. A page cached in Amsterdam is not automatically available in Tokyo — the Tokyo PoP caches it on first request from that region.
Cache rules
Section titled “Cache rules”Default behavior
Section titled “Default behavior”The CDN respects standard HTTP cache headers sent by your application:
| Header | Effect |
|---|---|
Cache-Control: public, max-age=3600 | CDN caches for 1 hour |
Cache-Control: private | CDN does not cache; response is per-user |
Cache-Control: no-cache | CDN revalidates with origin on every request |
Cache-Control: no-store | CDN does not cache or store the response |
Vary: Cookie | CDN caches separate versions per cookie value |
CMS-specific caching
Section titled “CMS-specific caching”Optimizely CMS sets cache headers based on content type and publishing state:
- Published pages — Cached with configurable duration (default: 10 minutes for server-side, longer for CDN)
- Edit mode — Never cached;
Cache-Control: no-storeis set automatically - Personalized content — Varies by visitor group; the
Varyheader prevents cross-user leakage - Static assets — Long cache duration with content-based hash in the filename for cache busting
Cache key composition
Section titled “Cache key composition”The CDN cache key is composed of:
- URL path — The request path including query string
- Host header — The domain name
- Vary headers — Any headers listed in the
Varyresponse header
Two requests with identical URLs but different Vary header values produce separate cache entries. This is how personalized content avoids serving one visitor’s content to another.
Purge strategies
Section titled “Purge strategies”When content changes, stale cache entries must be cleared. Optimizely Cloud supports several purge approaches.
Automatic purge on publish
Section titled “Automatic purge on publish”When an editor publishes content in the CMS, the platform automatically purges the CDN cache for the affected URLs. This includes:
- The published page’s URL
- Any listing pages that reference the published content
- API endpoints that serve the content
Manual purge
Section titled “Manual purge”Through the management portal or CLI, you can purge:
- Single URL — Clear one specific cached resource
- Path prefix — Clear everything under a URL path (e.g.,
/en/blog/*) - Full purge — Clear the entire CDN cache for an environment
Purge via API
Section titled “Purge via API”For automated workflows, the purge API accepts URL patterns and executes purges programmatically. This is useful in CI/CD pipelines where a deployment should clear specific cached assets.
Time-based expiration
Section titled “Time-based expiration”Not all content needs active purging. Setting appropriate max-age values lets content expire naturally:
| Content type | Recommended max-age |
|---|---|
| HTML pages | 5-15 minutes |
| CSS/JS bundles | 1 year (with hash-based filenames) |
| Images and media | 1-7 days |
| API responses | 1-5 minutes |
| Fonts | 1 year |
Cache considerations for personalization
Section titled “Cache considerations for personalization”Personalized content requires special handling at the CDN layer. If a page shows different content to different visitors, a naive cache would serve visitor A’s personalized content to visitor B.
Edge-side includes (ESI)
Section titled “Edge-side includes (ESI)”The preferred pattern is to cache the page shell at the CDN and load personalized fragments separately. The main page is fully cacheable, and personalized components fetch their content via client-side API calls that bypass the CDN cache.
Vary header strategy
Section titled “Vary header strategy”Alternatively, the Vary header can create separate cache entries per visitor segment. However, this reduces cache hit rates because each segment produces a distinct cache entry. Use this approach only when the number of segments is small and well-defined.
Bypassing CDN for dynamic content
Section titled “Bypassing CDN for dynamic content”For highly dynamic pages (search results, user dashboards, checkout flows), bypass CDN caching entirely with Cache-Control: no-store. These pages are served directly from origin on every request.
Performance monitoring
Section titled “Performance monitoring”Cache hit ratio
Section titled “Cache hit ratio”The cache hit ratio measures what percentage of requests are served from cache versus origin. Target above 85% for content sites. Monitor this metric in the management portal under CDN analytics.
- Below 60% — Review cache headers; likely too many
no-cacheorprivatedirectives - 60-85% — Acceptable, but look for optimization opportunities
- Above 85% — Healthy caching behavior
Edge response times
Section titled “Edge response times”CDN-served responses typically complete in 5-50ms regardless of user location. Origin-served responses depend on application processing time plus network latency to the origin region.