Page Performance Guide¶
This guide will help you troubleshoot performance issues in your Skuid pages.
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.
Measure¶
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.
Tweak¶
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.
Measure¶
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.
- Open the Network tab of your developer console.
- Refresh your page.
- Make sure the red dot in the upper left corner is red for recording.
- 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.
- Open up the Salesforce Developer Console and refresh your Skuid page. A log should appear in the logs list.
- 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.
- 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 of the biggest factors in determining the speed of your query is the total number of records in the object that your query is based on and the ability for the query to utilize an index to get at results faster. The tips below will help your queries perform faster.
If possible, put conditions on indexed fields.
You can 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 your query performance dramatically.In some cases you may be able to contact Salesforce Support and they will assist you with getting a custom index put on a particular field if needed.
Beware of the contains operator and negative operators on conditions.
Only use the contains operator if you absolutely must. The starts with and = operators will perform much better than contains. Wildcards at the beginning of a condition value will 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 will also not be able to use an index.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 SOQL queries generated by Skuid into the Query Editor tab. Then click on the Query Plan button.
To better understand the results from this 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 Javascript or the Action Framework 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.
- 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.
- Next change a filter to execute it and check out your network tab.
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 specialize 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!