While Sitecore continues to extend Content Editor functionality to the Experience Editor, Content Editor remains the interface of choice for developers and power users. Its performance can significantly impact the productivity of any development team. With the fairly simple adjustments I outline here, you can optimize Sitecore Content Editor performance and usability.
Tweaking the Tree Structure
A common culprit when performance degradation occurs is the Content Editor tree structure. The number of items under a parent item impacts how quickly that parent unfolds. Sitecore recommends that the children or items under any parent item should ideally be limited to 60 or fewer, and should not exceed 100. Having more than 100 items per folder will eventually result in slow response and increased loading time when a user starts to expand items. If a single folder item contains more than 100 items, it’s the right time to re-organize content.
This guidance sounds simple enough to implement, until you encounter a project where business constraints prevent making changes to the tree structure. For example, product information may need to be imported from an external service (PIM). In such situations, adding these three settings will improve navigation and the overall Content Editor experience:
<setting name="ContentEditor.CheckHasChildrenOnTreeNodes" set:value="false"/> <setting name="ContentEditor.RenderCollapsedSections" value="false" /> <setting name="ContentEditor.CheckSecurityOnTreeNodes" value="false" />
Usually, it is good to consider applying these through the Sitecore patching mechanism per targeted environment. Keep in mind that:
- RenderCollapsedSections is a hidden setting and it can help a lot.
- CheckHasChildrenOnTreeNodes and the ContentEditor.CheckSecurityOnTreeNodes typically only enhance speed in cases where the folder has more than 500+ items.
It’s also important to note one downside to disabling CheckHasChildrenOnTreeNodes: Sitecore doesn’t know if there are child items under a single folder. When set to “false,” the user will see a black arrow pointing next to the item, suggesting that there are child items. The user can’t tell there are no additional items until he clicks on the folder, at which point the arrow indicator will disappear. When set to ‘true’, Sitecore checks if there are additional items stored and, if not, hides the arrow automatically.
Removing Item Versions
If items have more than 5 versions and performance issues are still noticeable, you should consider removing item versions. This code snippet (credit: Maryna Veller) is from a Powershell script that does just that:
$folder = "/sitecore/content/products/data" $items = Get-ChildItem -Path $folder -recurse foreach($item in $items){ $versions = Get-Item -Path $item.FullPath -Version *|foreach-object{ if($_.Version -ne $item.Version){ $_.Versions.RemoveVersion() } } }
By using Sitecore Powershell Extension plugin and defining the root item folder ($folder variable), this script will remove all previous item versions.
One final thing to check is how items and templates are actually defined. ‘Rich Text Fields’ and the amount of data stored in them can affect performance. In rare cases where there are more than 1000 items under a single folder item, storing a lot of content in Rich Text Fields (>500kb) can significantly decrease performance and increase memory consumption. Also, based on the value size of individual items, the action of expanding tree nodes places these objects in LOH (Large Object Heap) and GC doesn’t clear them until full garbage collection.
Great post! Thank you so much for sharing it.
You’re welcome…
Great post Ivan. Only one small drawback is related to Sitecore bug (I tested from 7.2 to 9 and reported). If RenderCollapsedSections is set to false, reset fields dialog will throw error 500 on trying to collapse/expand section under it.
Good catch Marko. Thanks for the additional info.
Pingback: Improve Sitecore Experience Editor Performance by Disabling Number of Locked Items Counter | Brian Pedersen's Sitecore and .NET Blog