In 2017 I wrote a reasonably long post on all the different considerations a Sitecore Caching Strategy might cover.
Following on from that post its time to share some custom HTML cache extensions that we at Aceik may incorporate into our projects. This count down of custom settings has been collected from across the Sitecore community.
5) Vary By Personalisation
This one (in my opinion) is a must-have if your incorporating personalisation in your homepage.
I admit it will only be effective up to a certain number of content variations and even then needs to be used with caution. Still, if you can save your server and databases from getting hit and help keep Time to First Byte (TTFB) low, its always worth it.
Please note that if you’re displaying a customised message with data that is only relevant to that user, the number of variations may not make it worthwhile. On the other hand, if your showing variations based on a handful of profile card match rules, we found it to be fairly effective.
Code Sample: ApplyVaryByPeronalizedDatasource.cs
Credits: Ahmed Okour
4) Vary By Resolution
Its a fairly common scenario that we want to display a different image based on the users screen size. So it stands to reason that we would need a way to differentiate this when it comes to caching our Renderings.
The particular implementation was used in combination with Scott Mulligan’s Sitecore Adaptive Image Library.
The Adaptive Image library stores the users screen resolution via a cookie in the front end razor/javavscript:
document.cookie = '@Sitecore.Configuration.Settings.GetSetting("resolutionCookieName") =' + Math.max(screen.width, screen.height) + '; path=/';
- The first time around if no cookie is set it uses the default largest image size as the cache key.
- If the cookie is set the cache incorporates the screen resolution.
args.CacheKey += "_#resolution:" + AdaptiveMediaProvider.GetScreenResolution();
Code 1: ApplyVaryByResolution.cs
Code 2: AdaptiveMediaProvider.cs
Credit: Dadi Zhao
3) Vary By Timeout
This one’s a little different, it requires not only a new checkbox but also a new “Single-Line text” field that allows you to enter a timeout value. The idea, as you might have guessed, is for the rendering cache to expire after a certain amount of time.
Code 1: ApplyVaryByTimeout.cs
Credit: Dylan Young
2) Vary By Url
An oldy but a goody. I’m a little surprised this one just hasn’t made it into the out of the box product. On the other hand, I can see how it could be overused if you don’t understand the context it applies to. Essentially you can take either the Context Item ID or the raw URL and make your rendering cache vary based on that key.
A good use case for this setting could be for navigation that requires the current page to always be highlighted.
Code 1: ApplyVaryByURLCaching.cs (Context Item ID formula)
Code 2: ApplyVaryByRawUrlCaching.cs (Raw URL formula)
Credit: The 10 other people that have blogged about this over the years.
1) Vary By Website
Given Sitecore is an Enterprise content management system we often see multi-site implementations launched on the platform. It makes sense then that you have an option to cache renderings that don’t change all that much on one site but have different content on another.
Example Usage: A global navigation used across all sites that requires some content for the context site to show differently.
Credit: Younes van Ruth
That rounds out the count down of some of the top ways to extend Sitecore’s out of the box rendering cache. Your renderings will likely use a combination of these settings in order to achieve adequate caching coverage.
For a better idea on how you might add the top 5 above into Sitecore. Please see the technical footnote below.
All these extensions will add an extra checkbox in the Rendering cache tab within Sitecore.
In order for this check box to show up you need to add your custom checkbox fields to the template:
You can achieve this in several ways. and there are a lot of other blogs “on the line” that describe how to add in these custom checkboxes so I won’t go into a deep dive here.
With regard to the Helix architecture lets outline one way you could set this up. Aceik has a module in the foundation layer that has all the custom cache checkboxes added to a single template (serialized in Unicorn within that module) . The system template above is then made to inherit from your custom template in order to inherit the custom caching fields.