We have an xp app that uses option-sets in all content-types. This allows the editor to keep adding components to a page, while still retain the data in the page’s index (We made this before parts were indexed correctly). On some of these pages the option-set contains alot of data.
This seems to slow the frontend down in content studio. The backend initially delivers the html pretty fast, but the page still takes 30-60 seconds to actually render.
In the network tab I see a huge amount of requests to an “authenticated” endpoint, but it also seems to load the same css resource over and over again. (I suspect for the wysiwyg editor)
How many option sets on a page are we talking about here, when the page starts slowing down?
We did have a similar issue when a schema contained an option set with several content selectors and date pickers. There was a crazy amount of option sets on a page, with total number of selectors and pickers approaching 300 or something like that. It took more than a minute to render such a page.
We fixed it by optimizing the rendering of controls with dropdowns so that a dropdown won’t get rendered until it’s expanded by a user.
If your option set contains content selector(s) or date/time picker(s) then I’m pretty sure it’s the same issue. I suggest you wait for the release of 6.14 (which is a couple of weeks away) and the problem will be solved.
You are correct, the number of option sets are getting pretty big. We have alot of html editors and content selectors within the sets. One of the slower pages has 11 options to choose from in the opton-set. And they have inserted 9.
So not that many in numbers, but the data behind each option varyes in complexity.
I will test this with 6.14 and see if that solves the issue.
