Wednesday, September 28, 2016

Improving and optimising the performance of your Sitecore website

Statistics around user behavior and page load times is a good bit of background reading on how users perceive the performance of a web site. The standout pieces of information for me was that:
"A 1 second delay in page response can result in a 7% reduction in conversions."
 Along with:
"40% of people abandon a website that takes more than 3 seconds to load."
This then sets the scene for why optimisation of a Sitecore website might be important to the end-users. For Sitecore websites which have a sales/lead generation component, there will be less conversions if the performance is not optimised.

Optimise the front-end

The first thing I always do is take a look at the website using the YSlow tool. This is a browser extension that essentially gives a rating on how well a given page will perform. They key areas it looks at is around the number of HTTP requests, CDN, compression, location of JavaScript/CSS (page blocking), minification and so on. It's a great starting point to get Sitecore optimised and often makes one of the biggest differences to end users.


The main outputs after using this tool should be:

  • CSS/JS bundled and minimised where possible
  • Any third party fonts or JavaScript libraries (jQuery) using CDN where possible
  • Images optimised in terms of size and kept minimal (use sprites in your CSS for example)
  • Static and dynamic compression enabled (this makes a big difference with those JS libraries)
  • Keep the HTTP requests to a minimum, once under load these exponentially affect performance

Optimising the caches


Database caches: Inside Sitecore.config (or web.config) will be a database section for Master, Core and Web. These caches are used to store data coming from the SQL databases and will lead to less database calls and ultimately better performance. The default values are generally not enough for smaller Sitecore implementations and should be optimised in a testing environment for every Sitecore website you work on. The http://server/sitecore/admin/cache.aspx page can be used to monitor these caches and in turn work out the ideal values they should be set to. There are plenty of blog posts/guides on correctly configuring these cache values.


Prefetch caches: When Sitecore is starting up, one of the tasks is to prefetch some data from the various databases, ready to use. These caches are configured in the files available in Website\App_Config\Prefetch and by default will hit key templates, items and item children. Recently I discovered that for the web prefetch cache, Sitecore attempts to cache the default home item and it's children. As many implementations use a custom home item, this is an example of a cache configuration which could be changed. This cache will have a minor impact on startup time, which should be okay on production environments, but will affect developers on their environments.

HTML Output cache: When you use caching for sublayouts/renderings, this data is stored in the HTML output cache. On the Site element for your web site (found under <configuration><sitecore><sites>) there is a variable called htmlCacheSize which controls the size of this cache. By using the cache administration page mentioned above, you are able to see if this cache is adequately sized. Remember to check this page on content delivery servers in a scaled environment, as these are the ones mainly serving data from this cache.

Optimising the database

SQL Server Index Fragmentation: For existing Sitecore implementations which have been active for some time, one area to investigate is the fragmentation percentage of SQL Server. As Sitecore puts it:
As indexes age, insertion and deletion of noncontiguous data can take its toll and cause fragmentation to occur. This can happen in just a few days on a busy CMS database. Minor amounts of fragmentation won't generally hurt performance. But as the percentage of fragmentation increases, performance suffers dramatically.
Your SQL Server database administrator should be able to help run the Index Physical Statistics report, which will then show which indexes have a high percentage of fragmentation  (over 10% is bad). The defragment indexes maintenance plan being run will solve these issues but ensure to make backups beforehand.

Further reading

These are some of the key areas in which I focus on and have found to provide the most benefit to optimising the performance of a Sitecore website. Of course this assumes that the custom code used on the website itself is optimised and running well. 

No comments:

Post a Comment