Try our conversational search powered by Generative AI!

Will there be any performance improvement if we use property list instead of contentarea to build accordions?



We currently have the contentarea which holds the accordion items, as it is possible to do similar job using property list will there be any difference between two approaches, which is most prefered one?



Mar 04, 2022 7:06

We commonly use IList<T> for such properties, just know that you miss out on personalization, permissions, and display options etc for each item.

Performance-wise it would have minor impact for rendering, but depending on requirements the IList<T> version could be faster for editors during publishing (fewer clicks).

The IList<T> approach may also be simpler for developers when implementing rendering, as the items are available without first having to filter and get the content for each content area item.

Edited, Mar 04, 2022 9:24
Deepa Puranik - Mar 04, 2022 10:00
Thank you Ted for explaining on PropertyList.

Hi Deepa,

I suspect there would be slightly better performance using a list property though that will depend on the implementation and, importantly, it comes with trade-offs.

If you create a property which is an IList<AccordionItem>, the data for each of the accordion items is stored serialised as part of the page so there are no furter calls required to get the data from a ContentReference which makes this probably the best performing of the options. The downside of this approach is that the content of the accordion items isn't reusable and you would need to put in extra effort to make the list neatly editable in on-page edit view. Additionally, PropertyList<T> properties are described as "unsupported" in the documentation

You could create the accordions using an IList<ContentReference> property which would resolve the issue of content reuse and, as I recall, is a supported property type however you'll now need to get the content for each ContentReference in order to render the item and, as with the first approach, you'll need to put in the effort yourself to ensure that the property renders nicely and is editable in the on-page editing view. In terms of performance, This could possibly be marginally better performing than a contentarea as you could potentially shortcut the template resolution process and you won't have the same filtering applied that you get with a ContentArea though I'm not convinced any performance gains would be that noticeable.

My personal preference would be to use a ContentArea for a few reasons, the main ones being:

  • Content reuse - individual accordion items can be reused across different pages and blocks
  • Editor experience - by using a content area you get the best on-page editing experience, even more so with the "quick edit" functionality in newer versions of the CMS
  • Personalisation - with a ContentArea you can target content using visitor groups
  • Flexibility - If needed, you can intersperse the accordion items with other content (e.g. headings, images, etc). You can also allow different display options to be chosen for each
  • Maintainability - The ContentArea property type is fully supported and, if you need to change or extend your accordion item content model, that's much easier to manage for a block than for a type used in a PropertyList.

And, given the internal caching used when retrieving content from the CMS, I don't think the performance is much of a deciding factor.

Edited, Mar 04, 2022 9:50
Deepa Puranik - Mar 04, 2022 9:59
Thank you Paul for detailed explanation on pro's of using content area.
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.