In this tutorial, you will learn how to decide what items should be added to the Episerver output cache using VaryByParams
. Let us say you have personalisation or a members area on your site. it is highly likely you will not want to cache these pages. It would be bad to show your site visitors PPI to anyone expect them. When implementing a cache, you will often need to add rules to tell Epsierver what to cache and more importantly what not to cache. In this tutorial, you will learn all these secrets 🔥🔥🔥
This is not the only post I've written about caching and Episerver. If you want to master page performance, some good reads include:
- Episerver Caching - The Output Cache Explained
- Episerver Caching - Output Caching Strategies Explained... What Is A Donut Cache?
When you cache your pages, you may hit the snag of caching the wrong thing. Let's say you have a multi-lingual website. Your site does not have a unique page Url for each language variation. Instead, it uses a single Url and a cookie to set which language to display. When you enable the output cache, the first time a page loads, the user comes from the UK and the UK version of the page is loaded and cached. Now a visitor from Sweden visits your page, he lives in Sweden and wants the Swedish version of the page. As your website has cached the page in English, he will see the English version even if he had the correct cookie set, this is shit 💩
This happens because out-of-the-box, the .NET output cache works usiing the page Url as the cache key. If your website contains logic that renders custom content on your pages based on cookie values or session data, your site visitors will see strange results being returned from your cache. Common causes of strangeness include visitor groups, membership areas, A/B tests and personalisation. Instead of not catching anything, a better approach would be to cache a version of the page based on a unique key. In our example, caching based on the value of the language cookie would solve the problem.
To cache by a unique key, you need to create a global parameter that will be added to all page requests. When any page request is made, we can use VaryByParams
to define how the cache key works within the OutputCache. Doing this will mean sensitive or unique content will not be cached. Read on to learn how to make this happen 💥
Configuring Your Custom Param in Episerver
The first step is to define a unique cache key with a custom param within Episerver. This is done within episerver.config
file like this:
Add the httpCacheVaryByCustom
property and add a custom parameter name. You can add more than one parameter within here. Simply, separate each key with a comma, e.g. paramone, paramtwo
Setting The Param On Each PageRequest
The next step is to populate the parameter on each page request. You can do this within Global.ascx
file by overriding the GetVaryByCustomString()
method:
In the global.ascx
override the GetVaryByCustomString
method and check if whatever rule you want to use matches a condition. If it does, generate a unique cache key and value. In this example, I check the requests current culture, find the culture code and then set that as the unique cache key. This change would stop Episerver from caching pages in the wrong culture. This is all you need to do to configure your cache to cache by unique settings. You can make these rules as simple or complex as you need 💥
When we find these unique caching scenarios, you need to figure out the unique part of the page is and then creates a custom param in the output cache to differentiate the cache. As long as each rendering variation has a unique cache key, .NET can create different HTML snippets to deal with each scenario. Adding a cache parameter is pretty straightforward. Define the key in Episerver.config
and then in the global.ascx
override GetVaryByCustomString()
method. Check the request based on specific rules and then create a unique cache key. Happy Coding 🤘