One of the customers had Sitecore 10 initial release installed on Production – everything was working fine till they started adding many new languages and visibility rules to the content they create – in other words they have started to use Sitecore XP in full scale, with personalization etc.
At the beginning everything was working fast and smothly but after few more languages and few more rules added, everything slowed down and editors had to wait aroud 30-60 seconds to load Sitecore Experience Editor and sometimes more complex pages were even able to stop the IIS.
There are at least few well known tweaks that can be applied to improve Experience Editor performance, majority of them are listed on the Sitecore.StackExchange : https://sitecore.stackexchange.com/questions/10627/experience-editor-painfully-slow
I had an ‘opportunity’ to found another case that later was identified by Sitecore Support as known issue with fix number: SC Hotfix 530937-1 (please contact Sitecore Support to get code of it).
Explanation of the issue
Sitecore has very advanced mechanisms checking what exactly should be shown to the visitor and when. Some of the checks are:
- check of the date and time when component should be shown
- check of the personalization rules when component should be shown
- check of user permissions to display/change every component
As you see I emphasize ‘component’ in every aboves point – I do that because complex pages with many components have to run those checks so many more times to show you the page that it significantly increase time of page loading in the experience editor – where you do not have cache enabled.
I was debugging for a while and found this tool as the source of low performance:
It allows to change the date and verify how the website would looks like for certain date – with all applied rules/filters.
The tool seems to use Sitecore.Pipelines.FilterItem.GetPublishedVersionOfItem, Sitecore Kernel processor to prepare data to display it in the experience editor.
I replaced this processor with my one to verify how many times it is called and what operations are being made there and I was shocked with hundreds of requests and checks that are triggered by this processor.
I decided to remove it from the pipeline with code:
<processor type="Sitecore.Pipelines.FilterItem.GetPublishedVersionOfItem, Sitecore Kernel" resolve="true">
<patch:delete />
</processor>And after the patch was applied I immediately noticed that Experience Editor has started to load quickly again (I mean as fast as it is possible for Experience Editor – around 5s).
So, if you also experience very low Experience Editor performance you can try to apply that change and check if it helped – if yes, then I would suggest to contact Sitecore Support and get the official patch.