Page Performance Guide

This guide will help you troubleshoot performance issues in your Skuid pages.


If you are seeing performance issues, it’s always a good first step to upgrade your Skuid managed package to the latest version.

Salesforce does not allow reverting back to prior versions of managed packages. Because of this, we recommend upgrading and testing your apps in a sandbox org first, before upgrading in a business-critical production environment. For more information, see our Upgrading Skuid SFX topic.

If possible, strongly consider upgrading to a more recent version of Skuid.

Issues usually appear in one of four areas

Apex code processing

When you load a Skuid Page, the Skuid Application takes your page XML and turns it into something that your web browser can understand. Models XML is processed and turned into SOQL queries that are run against the Salesforce Database. Once the result of these queries is returned, the Skuid Application serializes this result into JSON that will be sent to your web browser. Skuid Components can provide their own Apex code to be run if they are included in your page. Any resources that you request in your Skuid page are also processed and sent on to your web browser. Finally, most of the XML of your Skuid page is sent on to your web browser as well to be further processed client side. If you are running into errors such as Apex Heap Size Too Large or Apex CPU Time Limit Exceeded, this is likely the area that needs tuning.

Database queries initiated by models

For Salesforce Orgs with large data volumes, this is typically the cause of most performance issues. Skuid Models make SOQL queries against the Salesforce Database. If those queries are slow, then your page will be slow. Often, making a small change to your queries can mean the difference between 50 milliseconds and 15 seconds.

Network latency

This is the time it takes for data processed in the Skuid Application in Apex to make its way through the internet to your web browser. On modern web browsers with fast internet connections, this is rarely an issue. However, it is good to at least measure this and eliminate it as a possible issue.

Client-side processing and rendering

Once data from Salesforce makes its way to your web browser, the Skuid Javascript code kicks in and starts rendering the components on your page. Modern web browsers will usually perform this task very quickly, but this is a good aspect to measure as well.

Measure, Tweak, Measure…

One of the most important concepts in optimizing any performance is to be careful not to micro-optimize. Micro-optimization is harmful when you sacrifice clarity for some small (or possibly nonexistent) performance gain. Performance tweaks are only useful when they produce faster performance, and we can only know this if we measure it. Modern web browsers as well as the Salesforce developer console include some amazing tools for figuring out exactly why and at what step of the process you Skuid page is taking the most time. The general cycle that we’ll follow is below.


Using the tools and techniques described in this document, measure the performance of the different steps your Skuid page goes through. Since Salesforce is a multi-tenant environment and page load times vary, it is best to run your measurements several times and get a good sense of the typical results.


Once you get a good sense of what areas of your page are taking the most time, apply one of the fixes described in this document that relates to that area.


To determine if your tweak actually made a difference, measure the performance of your page again. If you can see a difference, congratulations! You’ve improved the performance of your page.

Where’s the Problem?

The first tool we’ll use to determine the slowest parts of our page is our web browser’s developer console. In this document we will be using the Chrome Developer Console, but other browsers have similar tools.

  1. Open the Network tab of your developer console.


  2. Refresh your page.


  3. Make sure the red dot in the upper left corner is red for recording.


  4. Mouse over the green and blue bar in the timeline column of the first item in the list.


For now, the item you’re most concerned about is the very first row of the table in the network log. This is the initial request for your Skuid page to Salesforce. The most important metric to look at is the Waiting (TTFB) number in the hover menu. In this case, it took 1.23 seconds for our browser to request the page from Salesforce and for Salesforce to come back with a response. Around 1 second is pretty typical for a Skuid page, but if you were getting times greater than 4 seconds, you know there is probably some server side issues that need to be addressed.

The time between the end of the Waiting (Time To First Byte) and the vertical blue bar is the time that it took your browser to download the rest of the resources needed to load the Skuid page as well as process the logic of all your components client side. From this data, we can make a pretty good decision about what is the slowest part of our page. Also, look through the rest of the items in your network log and see if you can see any anomalies. If you find something strange, post a screenshot of your network log to the Skuid community and we’ll see if we can figure out what is going on.

Diagnosing Server-Side Issues

If by using your browser’s network console, you’ve determined that your performance issues are server side, open up the Salesforce Developer Console and follow the steps below.

  1. Open up the Salesforce Developer Console and refresh your Skuid page. A log should appear in the logs list.


  2. Double Click on the Log in the list. Make sure that the execution overview panel is showing by going to the Debug Menu > View Log Panels and checking the Execution Overview checkbox. Once you see the Execution Overview panel, click on the Timeline tab. Your screen should now look like the screenshot below.


  3. If a large portion of the timeline shows in the DB category, open the Executed Units tab and look and how long it took Salesforce to execute each of your queries.


From this information you can tell if the queries themselves are causing the slowness in your page or if it is other apex processing. If the queries are the issue, check out the Improving Query Performance section of this guide. If it’s not the queries, check out the Improving General Apex Performance section of this guide.

Improving Query Performance

Query performance depends on a lot of issues, but two key factors in determining the speed of your query are:

  1. The total number of records in the object
  2. Indexed fields.

