Typically, slowness when loading a reader portal is based on factors specific to that portal. When a reader portal is loaded, every associated query runs and retrieves all data points within those queries. Therefore, particularly complex or data-heavy queries can cause a reader portal to load more slowly, or timeout. You may need to consider redesigning the portal to be more streamlined. As an immediate stopgap, inactivating certain parts of the view and unlinking the associated queries, will allow you to troubleshoot which queries are particularly problematic.   

We would like to share the following recommendations to troubleshoot your Reader Portal:  

1. Reduce waste - remove or inactivate unused exports from any queries associated with the portal. If your team decides later they need some of these exports, they can always be reconfigured or added back. 

2. Less is more with Reader Portals - try to avoid recreating the entire application in the portal.  

3. Avoid NOT IN - much like the strategy of creating Rules, avoid NOT IN. Instead, think about leveraging EXISTS/DOES NOT EXIST filtering on both the queries and the sections in the View. Similarly, avoid too many OR statements in filtering. More simplistic filters, as well as those written in the positive, are evaluated more efficiently. 

4. Break large queries into smaller queries - if you are using queries in your portal that join multiple tables with extensive exports, consider breaking them up into smaller queries. It can be computationally expensive for Slate to retrieve long lists of exports and subquery exports across multiple tables. Consider creating queries that leverage the exports from a single table. Think Schools, Test Scores, and Applicant Data.  

5. Review existing local filters and exports - are they still behaving as intended? Keep in mind local filters will often not evaluate as efficiently as standard filters and exports. Can the data points be pulled in more efficiently using Configurable Joins?  

6. Simplify the portal - this may result in breaking up a complicated portal into two portals that can be displayed in the Reader. Consider less conditional logic and use of merge fields. Instead, use Liquid Markup or Liquid Looping on tab groups for different portals.  

7. Evaluate the data points - are all data points being pulled into the various parts of the Portal necessary? Do these data points exist elsewhere in the application? What are the benefits of displaying the data in a dashboard? The considerations here can be extensive, but ask what data points are absolutely necessary at the dashboard level because they are evaluated each time a record is being reviewed.  

Latency in the Reader Portal is not just from the behavior of the portal, but other processes running in your instance of Slate, and one of the biggest culprits is data imported through the Upload Dataset tool. This is also true of tools like Query and Report, as their rendering relies on data, large imports running regularly can slow down reports, queries, and rules.   There could be numerous large imports coming into your system over the course of a day. Large imports have an impact on efficiency because when the imports come in and make updates to records or applications, other processes are triggered (like Rules).   A few suggestions to think through to help improve the efficiency of the data imports:  

1. What is the frequency of the imports coming into your system? Do these imports have to happen multiple times per day or can they be limited to once a day, perhaps even during overnight processing to avoid importing during times when your users are working in Slate? 

2. Updating source format setting for Replace Existing Datasets from Inactive: Files are ad-hoc (incremental) to Active: Files are delivered consistently; delete all past uploaded datasets for this source format. This is a cumulative upload that will behave more consistently.  

3. Review all source formats, and where possible reduce the number of columns coming in on the imports. Consider the data points that are currently not being mapped in Slate to determine if they can be omitted from the import.

Reading through and applying some of these suggestions will help to improve the efficiency of the portal(s) in the Reader, as well as tools like Query, Reporting, and Rules. We do encourage you to work with your team on making some of these updates and you should see some improvements. Also consider archiving records and objects that aren't necessary for your work in the current cycle, too. It does appear that you are already utilizing some of these methods, but we wanted to bring attention to them again and describe how they would be affecting your system.