Performance Optimization

By Optimizely Education
Published: Feb 13, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

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 + 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. Optimizely CMS provides built-in caching mechanisms, object caching, and configuration guidance for Content Delivery Networks (CDNs).

This document expands on caching strategies, CDN usage, and output caching using only officially documented patterns and examples from the Optimizely CMS documentation.

1. Caching strategies in CMS 12

Caching in CMS 12 operates at multiple levels:

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

Each layer serves a different purpose and must be applied with awareness of content volatility and publishing workflows.

2. Core caching mechanisms

This section breaks down the main caching types you typically combine in CMS 12 PaaS performance tuning.

1. Object cache (internal CMS cache)

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

This object cache is:

In-memory
Designed for read-only objects
Managed internally by the CMS

Because object caching is built into the content repository layer, developers typically do not need to configure it manually. However, it is important to understand that content retrieval performance already benefits from this internal mechanism.

2. Fragment caching

Fragment caching allows developers to cache a portion of rendered output rather than the entire page. This is useful when pages contain both static and dynamic regions.

Fragment caching is applied in Razor views using the built-in caching tag helper. The documented example uses the cache tag helper:

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

In this example:

The content inside the <cache> tag is cached for 10 minutes.
Subsequent requests within that duration reuse the cached fragment.

Fragment caching is suitable for components such as navigation menus, footers, or reusable layout elements that change infrequently.

3. Output caching (response caching)

Output caching caches the full response of an action or endpoint. In ASP.NET Core, this is implemented using response caching middleware and attributes.

A documented example shows using the ResponseCache attribute:

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

In this example:

The response is cached for 60 seconds.
The caching location allows intermediaries to cache the response.

However, when applying response caching in CMS scenarios, developers must consider:

Published content may not appear immediately if cached responses are still valid.
Editor-specific features and UI elements should not be cached.
Load-balanced environments require consistent cache behavior across instances.

Response caching should be applied only to content that is identical for all users and not personalized.

4. HTTP caching headers

HTTP caching behavior is controlled using response headers such as Cache-Control. Optimizely documentation references configuring cache behavior using headers like:

Cache-Control: public, max-age=86400

This header allows intermediaries (including CDNs) to cache the response for 24 hours. Shorter durations can be used for frequently updated content, while longer durations are appropriate for stable assets.

3. CDN usage in Optimizely DXP

When running on Optimizely Digital Experience Platform (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 in CMS 12 is configured by defining the base URL for client resources. The documentation describes configuring the client resource base path in configuration.

Example configuration in appsettings.json:

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

After configuration:

Static resources are served from the CDN base URL.
Asset requests no longer hit the origin server directly.

This ensures that scripts, styles, and other client resources are distributed via the CDN.

4. Verifying CDN configuration

After deploying CDN configuration, verification should be performed using browser developer tools or command-line utilities.

Developers should:

Inspect network requests
Confirm that static resources resolve to the CDN domain
Review response headers such as Cache-Control

This ensures that the CDN is correctly caching and serving assets.

5. Cache invalidation strategies

Caching requires a strategy for ensuring freshness when content changes. The documentation outlines several approaches:

1. Time-based expiration

Control freshness using max-age values in Cache-Control headers.

2. Versioning or fingerprinting

Assets can be versioned by appending a query string:

style.css?v=2

When the version changes, the CDN treats the asset as a new resource.

3. Manual purging

Most CDN providers allow 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.

6. Coordinating application and CDN caching

Effective performance optimization requires coordination between:

Fragment caching inside Razor views
Response caching at the controller level
HTTP cache headers
CDN configuration

Key principles include:

Avoid caching personalized or editor-facing output.
Ensure cache durations reflect publishing frequency.
Treat CDN caching as an extension of HTTP caching rather than a separate system.

When properly configured, these layers significantly reduce database access, CPU usage, and origin traffic while maintaining predictable content freshness.

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.