Finsweet CMS Filter + Load + Nest with 300+ items

Heyyy, what’s up beautiful people! I’m just here to leave a bit of useful information about stretching the limits of Finsweet’s amazing solutions.

I started a project for a real estate agency a couple months ago and decided to put those functionalities to test in a very robust and complex project (based on my previous experience), and I did.

A lot of anxiety came along with the immediate fall in performance of the “Amazing Three”, specifically the CMS Nest. A bit of testing and guessing helped me figure out the problem, but the solution seemed to be gated behind either A) Finsweet+ or B) A developer and a lot of work.

But when hopes were fading, I FOUND IT! It was on Finsweet’s forum (read-only for free users) a post (mostly) solving the performance problem and I just want to put it here for future reference. This has been a pain for a while and I hope it helps who needs it.

Post copy
If your collection to nest is 100+ items you can try this:

For the CMS Nest script use this script:

<!-- [Attributes by Finsweet] CMS Nest -->
 <script defer fs-attributes-preventload="true"  src=""></script>

Child collection (COLLECTION TO NEST)

Use CMS Load set to render-all

  • Enable pagination with 100 items per page
  • Activate Speed Boost

Use CMS Load callback to reinitialize CMS Nest

Add this snippet to </body> tag

 window.fsAttributes = window.fsAttributes || [];
   (listInstances) => {

Original post

Bye bye


hey @Gabriel_Brasil thanks for sharing this! This is for sure something I’m struggling a bit with…

I gave this a try and noticed a couple of things:

  • for some reason I’m seeing a performance decrease when I try this (when it comes to loading the nested list) With this version, loading tags was taking about ~10 secs vs ~5 without.
  • the custom attributes are being stripped from the nested items. For context, I’m loading 100+ tags that are hidden, but searchable in a large grid. They seem to lose the ‘fs-cmsfilter-field’ attribute when trying this. It appears tied to the ‘preventload’ script… going back to the original script syntax returns the attributes and goes back to original speed. The additional /body script appears to have nominal impact.
  • Things are getting a little weird with the parent list using ‘infinite’ and the nested list using ‘render-all’ with pagination. Sometimes it loads additional content in place of instead of after the previous parent list content.

Have you experienced some of the same? I know thats a lot, but any insights would be appreciated as I’ve hit a bit of a wall… the temp solution is to add in an interaction that disables search and says it’s ‘loading’ for ~10 secs… :sweat_smile:


Hey Jon, I think I understood some of what you’re saying.

  • For the performance point, for my case specifically loading my list items was priority number #1, so I could afford to have the nesting delay (it still takes me around 7 sec to nest everything on my 300+ items), so I could get my items then nest my tags. One other thing you could do is to also defer the filter script.

  • Also in the matter of performance, CMS Nest uses caching to perform better, so while you’re building and constantly publishing the site, it will always delete the cache. When it comes to the pagespeed insights, I couldn’t get any higher than 40-50 on performance, but the solution should work once the caching gets going

If you could send a read-only link, maybe I could assist more 'cause I’m pretty sure we have different goals in mind.

Take care!

Hey Gabriel,

Thanks for the follow-up, I really appreciate it! After I did a bit of testing, I ended up scrapping it for now– the delay was a bit excessive since filtering by tag was a primary function. I’ll definitely take a look at using defer for the filter script, and the caching is good to know as well.