Improving Sitecore rendering performance using the HTML cache

There are large performance gains to be had in Sitecore by employing judicious use of caching. As Sitecore developers we should try and be mindful, that performance should be a consideration from the start when building a component. Caching is an important part of ensuring we build performant controls, yet to some caching is a complicated black art best avoided. This needn’t be the case – it is actually very straightforward to take advantage of Sitecore’s built in caching options.

What is the HTML cache?

The HTML Cache in Sitecore, (sometimes referred to as the output or web cache) is a mechanism that stores the rendered output of a component in a key based table. Every time Sitecore renders a component on the page, it checks the HTML cache to ascertain if the cached output is present. If it is, it is retrieved and rendered immediately otherwise it goes through the normal process of running the rendering pipelines and constructing the output. If you’re not employing caching for your site, you’re leaving a lot of performance on the table.

How do I use it?

The HTML Cache is employed by selecting appropriate caching options on the Rendering itself or on the Presentation details for a component. 

To enable caching select the Cacheable checkbox. We must then decide how we want the cache to be created. This will vary depending on the type of component and it’s use case. Varying the cache by a given parameter means we would like Sitecore to create an individual cache key for every variation of that parameter. e.g. if we Vary by Data[source] we are telling Sitecore want to store a cached version of the component output for every different data source it encounters when rendering.

The available options that come with Sitecore are:

  • Clear on Index Update: Indicates that the cache should be cleared when the index is updated – if your code depends on an index, selecting this will help prevent any race conditions occurring between HTML caching and index update operations.
  • Vary By Data: Generate a cached version per data source
  • Vary By Device: Generate a cached version per device
  • Vary By Login: Generate a cached version for authenticated users and one for unauthenticated users
  • Vary By Parm: Generate a cached version per rendering parameter
  • Vary By Query String: Generate a cached version for each unique combination of querystring parameter
  • Vary by User: Generate a cached version per authenticated user

How does it work?

A component is rendered by Sitecore and if the caching options are set, a cache key is constructed. The name of the key corresponds to the caching options selected. See below for the format of the cache keys from the Sitecore documentation:

  • Vary by Data –The cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#data:[Path of the Datasource Item]
  • Vary by Device -The cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#dev:Responsive
  • Vary by Login – The cache key is:  controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#login:False
  • Vary by Parameters – The cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#parm:[Key=Value]
  • Vary by Query String –The cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#qs:[request.QueryString]
  • Vary by User – The cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#user:[user]

Once this key has been generated, the rendered output is stored against this key. The cache key is checked the next time a control is rendered (by a pipeline in the Sitecore.MVC DLL – Sitecore.Mvc.Pipelines.Response.RenderRendering.RenderFromCache). If it is present, the stored output is rendered rather than executing the relatively slow process of constructing the model and rendering the output again.

Note: Bear in mind if a cached rendering contains placeholders which contain other components or statically bound renderings when these are also cached with the parent.

Can I override a rendering’s default cache settings?

Default caching options can be overridden by changing the settings on the presentation details for a component.

How can I check if my rendering is cached?

There is no built in tool with Sitecore that allows you to easily inspect the cache keys that have been constructed in the HTML cache. To do this you need to write your own inspection page or tool. Alternatively you could install Sitecore Rocks – the tool that integrates with Visual Studio which allows you to view the cache keys. To do this Manage your site from within the Visual Studio Sitecore Explorer and select the caches tab. Scroll down to “yoursitename[html]” and double click it. The Explore cache window should appear and you should then be able to see the cache keys currently in the cache e.g.:

Sitecore Rocks allows you to see the cache keys in use

 Note if you experience problems getting Sitecore Rocks to work with a Sitecore 9 installation, see this post here on how to resolve it:https://sitecore.stackexchange.com/questions/9659/create-connection-for-sitecore-9-instance-with-sitecore-rocks?rq=1

How to measure performance

Cache tuning is a fine art and you will want to measure how your changes are affecting the rendering performance. To do this there are a few options. The first is to use the Sitecore debugger which is accessed through the Experience Editor -> Experience Tab -> Other button -> Debug or alterntively add “?sc_debug=1” to the current page URL in a browser.This will add very useful detailed information below the page such as a profile of the full rendering pipeline detailing timings, cache hits and item reads as well as tracing information showing each step Sitecore pipeline executed when rendering out the page. Analysing the timings here and looking at the Hotspots sections can help you target problem renderings and ensure you optimise the slowest renderings first.Another alternative is a tool like JMeter to run load tests against a URL and measuring the before and after results.


This just scratches the surface of Sitecore’s caching capabilities, but hopefully it will have given a small insight on how to get started with caching your Sitecore renderings.

2 Replies to “Improving Sitecore rendering performance using the HTML cache”

  1. Nice article.
    Actually, I have a different and interesting issue.
    Setup:
    There is a component for which cache setting of the rendering is marked with Cacheable, VaryByData, VaryByParam, and VaryByQuerystring and there is only one data source to this rendering. But this component is placed on multiple pages (different URLs) and part of the component reads the data from page fields and another part from the component’s data source. Which is making the data being cached which is resulting in data of last page visited gets displayed on the page. Its like I need to mark this rendering as cacheable to increase the performance but can not mark it at the same time due to wrong data displayed. Any idea?

Leave a Reply

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