Skip to main content
Optimizely Academy

End-user eLearning

Upcoming events

Certification

Partner training

Community

All Topics

Performance Optimization

  • By Optimizely Education
  • Published: Feb 13, 2026
  • Rating
    Average rating: 0 No reviews

Outline
At a glance:
  • Internal object cache: CMS repository-layer caching reduces database round-trips automatically
  • Fragment caching: Cache partial output in Razor using the <cache> tag helper
  • Output/response caching: Cache full responses selectively (only where output is identical for all users)
  • HTTP headers and CDN: Use Cache-Control to guide intermediary/edge caching; configure CDN base paths for client resources

Introduction

Optimizing the performance of an Optimizely CMS 12 (PaaS) solution requires a clear understanding of how caching works at different layers of the platform and how CDN configuration interacts with application-level behavior. CMS 12 provides built-in caching mechanisms, object caching, and configuration guidance for Content Delivery Networks (CDNs).

1. Caching Strategies in CMS 12

Caching in CMS 12 operates at four distinct levels. Each serves a different purpose and must be applied with awareness of content volatility and publishing workflows:

  • Object-level caching inside the CMS runtime
  • Fragment and output caching in the rendering layer
  • HTTP-based caching controlled via response headers
  • Edge caching using a CDN

2. Core Caching Mechanisms

The following four caching types are typically combined in CMS 12 PaaS performance tuning.

Caching Types

Select a type to expand and read the details.

1. Object Cache (Internal CMS Cache) ▼

Optimizely CMS automatically caches objects retrieved through its APIs. When content is requested - pages, blocks, or media - the CMS checks the internal object cache before accessing the database.

This object cache is in-memory, designed for read-only objects, and managed internally by the CMS. Developers typically do not need to configure it manually - content retrieval performance already benefits from this layer automatically.

2. Fragment Caching ▼

Fragment caching caches a portion of rendered output rather than the entire page - useful when pages contain both static and dynamic regions. Apply it in Razor views using the built-in <cache> tag helper:

HTML
<cache expires-after="00:10:00"> @await Html.PartialAsync("_Menu") </cache>

The content inside the <cache> tag is stored for 10 minutes. Subsequent requests within that window reuse the cached fragment. Ideal for navigation menus, footers, or reusable layout elements that change infrequently.

3. Output Caching (Response Caching) ▼

Output caching stores the full response of an action or endpoint using ASP.NET Core response caching middleware and the [ResponseCache] attribute:

C#
[ResponseCache(Duration = 60, Location = ResponseCacheLocation.Any)] public IActionResult Index() { return View(); }

The response is cached for 60 seconds and intermediaries may also cache it. In CMS scenarios, apply this only to content that is identical for all users and not personalized. Consider:

  • Published content may not appear immediately if cached responses are still valid.
  • Editor-specific features and UI elements must not be cached.
  • Load-balanced environments require consistent cache behavior across all instances.
4. HTTP Caching Headers ▼

HTTP caching behavior is controlled via response headers such as Cache-Control, which also instructs CDNs on how long to hold a cached copy:

HTTP
Cache-Control: public, max-age=86400

This header allows intermediaries including CDNs to cache the response for 24 hours. Use shorter durations for frequently updated content and longer durations for stable assets.

3. CDN Usage in Optimizely DXP

When running on Optimizely DXP, using a CDN is strongly recommended. A CDN reduces latency and origin load by serving cacheable content from geographically distributed edge nodes.

CDN integration is configured by defining the base URL for client resources in appsettings.json:

JSON
{ "EPiServer": { "Cms": { "ClientResources": { "BasePath": "https://yourcdn.example.com" } } } }

After configuration, static resources are served from the CDN base URL and asset requests no longer hit the origin server directly - scripts, styles, and other client resources are distributed via the CDN edge.

Verifying CDN Configuration

After deploying CDN configuration, verify it is working using browser developer tools or command-line utilities:

  • Inspect network requests and confirm static resources resolve to the CDN domain
  • Review response headers such as Cache-Control and X-Cache to confirm the CDN is caching and serving assets correctly

4. Cache Invalidation Strategies

Caching requires a strategy for ensuring freshness when content changes. There are three primary approaches.

1. Time-based Expiration

Control freshness using max-age values in Cache-Control headers. Set durations that match the publishing frequency of the content - short for frequently updated pages, longer for stable assets.

2. Versioning or Fingerprinting

Append a version query string to asset URLs. When the version changes, the CDN treats the URL as a new resource and fetches a fresh copy regardless of cache headers:

HTTP
style.css?v=2

3. Manual Purging

Most CDN providers support manual purging of cached content. In DXP environments, cache clearing may require coordination with Optimizely support. Manual purging is appropriate for urgent updates but should not replace structured expiration policies.

5. Coordinating Application and CDN Caching

Effective performance optimization requires all four caching layers to work together: fragment caching in Razor views, response caching at the controller level, HTTP cache headers, and CDN configuration.

Key principles for coordinating these layers:

  • Never cache personalized or editor-facing output. Vary-by-user requirements must be reflected in both fragment cache keys and HTTP headers.
  • Align cache durations with publishing frequency. A news site publishing hourly should not use 24-hour CDN TTLs.
  • Treat CDN caching as an extension of HTTP caching, not a separate system. The Cache-Control header you set at the application layer directly governs what the CDN stores and for how long.

Pro tip: When properly configured, these layers significantly reduce database access, CPU usage, and origin traffic while maintaining predictable content freshness. Start with fragment caching on high-frequency components (menus, navigation), then work outward to CDN configuration for static assets.

Conclusion

Performance optimization in Optimizely CMS 12 (PaaS) relies on combining internal object caching, selective fragment caching, controlled response caching, and properly configured CDN distribution. Fragment caching improves partial rendering performance. Response caching reduces full-page processing. HTTP headers guide intermediary caching behavior. CDN configuration ensures global distribution of static and cacheable resources.

A successful optimization strategy balances performance gains with content freshness requirements, ensuring fast delivery without compromising publishing workflows.