Configure cache


Sitefinity ASP.NET Core pages leverage the output cache feature, shipped with the ASP.NET Core 7.0 framework.
For more information, see Microsoft documentation » Output caching middleware in ASP.NET Core.

You can configure the ASP.NET Core Renderer in the following caching modes:

  • ASP.NET Core output caching
    This type of cache can be absolute or distributed, with or without cache invalidation
  • CDN caching
    If the Renderer is hosted on CDN, you should configure CDN cache with or without cache invalidation.

NOTE: By default, the renderer does not allow CDN caching and always stores only server side cache. Thus the renderer always returns the Cache Control: no-cache header.

Output caching with absolute expiration

This is the default configuration. The Renderer is set to cache everything with 60 seconds absolute expiration.

You can change the absolute expiration time or turn off caching via the appSettings.json file of the ASP.NET Core Renderer, using the OutputCacheDuration setting. 
For more information, see Application settings.

NOTE: To turn off caching, set the setting to 0

Output caching with distributed cache

Absolute cache expiration works when you want to cache for shorter periods. The default value of 60 seconds works for NLB scenario also, because within a maximum of one minute, all of the nodes are invalidated with the latest content.

If you want to take advantage of longer cache times, you need to sync the caches by providing distributed cache storage. This kind of storage is shared between all the nodes, which means that at any given time the output cache from each node in the NLB returns the same content.

GITHUB EXAMPLE: The Output cache sample on Sitefinity’s GitHub repository demonstrates how to provide a customized cache policy by overriding the default one. It uses EntityFramework to implement distributed caching. It stores data in the database, and takes advantage of the IOuptutCacheStore interface to make a distributed cache storage.
For more information, see Microsoft documentation » Cache storage.

Using this distributed cache storage, the cache duration can be extended to more than 60 seconds to allow for longer cache periods.

Output caching with cache invalidation

If you want to have longer caching times, you must ensure that whenever a page is changed or a content item is published, the output cache is automatically invalidated. 

You can achieve this by setting Sitefinity CMS and the Renderer to communicate about cache invalidations. Sitefinity CMS must notify the Renderer when a page or content item is changed, so that the output cache can be invalidated automatically. This enables you to cache for longer periods of time.

To setup cache invalidation, you must configure both the Renderer and Sitefinity CMS.

Configure the Renderer

  1. Open the appsettings.json file of the Renderer.
  2. Configure the following settings:

    Set the cache duration to a longer period - for example, set it to 86400 (24h). You will use the SECRET_VALUE value in the configuration of Sitefinity CMS.

  3. Save and close the appsettings.json.

Configure Sitefinity CMS

  1. Open the web.config file of Sitefinity CMS.
  2. In section <appSettings>, add the following:
  3. Create a service hook using procedure Create service hooks.
    The hook must have the following properties:
    1. In Trigger, select Custom event.
    2. In Custom event type, enter
    3. In Action, keep Send data to URL.
    4. In Target URL, enter https://rendererdomain/sfrenderer/api/v1/cache/purge

      NOTE: The Service hooks UI does not allow adding localhost domains. If you want to add a localhost domain, you need to change it via the file system, after you save the service hook.

    5. In HTTP Headers, add a header with KEY equal to SF_OUTPUTCACHE_AUTH and VALUE equal to SECRET_VALUE
      The value must be the same one that you configured in the appSettings.json of the Renderer.

RESULT: This configuration in Sitefinity CMS allows it to signal to the Renderer whenever a page is invalidated, so the Renderer can purge that page from its cache.

CDN caching

Whenever the Renderer is hosted behind a CDN, you should turn off output cache for the Renderer. This is necessary because the caches can become out of sync with one another. To do this, in the appSettings.json, set the value of Sitefinity:OutputCacheDuration to 0

By default, the CDN cache is controlled through the caching policy for the pages. 

You configure this in the Sitefinity backend » Administration » Settings » Advanced » System » Output Cache Settings » Page Cache profiles » Standard Caching
The Renderer respects this cache profile and will forward the corresponding cache control headers to the CDN.

CDN caching with cache invalidation

To use cache invalidation with a CDN, you need to configure Sitefinity CMS

To do this, perform the following:

  1. Create a service hook using procedure Create service hooks.
    The hook must have the following properties:
    1. In Trigger, select Custom event.
    2. In Custom event type, enter
    3. In Action, keep Send data to URL.
    4. In Target URL, enter https://cdnpurgeurl

By default, the payload of the purge URL will look similar to the following, where URL will be the invalidated URL:

Increase your Sitefinity skills by signing up for our free trainings. Get Sitefinity-certified at Progress Education Community to boost your credentials.

Get started with Integration Hub | Sitefinity Cloud | Sitefinity SaaS

This free lesson teaches administrators, marketers, and other business professionals how to use the Integration hub service to create automated workflows between Sitefinity and other business systems.

Web Security for Sitefinity Administrators

This free lesson teaches administrators the basics about protecting yor Sitefinity instance and its sites from external threats. Configure HTTPS, SSL, allow lists for trusted sites, and cookie security, among others.

Foundations of Sitefinity ASP.NET Core Development

The free on-demand video course teaches developers how to use Sitefinity .NET Core and leverage its decoupled architecture and new way of coding against the platform.

Was this article helpful?