After working with the Sitecore platform for a few years I’ve summed up a few useful tips which I’ve used to enhance the setup. These are mainly based around optimisation but also cover some other issues that can arise. As with any architectural decision it’s best to plan these as early as possible, but the following should be considered whether you already have an instance setup, or if you’re about to embark upon a new project:
Trim your versions
Versioning is something which can be overlooked but our out of the box Sitecore instance will create an endless amount of page versions which carries a very large performance implication. Each time an editor changes a page they create a new version, so we could end up with literally hundreds of versions of pages on our site, most of which are not required.
We need to limit the amount of versions for our Sitecore items. The first tip is to implement a rule to limit versioning and if you don’t read any further, at least pay attention to this step and ensure that you limit your page versions to a useful number such as ten.
There is a common problem for those with more than a handful of content editors whereby editors will often need access to a file has been locked by another user who has forgotten to check it in. For good reason Sitecore out of the box doesn’t allow users to unlock another users items and if organisational governance dictates that only admins can unlock files we’re restricted to the following options:
- Make sure editors are educated to check in any items that they have locked – This is unreliable and doesn’t account for human error.
- Ensure that the users can always contact an admin – this places a dependency on an admin and could be quite time consuming for them which doesn’t help efficiency.
- Write and admin tool to allow mass unlocks – This could be useful but still requires an admin to be present who would have to issue caution when using such a tool.
- Make editors an admin – This is a bad idea for obvious reasons. Also, when an admin edits a page it doesn’t automatically create a new version so it adds a requirement for them to remember to manually add a version.
The best solution is to reduce the dependency on an admin by creating a new user access right. We can then allow editors to unlock certain items within Sitecore that have been locked by other editors. Obviously this still requires governance and education in the use of the new feature, but it resolves our issue.
Publishing impacts data, item and HTML cache so we need to use it sparingly and there needs to be a reason for anything other than a Smart publish of items.
It is important to assign the correct user access rights to restrict publishing options. If a user has all publish options available to them they will likely use them so accounts must be restricted, ideally to a Smart publish only. We can restrict the publish options available to our users by setting security in the Core database. It probably goes without saying that a full site publish should be a rare thing, as should a full search re-index.
Patch your configs
This is an absolute must. Patch your configs and leave the originals well alone! For one, it will make life a lot easier when you upgrade a Sitecore instance.
Patch files by default are stored in App_Settings/Include but this setting can be overridden within Sitecore. Don’t forget the ShowConfig.aspx admin tool to view the results of your patch files.
Use Sitecore NuGet
As the title says, make use of the Sitecore NuGet feed and if you’re using VSTS for CI/CD be sure to read the following article.
You should also be using a NuGet package restore for a clean development environment and smaller repository size.
Avoid performance degrading methods
Methods such as GetDescendants in the content API will impact upon site performance as your site data grows. A Sitecore instance which is making heavy use of such methods will suffer from slow performance, instead we should use a Sitecore search API which will make use of Solr/Lucene for queries.
I have also seen performance issues with large Sitecore trees. If for example you have 200 child items which all use a template with a Treelist field, a simple switch to the TreelistEx field type will offer a significant performance increase. We should conduct an audit of our templates and ensure that the field types have been optimised. Obviously we also need to consider buckets.
Although we need to think about the values of Prefetch, Data and Item Cache in our config files I wan’t to remind us of a very obvious tip which is to make your renderings cacheable. There are very few occasions where I have had to completely switch off caching on a rendering, so you should check all renderings and ensure that some form of caching is enabled.
Implementing this software design pattern allows us to swap our providers, unit test, and ensures that our code is loosely coupled, reusable and maintainable. However, the use of a DI container carries a performance hit so we should study the DI container benchmarks and choose accordingly. Obviously we should be aware that with an IOC container we can lose compile time checking, and we must carefully think about this architectural decision.
Fields should contain user friendly titles to assist our content editors, this is a fairly obvious step but it’s one that’s often ignored.
Using IIS redirects is best for performance but if for any reason you’re not doing this you need to handle them in Sitecore. We have access to alias’s but it’s a good idea to setup your own 301 redirect component and manage your redirects as items in a folder. Remember to give your folder structure some consideration. It’s easy enough to create your own module or you can follow a 301 redirect setup guide.