I think that the main way in which having “too many” Models in your page will affect page performance is in slowing down your page’s initial load time, and the only reason that this is a problem is that the “larger” your Models are, the longer it takes for the following to happen: - server processing of Models: loading Model Metadata, querying for Model Data - transmitting Models’ initial state over the Internets Once your browser has processed your Models initially, performance should be relatively the same regardless of how many Models you have / how large your Models are. As far as what constitutes “large Models”, there are two factors to consider: 1. How much Metadata you are retrieving in each Model 2. How much Data you are retrieving in each Model If your Models are fairly “sparse” — meaning that they request only a few Fields / data rows — you can have tons of them in your pages, and your pages will still load quickly. I have seen pages with around 50 Models, but the Models were all very sparse, and I was only loading in data for a few of the Models — the rest of the Models were placeholders for new records being created. On the other hand, it is very easy to create a Page with only 1 Model and have the page be totally non-functional. How? Remove the “# of Records to load” clause from your Model, or put a really high limit like 2500 records or something like that. Why does this matter? Well, the more data that Skuid has to load initially, the more data that has to be processed by the server, and then transmitted to your browser from the server — even with a fast connection, it takes the server a long time to process 2500 records and get them ready for transmission to your browser. The only hard and fast Model limit that you’ll run into with Skuid is the 6 MB “JSON Heap Size” limit. Skuid gets around virtually all other data size related governor limits, but the Heap Size limit is one that we can’t avoid. How does it work? Well, Salesforce only lets you transmit 6 MB worth of Data and Metadata between Server and Client in a single transaction / execution context — and the format that Skuid transmits both of these in is JSON. So if, in any given communication between server/client involving Skuid data / metadata, you transmit a total of more than 6 MB worth of Data and Metadata, you’ll get a nasty error. Here are all of the things that contribute to this 6 MB, starting with the largest contributors: 1. Data records retrieved for each Model 2. Metadata retrieved for each Model, its Fields, and its Conditions 3. Skuid Page Component metadata (the XML for your Page Components) The most important things to consider when trying to improve Model performance are: 1. Only retrieve Fields that you actually need in your Models. 2. Only retrieve as many records as you really need on initial page load. For “related list” data, 0-10 records (yes, even 0!) are recommended if your users’ first steps will be filtering and searching — why pull in data that will immediately get thrown out when a user goes to search, unless the user will actually use it? 3. When choosing the Fields to have your Model Conditions on, pick Fields that are as close as possible to the primary Object. For instance, when filtering Contacts by Account, filter on AccountId, NOT on Account.Id 4. If you need to Order your Models by a field, Order on Indexed Fields (like Name, CreatedDate). You have a lot of flexibility on 1 and 2, and this is where where you have to spend some time thinking through how your users actually interact with your pages. I highly recommend training users on the use of the “Load More” button at the bottom of Tables. If your users can make use of Load More to pull in more than 10 records on the rare occasions that they actually need this, then this frees you to only pull in a max of 10 records in tables to begin with — which will really speed up your initial Model load time.

Thank you for the detailed response! This is good stuff.

Zach … this is very useful. A related question - we have a client detail page where the account ID is in the URL. We have an Account model that returns a few fields from that account, then about a dozen “related list” models that use that parameter as their account filter (“Client__c = (param) id”). For the related list models, is there a performance difference between filtering on the URL parameter or filtering on the result of the Account model?

Glenn, I don’t think there’s any real performance difference here.

Very helpful! Are there any unique best practices when working with hundreds of thousands of event records and rolling them a filtered list to the calendar component?  I am struggling to keep my Skuid page zippy with my event based models.  

For Calendars, the best practice is to go to your Models’ Advanced properties and set “Load Model data on Page Load” to FALSE (unchecked). This is because the Calendar component automatically queries the Model, as needed, after applying appropriate boundary Conditions on the StartDateTime and EndDateTime fields (e.g. so that only Event records for the currently visible Month / Week / Day will be pulled in). What you can do is to Filter on WhatId / WhoId / OwnerId / Subject, etc, to try to just find Event records that are relevant.