How can you decrease load times on large Catalog Items?

[Shane J]

We have (at least) one exceptionally large Catalog Item used for requesting new computer/systems access.   It currently has the following, with little chance of any of these numbers decreasing:

• 120+ Catalog UI Policies
• 10 Catalog Client scripts
• 450+ variables

The problem is load time.   I have seen Requested Items or Catalog Tasks that have the Request Variable for this form take 10 seconds or more to load.   Since essentially one team works on these, their love of SN is wavering quickly.  

So I'd like to know how others are handling this same issue?   I'm not even sure how to attack it at this point.

[Shane J]

Having separate items only works if those items end up with different groups.   We made the mistake of trying to do separate items for hardware orders, and that group almost mutinied because they'd receive 5 RITMs for a single order.   Maybe that's more correct, but it's not the way we do business right now.   Our Systems Security group needs the form in its entirety (for auditing purposes), and Tasks are created as needed in many cases.

And yes, the form is a huge pita to fill-out, but I don't get to dictate the content.  

[Kalaiarasan Pus]

Logical solutions are already laid out. So I am not getting into those areas...

Few Technical things you can lookout for..

Is there possibility to reduce the number of Ajax calls ? Does all the sync calls need actually be sync based and can't it be async?

Can variable sets be used instead of individual variables? I guess, hiding/showing the variable set would be faster.

[Community Alums]

I'm not sure I understand the problem with five RITMs for a single order. The Requested Items are all part of a single request, so everything still has a grouping, but each of the different items can then have their own steps for preparation and deployment beyond the actual sourcing of the items. You get what you need together in one place for auditing but still have the breakdown to create the forms properly.

[Shane J]

That was built during our initial implementation and (likely) wasn't setup like it should be.   If you had seen the end product, I think you'd understand...

Anyway, we are looking to try to split this form up some.   At least the initial form will load much quicker, as well as any children forms.