You are here:
Performance Insights
The Performance Insights dashboard focuses on four core metrics for page performance, which it measures and presents in different ways to provide useful insights. These four metrics appear at the top of your report.
| Metric | Details |
|---|---|
| First Page Experienced Page Time (EPT) | Page load time for a complete page load, including Lightning Experience bootstrap (framework initialization), measured in milliseconds. (Divide by 1000 to get the number of seconds.) Typically, only the first page that a user visits in Lightning Experience requires Lightning Experience bootstrap. You can’t affect the time it takes for Lightning Experience bootstrap — that’s our job, and we’re always working on it. Because it adds significant time to the EPT, we measure and share it, but Subsequent Page EPT represents the more typical user experience. |
| Subsequent Page EPT | Page load time for other pages, after Lightning Experience bootstrap, measured in milliseconds. This metric typically accounts for any page a user navigates to after loading Lightning Experience. Without the need to reload Lightning Experience, this metric is typically faster. While First Page EPT represents a first impression or start of session experience, Subsequent Page EPT is the better measurement of how your users experience Salesforce as they use it throughout a working session. |
| Total Page Views | Total number of page views over the 7-day period. You can use it as a way to track increasing usage of your Salesforce implementation. |
| First Page Views, % of Total | Proportion of all page views that are first page views. This ratio gives you a meaningful insight into how your users experience working with Salesforce in Lightning Experience. This number is normally low, a minority of overall page views. If you see a larger number, review the business processes performed in Salesforce and consider optimizing navigation or other processes to make it easier for users to stay in Lightning Experience. |
Embedded ApexGuru Insights
When you access a report, ApexGuru recommendations are automatically embedded in your Lightning Experience Performance dashboard. Click a hyperlinked action name to open its ApexGuru insights in a new tab inside the dashboard. There, access ApexGuru’s Code Recommendations and SOQL/DML Analysis for the corresponding Apex action. Make the suggested revisions to your code to improve Lightning Experience performance.
In the Key Insights for slowest Apex actions section, ApexGuru recommendations are available when the webpage loads. In the High Impact, Slow Performing Pages section, recommendations for Apex actions load in the background to ensure that embedding many insights at once doesn’t slow down dashboard loading time.
Key Insights
This section provides a plain-language summary of the most important performance takeaways. Rather than just presenting raw numbers, this section interprets the data for you, highlighting critical issues and applicable best practices. It serves as your starting point and immediately draws your attention to the most significant performance problems and opportunities for your org.
| Insight | Details |
|---|---|
| Number of components | The number of custom components on a page affects page load time, especially when a component is complex or inefficient. Make sure that every component on your pages has a purpose. |
| Secured Browser Caching | Secure data caching in the browser improves page reload performance by avoiding extra round trips to the server. This setting is enabled by default. |
| Lightning CDN | The Lightning content delivery network (CDN) serves static content for the Lightning Component framework. This setting is enabled by default. |
| Dynamic Boxcar'ing | Dynamic boxcar optimization improves Aura app performance by grouping Aura actions into boxcars. |
| Apex caching | Percentage of Apex actions served from the client cache, instead of requiring a round trip to the server. Make sure that your Apex classes are taking full advantage of the @AuraEnabled annotation to get caching of server-side action results. |
| Slowest Apex actions | These Apex methods are the slowest actions used by your custom components. Check ApexGuru Insights for opportunities to optimize these actions. |
Performance Trends
After Key Insights, review charts that visualize your org’s P75 EPT over the selected week and break down EPT by region and browser. This graph helps you identify trends and understand performance patterns. You can see when EPT is spiking, whether performance is degrading over time, or if recent changes have improved page load times.
The Performance Trends chart shows trends for both the initial page load (1st Page EPT) and subsequent page navigation within the app.
High Impact, Slow Performing Pages
This section lists the ten pages with the highest combination of the number of page views and the highest P75 EPT. That is, it identifies the ten slowest pages that get used the most. With this data, you can focus your optimization efforts where they have the most impact.
It also goes deeper by identifying the specific pages, components, and actions that can make Salesforce feel slow for your users. For a given page in the table, expand the row to see the individual components and their actions — such as complex Apex calls or inefficient component logic — that are the most resource-intensive. You and your development team can use this data to move directly from analysis to action, addressing the root cause of the performance bottleneck at a fine grained level.
Untimed Action Metrics
This table provides non-time-based metrics. These metrics offer insight into which component actions run the most frequently, and whether and how efficiently they’re reused.
| Metric | Details |
|---|---|
| Action Count | The number of times this action ran during the selected time period. |
| Boxcar Count | The number of actions grouped in a batch in a single network request. Lightning Experience can group multiple actions into one request for efficiency. If the batch becomes too large, higher counts mean more efficient batching, but potentially longer individual action times. See Batching of Server-side Actions in the Lightning Aura Components Developer Guide for a detailed description of the boxcar’ing process. |
| Cache Eligible | Indicates if you can serve an action from a cache. If it can, it loads faster because it doesn’t require new processing from the server. Check the cache hit ratio to see how often this process actually happens. For more details, see Client-Side Caching of Apex Method Results and Storable Actions. |
| Cache Hit Ratio | The percentage of actions that returned results from cache rather than requiring server processing. Higher ratios indicate better caching efficiency, and generally result in faster response times for repeated actions. |
Timed Action Metrics
It's easier to interpret the details provided in the High Impact, Slow Performing Pages list when you understand the phases of an action request. Let's review this process, starting from when a component fires the action, to the different phases of the round trip to Salesforce, until the action completes and applies any updates to the page.
This diagram illustrates the various phases of an action request.
The Performance Insights dashboard provides these time-based metrics.
| Metric | Details |
|---|---|
| XHR Request Stall Time | Measure of the initial network connection delay before a request is sent to the server. This value includes the time needed to look up the server’s address (DNS lookup) and establish the network connection (TCP setup). |
| Server Time | Time spent running the action on the server, including database operations and business logic. This value excludes network transfer time and client-side processing, and can help identify when delays are due to server processing. |
| Time to First Byte (TTFB) | Time from when a request is sent to the server until the server receives the first byte of the response. This value indicates how quickly the server responds to the action, and can help identify when delays are due to server processing or network issues. |
| XHR Duration | Time between when a network request is sent to the server and when the client receives the full response. This value measures pure network communication time, including the server execution time, but not client-side processing. |
| XHR Response Stall Time | Delay in processing the response due to the main thread being busy. Begins when a network response is received from the server and ends when the JavaScript callback runs. This metric helps identify when the client-side app is the bottleneck, rather than network or server performance issues. Heavy JavaScript execution or UI thread blocking often cause client-side processing issues that prevent immediate response handling. If you see high values, review the component and consider redesigning it to handle responses more independently or asynchronously. |
| Duration | Total time for this action to complete, from when the action is first requested until the client-side callback completes. This value includes all waiting time, network transfer, server processing, and client-side execution. It’s the complete end-to-end time for an action to finish. |