The tips below may help your queries perform faster.

  1. If possible, put model conditions on indexed fields.

    By default Salesforce indexes some fields on most objects, like RecordTypeId, CreatedDate, and Name.

    Check to see if Salesforce has an index on a particular field by looking at the Object definition in Salesforce Setup.

    The fields with the indexed column checked are indexed. Even if just one of the conditions in your model is on an indexed field, this can improve query performance dramatically.

    In some cases you may be able to contact Salesforce Support for assistance with getting a custom index on a particular field.

    For details about the indexes, check out Salesforce’s documentation on standard and custom indexes.

    Generally, indexes improve query performance, but custom indexes may slow query results if used incorrectly. For details about troubleshooting custom indexes, check out Salesforce’s knowledge base article on selectivity and custom indexes.


  2. Beware of the contains operator and negative operators on model conditions.

    Only use the contains operator if absolutely necessary. The starts with and = operators perform better than contains.

    Wildcards at the beginning of a model condition value make it impossible for Salesforce to use an index on that field.

    Operators such as !=, does not contain, does not start with, and does not end with also do not work with an index.

  3. Use the Query Plan feature in the Salesforce Developer console.

    In the Salesforce Developer Console, go to Help Menu > Preferences and check the Enable Query Plan checkbox. Then paste your Skuid-generated SOQL queries into the Query Editor tab. Then click on the Query Plan button.


For details about the Query Plan feature, check out Salesforce’s documentation on Query Resource Feedback.

Improving General Apex Performance

If you’ve determined that the Server Side is the cause of your performance issues, but you cannot find a particularly bad query that could be optimized, you can follow the tips below to increase the performance of your page.

Remove any large inline Javascript or CSS resources

Inline resources in Skuid are meant for small, one-off bits of code. Large inline resources will cause the Apex portion of your page to perform poorly. These large inline resources can be moved to Static Resources where they can be shared among Skuid pages and not slow down the Apex portion of your page load.

Lower the Max # of records (limit) property on your models

If you don’t absolutely need pages and pages of data preloaded into your models, consider lowering the LIMIT on your model queries. Your end users can request more data using the Load more button on tables if they need to see additional data.

Uncheck the Query on page load property on certain models

If you don’t need data from a model immediately on page load, uncheck the Query on page load property. You can use the Action Framework (or JavaScript) to load in that model data at a later time.

Consider using Page Includes

If your page is split up into many different sections, consider using page includes for each section. This way, you can lazy-load the sections of your page when end users request them, not all upfront.

Consider splitting up large pages into multiple smaller ones

Your end users can only look at so much information at once. If you have every piece of data and every object in your system crammed into one gigantic Skuid page, you might be better served by splitting it up into smaller pages that make sense.

Diagnosing Client-Side Issues

After looking at your network tab of your Web Browser’s developer console, you’ve determined that Client Side performance is your problem, follow the tips below.

Use a modern web browser

Self updating, modern browsers like Chrome, Safari, Firefox or Microsoft Edge are the best way to experience Skuid. These browsers are sometimes 10 to 20 times faster than older browsers like Internet Explorer 8 or 9.

Consolidate CSS and Javascript files to minimize HTTP requests

The more HTTP requests your page makes for resources, the slower it can be. However, be sure not to do these kind of optimizations unless your measurements show that it would help.

Reduce the page size of your Table components

The more elements your browser has to render on page load, the slower it will be. Changing the Visible rows property on your tables from Show all to 10 could improve client side performance.

Defer rendering of tab contents property on Tab Set Components

Doing this will let your browser wait to render the contents of tabs until they are opened.

Diagnosing and Improving the Table Filter and Search Performance

Sometimes you notice performance issues not on page load, but when you select certain filters on your tables or queues. These filters are generation SOQL just like your other models on page load, but diagnosing the issue can be a bit different.

  1. Load your page with no filters selected and pull up the network tab of your browser’s developer console. You can clear out the filter list by clicking on the clear button in the top left. Also make sure the red record circle is active.


  2. Next change a filter to execute it and check out your network tab.


  3. Next change a filter to execute it and check out your network tab.

    You can use your Salesforce Developer Console in the same way shown in the Diagnosing Server Side Issues section. Look for a log entry named VFRemoting.


Tips for improving table filter and search performance

Uncheck the Apply filters and Search immediately property on tables

Although this won’t actually improve the performance of your queries, it could improve your users’ experience. With this property unchecked, end users can set all of their filters exactly how they want them before executing a filter. When this box is checked, filters are executed immediately after a filter is changed.

Follow the same principles outlined in the improving query performance section

When filtering a table, for the best performance, you’ll need to adhere to the suggestions mentioned in the section above on Query Performance. If inefficient SOQL is generated by your filters, your response times will be slow.

Specify individual search fields and operators

By default, table searches are executed on all searchable fields. This is great for small data sets, but for larger ones, this can cause searches to be slow. Skuid allows you to specify exactly which fields are searched and which operators to use. Remember that contains operators are the slowest.

Use SOSL to improve search performance

If you check the Use SOSL to improve search performance box, the table will use Salesforce’s specialized search language to do your search. This will usually improve search performance. However there are some drawbacks including the inability to search data on parent records.

Diagnosing and Improving Lookup Search Performance

To investigate lookup search performance issues, follow the same diagnostic steps as in the Table Filter and Search Performance section. Except this time, type a search into a lookup search field. An apexremote line item will show up in your network console.

Tips to improve lookup search performance are the same as items 2, 3 and 4 of the Table Filter and Search Performance section.

Comments or suggestions?

We’d love to get your feedback on troubleshooting methods and tricks you’ve found effective in improving the performance of your Skuid pages. Post your ideas in the comments below or on the Skuid Community where others can find it.

Have fun measuring and tweaking and measuring your Skuid pages!