HomeGuidesAPI Reference
Submit Documentation FeedbackJoin Developer CommunityOptimizely GitHubOptimizely NuGetLog In


This topic explains the caching concept in the Optimizely platform, and the different caching options and methods available.

Caching options

Optimizely CMS supports external caching and cache expiration settings for files, resources, and images, and manages caching across the Web front-end servers, minimizing the amount of communication with the database. Optimizely CMS stores the cache and other resources (that are used by the templates) in the CMS. You can configure and extend the cache. Optimizely CMS supports the caching methods listed below.

Object caching

Optimizely CMS automatically caches objects that are requested from the API, such as content instances. The object cache is an in-memory cache and stores only read-only objects for better performance. An event system manages invalidation with support for load-balanced servers.

This cache improves scalability with an optimistic locking approach. When multiple threads are reading the same data, they attach to the same database calls to avoid putting too much load on the database for objects that are not yet cached. See Object caching.

Output caching

CMS has no built-in output caching of HTML responses. See Response caching on how to add response caching for an ASP.NET Core application.



Adding response caching of may cause a stale response to be delivered.

Browser caching

You can configure rules for browser (client) caching. For example, you can set a time period in which static files delivered by the Optimizely CMS are cached by the client. You also can define how long dynamically generated pages are cached on the client.

File caching

Content media cache headers can be configured through EPiServer.Framework.MediaOptions.

Static file caching

Static files are served by the static file middleware. To control the caching of these files, see https://docs.microsoft.com/en-us/aspnet/core/fundamentals/static-files#set-http-response-headers.

Dynamic Data Store caching

Dynamic Data Store (DDS) offers an API and infrastructure for the saving, loading, and searching of both compile time data types (.NET object instances) and runtime data types (property bags).

DDS uses a two-level cache:

  • The first level cache is a normal collection of objects that reside in memory with the context until the context is no longer in scope.
  • The second level cache provides a default in-memory cache implementation to the DDS. Objects are in deconstructed form, meaning they do not hold hard references to each other and may be invalidated from the cache individually, thereby maximizing cache efficiency. The used in-memory decides when and how it releases objects from memory, if Optimizely CMS does not remove the objects due to updates.

See also: Common caching pitfalls by Sanne Bregman

Did this page help you?