Sitecore Content Editor: Performance Tips

Sitecore Content Editor: Performance Tips

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.

Tweaking the Tree Structure: One more approach

There is another one option to organize Tree Structure that Sitecore provides from the box. The name of it is Item Buckets.

item-bucket

Item buckets let you manage large numbers of items in the content tree. An item bucket is a container that you can use to hide innumerable items and still easily retrieve and work with these items. The only way to find bucket items is to use the Sitecore search engine.

Official documentation from Sitecore: https://doc.sitecore.net/sitecore_experience_platform/content_authoring/managing_items/item_buckets/item_buckets

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 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.

Last but not least

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.

Enjoy!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s