Episerver Caching – The Output Cache Explained

When it comes to improving the performance of your website, performance optimisation is kind of a dark arts subject. One thing that is usually a given, is that if you try and need to do something custom then you’re probably in for an interesting journey. Under the hood, Episerver uses a lof of the standard.NET caching.  In today’s guide, I’m going to cover how to enable output caching in your Episerver website.  This post is the first in a series of applying output caching to your solution.

How Output Caching Works – For Dummys

Output caching is the .NET way of caching your pages and blocks HTML snippets to improve performance.  Output caching works in two flavours, full page caching and partial page output cache differently.  In Episerver, a page and a block can both use full page output cache.  Full page cache refers to anything that has a controller.  In Episerver a block doesn’t necessarily need to have a controller, so some blocks can also be classed as MVC partials.  So, depending on how you define your blocks, the way .NET will cache it behind the scenes may be different.

In .NET terms a full output cache is managed by the output cache module and works with a controller.  The ‘partial’ output cache (no controller) uses MemoryCache out of the box which was introduced in .NET 4.  In theory you can change this to use Redis or a third party cache database.

Output Cache Profile

In case you are new to output caching, the concept is pretty simple.  In your web.config, you create a cache profile. The configuration might looks like this:

<outputCache enableOutputCache="true">
<add name="ClientResourceCache" enabled="true" duration="3600" varyByParam="*" varyByContentEncoding="gzip;deflate" />

The enableOutputCache is useful in terms of deployment.  When you enable caching.. your pages cache.  Enabling output cache in your development environment creates a nightmare because the page caches prevents you from seeing new code changes.  Instead, you can use this property to turn on and off caching between environments.

In the cache profile configuration, the varyByParam is a very useful attribute to be aware of.  The varyByParam property is a semicolon-separated list of params that is used to uniquely identify a cache object.  A cached object might be a whole page or a whole block for example.  In a ‘normal’ scenario queryByParams might relate to Url segments or query string parameters.  IN Episerver though, things like Visitor groups and store in memory, so we need to add in custom code to include these custom parameters.

Output Cache Attribute

To enable output caching on your page, you need to apply the ‘ContentOutputCache’ attribute to either the controller, or, the actions in your controller you want to cache, e.g.

public class StartPageController : PageController<StartPage>
public ActionResult Index(StartPage currentPage)

The next part of the process is to enable the response headers on your page.  If you don’t do this you will see a no-cache set in your HTML requests response header.  To do this is pretty simple.  At some point on a page load you need to add the following code:

public void SetResposneHeaders()

On most of my projects I usually create a base controller.  This code would be good to live in there and get triggered on each page request.

If you compile your website and load it in a browser, the page should cache.  In order to check this, if you look in the pages response header:


You will see the Cache-control attribute is now set. This means that your page is cached 🙂 Also, if you look in the Request header you may see the no-cache attribute set.  You do not need to worry about this, this is fine and dandy. This is part of the process of your browser talking to the server.  This does not mean that your page is not cached server side.


In today’s guide, we’ve covered what the output cache is and how to enable it in Episerver. Caching can be a complex beast but getting the basics up and running is fairly trivial.  All you need to do is create a cache profile in your web.config, apply the output cache attribute on the page or block controller that you want to cache and then on every page request, set the cache expiration policies.  After that you’re golden.

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

More Posts

5 replies

Trackbacks & Pingbacks

  1. […] browser.  The bits that do change are prize contenders to be rendered with AJAX.  This means with output cache enabled and the HTTP expire headers set correctly, your servers will do the minimum amount of […]

  2. […] item for all Episerver websites. If you are unfamiliar with the output cache, I suggest you read, Episerver Caching – The Output Cache Explained . If you have more specific caching requirements, then donut caching can be very handy and allows […]

  3. […] be complicated. In the previous guides we’ve talked about when and why you may not use ‘full page‘ caching and why you might want to implement donut caching. In this post, I’m going to […]

  4. […] the previous articles, I’ve covered how to enable the output cache on the pages and blocks using a full page cachign stratergy, as well as setting custom cache keys/params to deal with […]

  5. […] the output cache in your EpiServer website to get the benefit of HTML caching in your solution in , http://jondjones.com/episerver-caching-the-output-cache-explained/. Now in most website builds this will be all you need, however, when you start to work with more […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *