Identifying Sitecore Performance Bottlenecks

After been doing a lot of application code reviews with the sole purpose of identifying performance bottlenecks I thought I would share the very simple set of tools we normally use at Alpha Solutions.

An important note: In most of cases it’s already too late when we’re brought in. The application might be bad architected, having unnecessary logic and code – and sometimes shows a lack of Sitecore knowledge. But business need to get the site live – fast – “yesterday” would be the best.

With that offset we are looking for easy fixes and wins – not going in detail, refactor major parts etc. So what tools to use in this situation?

Start by using the obvious tools: PageSpeed and

Both PageSpeed and webpagetest are very easy to use and very helpful. It often identifies a lot of easy ways to get better performance (and a lot of stuff that is hard to do something about fast :-)).

But not knowing anything really about the application, these gives the obvious hints, and for most part some of the easy fixes.


Things the we often find using these tools:

  • Optimize Image size & service scaled images

Mostly easy stuff to do. There’s a lot of good tools and libraries for that. Some situations demand from logic though; on e.g. responsive sites where the browser resizes, images must scale accordingly. Those situations are not that easy –  but on general there’s a lot to gain from optimizing your images. This is also the situation where you would have Sitecore serving a scaled image that fist the original size for the requesting device, but if the user resizes you would most like request the same size (original). Anything else would require some extra logic.

  • Use gzip compression

This is an easy fix – and no code required. Almost any client nowadays supports gzip compression meaning that the content from the web server and to the client will be compressed. There’s a lot of post explaining how to enable this.

  • Minimize Redirects

Avoid all those redirects. Especially when sites tend to get longer chains of redirections – this is really hurting the experience for the user.

“SEO Experts” all have different views on the value of redirects. We have experienced clients where multiple redirects were a “good thing” due to the SEO expert’s advice on keeping the “SEO juice”. I understand it makes sense to handle redirects for request coming from other sites, but from within your own site, this is just stupid (sorry).

  • Minification

Normally also an easy fix. As a hack you can simply use online tools to get js, css and maybe also html/cshtml file minified. Looking ahead you should use tools for that (There’s a lot to choose from).

  • Blocking javascript / defer parsing of javascript

If you can avoid it – get your javascript placed so that it will not be loaded during the first page load. Especially if it’s not needed on the first page load. Also avoid evaluating javascript until the full document is loaded.

  • Lazy load of images.

Normally this is not always an easy fix – but worth mentioning. Sometimes we see a lot of images being loaded before the full document is loaded. This is bad as the page will not start to render for the user. Best solution is to lazy-load all images – starting with images above the fold. Again – libraries, scripts and jQuery plugins exists for this.

Check the system “health condition”

Before you start looking for the bottlenecks you should do the obvious – check the logs. That normally tells a lot about what’s working and what’s not.

  • Check the Sitecore logs
  • Check server’s system logs
  • Check system performance counters

You can’t make Sitecore Rock’n’Roll if the foundation shakes the Blues – so to speak.

Get the site up running locally

Normally the next step we take is to get a copy of the site. That will not be a production setup at all, and that is not the purpose really. We want to identify application bottlenecks. For that Sitecore has tools that’s very helpful.

Also – get a copy of the source code so you can look at the code, and identify exact fixes, and also try to make changes as you work through the optimization.

Use the Sitecore Debugger

Sitecore Debugger is great for identifying the components that performs. Don’t go into details about the exact numbers – that doesn’t matter. Focus on the identifying the top 3-5 worst performing components.


Use that information to take a look at the code behind those components. Also look at how caching is set up – often we that caching hasn’t been considered at all. And “yes” – I can be complex if a lot of personalization will be used on the website. But normally – that’s not the case.


Cache.aspx (/admin/cache.aspx)

The cache.aspx give you an overview on how the caches are set up, and how the change over time. Use to check for cache configuration – are the caches configured with the correct sizes etc.


A Note on custom caches

We often see that developers have used HttpContext for some custom caching – instead of using Sitecore caches. Both things will work, but using Sitecore cache will make these custom caches appear on the cache.aspx – which is pretty useful.

If you create custom caches, you have to remember to identify when and if these caches must be cleared on publishing. We often see that missing actually. So remember to create a processer that can be triggered on publish:end (and publish:remote:end) that handle the needed clearing of your custom cache:


Pipeline Profiler

The pipeline profiler is another useful tool that helps you to identify processors/pipelines that take up most of the execution time. With that information you can concentrate the effort looking at the identified processors. There is fine post about that here:

Time measure

At Alpha Solutions we have created a small simple tool to help measure execution of code. We always include this in our running projects, as this is very light weight.

Below an example of the output of this tool (A rather extreme example). There’s two things to notice here. First off all, the obvious average execution time – column “average ms”. Secondly, and often more important –  the column “N” – the number times a specific method is executed. So even if the method is pretty fast, it can still a bottleneck.


The tools demands that we add using blocks to the code that we want to “measure”:


There are a lot “professional tools” that can help you doing the same type of measurements. We do not use this tools for exact measurements. We use this tools to quickly identify bottlenecks and help the business getting their performance issues solved short term.

A note on Solr and Lucene

Another thing we often see is rather big solutions still using Lucene instead of Solr. That often hits performance, and sometimes hard. Setting up Solr instead up Lucene is not that hard – not at all actually.

Other Sitecore admin pages worth looking into

Sitecore ships with a number of very useful admin pages worth getting familiar with. This cheat-sheet is very helpful:


The offset for this blog was to share a number of simple and easy tools to identify bottlenecks in Sitecore applications. These are the tools we usually use at Alpha Solutions when we are asked to help out on solutions that client struggles to get into production. Remember, the intention is not to re-code or re-architect – it is to get in to production – now. After that, we can look into re-factoring. I hope you find this blog helpful.

Identifying Sitecore Performance Bottlenecks
Tagged on:             

Leave a Reply

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