--- schema_version: "1" id: 8ab23c82b3c89d4c819ad0f1e63ca69d0a09a5dfcd1154b74298b2a019e50213 title: Performance Insights collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/lex_insights_performance.md canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.lex_insights_performance.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: 290ca1ffcd5c253f826b1d70f47bb81c05237ff810ff55e0fe6f648318f4aea3 description: 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. products: - Cross Cloud release: "264" --- # 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.

![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-scalability-264-0-0-production-enus/18f3af65-f4ea-4406-9c30-319b9afa03cd/images/icon_note.png) Note When not explicitly separated, we blend EPT across first and subsequent page views, and simply refer to it as “EPT.” This definition omits Lightning Experience bootstrap, and combines non-bootstrap EPT from both first and subsequent page navigation. Because you can’t directly optimize bootstrap, it represents the portion of EPT you can influence. It provides a simplified metric for further breakdowns across geographies, browsers, and slow pages. ## 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](#lex_insights_performance__key-insights) for slowest Apex actions section, ApexGuru recommendations are available when the webpage loads. In the [High Impact, Slow Performing Pages](#lex_insights_performance__high-impact) 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](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/perf_secure_browser_caching.htm) 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](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/perf_cdn.htm) (CDN) serves static content for the Lightning Component framework. This setting is enabled by default. | | Dynamic Boxcar'ing | [Dynamic boxcar optimization](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_actions_boxcar_dynamic.htm) 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](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_apex_auraenabled_annotation.htm) 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](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_overview.htm&release=264.0.0&type=5 "Use AI and machine learning models to analyze your Apex code, surface performance antipatterns, detect unused and duplicated code, and generate prescriptive optimization recommendations.") 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. ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-scalability-264-0-0-production-enus/18f3af65-f4ea-4406-9c30-319b9afa03cd/images/icon_note.png) Note To focus your attention on the impactful changes you can make, this section only displays custom components and actions. Components that can’t be determined from metrics are aggregated together, and are shown as “UNKNOWN.” You can still expand the “component” row, and review the individual actions for optimization opportunities. **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. ![Sequence of a component action request](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-scalability-264-0-0-production-enus/18f3af65-f4ea-4406-9c30-319b9afa03cd/scalability/images/lex_page_action_request.jpg) 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.