{"id":193201,"date":"2020-02-11T11:00:22","date_gmt":"2020-02-11T18:00:22","guid":{"rendered":"http:\/\/developer.salesforce.com\/blogs\/?p=193201"},"modified":"2025-11-05T02:20:59","modified_gmt":"2025-11-05T09:20:59","slug":"designing-lightning-pages-for-scale","status":"publish","type":"post","link":"https:\/\/developer.salesforce.com\/blogs\/2020\/02\/designing-lightning-pages-for-scale","title":{"rendered":"Designing Lightning Pages for Scale"},"content":{"rendered":"

This blog post provides guidance to architects, developers, and administrators in creating and designing Lightning pages that scale and perform well. Where we used to have Visualforce and multi-page applications, we now have Lightning Web Components (LWC) and single-page applications (SPA).<\/p>\n

With SPA, <\/b>a user can do most of the work from the same page without navigating to other pages. This is a huge productivity gain and can result in a great user experience; however, proper design is recommended to ensure large volumes of requests do not pose any scale or performance challenges.<\/p>\n

SPAs are made up of components that receive and send data to the server using XML HTTP Requests (XHR).
\nWhen a page loads, components can be rendered in parallel, making multiple XHRs to the server in order to retrieve data and metadata.<\/p>\n

In implementations with a large user base using the Lightning application concurrently, the component architecture can create a great number of network requests in the Org. Proper design is recommended to ensure large volumes of requests do not pose any scale or performance challenges.<\/p>\n

\n\t\t\t \n\t\t\t \"\"\n\t\t\t <\/span>\n\t\t\t<\/p>\n

 <\/p>\n

A Word about Scale and Performance<\/h2>\n

Scaling is the ability of a system to perform consistently under load. Lack of ability to scale can impact all processes in a system and can impact business growth. Performance <\/b>is the time taken for a request to complete. Your user <\/b>experience can be negatively impacted by UI applications that don\u2019t perform well.<\/p>\n

Factors that Impact Lightning scale<\/h3>\n

In implementations with a large user base, there are certain aspects of page design that can be optimized to scale. A few are summarized here:<\/p>\n

    \n
  1. Number of visible components on page load<\/li>\n
  2. Custom list views with lots of data<\/li>\n
  3. Related Lists, Quick Links<\/li>\n
  4. Custom Components<\/li>\n
  5. APEX & backend<\/li>\n
  6. UI Forms<\/li>\n<\/ol>\n

    Below you will find recommendations for each of these page design ideas.<\/p>\n

    Number of components on a page<\/p>\n

    Based on an analysis of various customer implementations, we\u2019ve found that Lightning pages with the right amount of components load faster, and Lightning implementation scales well overall. So how do we determine the right number of components?<\/p>\n

     <\/p>\n

    \n\t\t\t \n\t\t\t \"\"\n\t\t\t <\/span>\n\t\t\t<\/p>\n

    Solution 1: Lazy Loading Tabs<\/h3>\n

    Showing actionable components as visible components is both efficient and can result in a better user experience when implemented correctly. This is called lazy loading: wherein components are shown only on demand or progressively as the user navigates through a task. One lazy loading technique is to use tabs and nest components under tabs. Components nested in tabs do not execute any XHRs and are not part of the DOM.<\/p>\n

    Solution 2: Lazy Loading With Personas<\/h3>\n

    Another way to load components efficiently is to group components based on user persona rather than functionality. This way only higher priority components needed by a user to complete a certain tasks are visible on page load.<\/p>\n

    In the example below, we see components relevant for an insurance agent. Products are what the agent wants to access quickly. Components that are secondary to a user\u2019s needs, such as claims, details, and reports – can be in tabs.<\/p>\n

     <\/p>\n

    \n\t\t\t \n\t\t\t \"\"\n\t\t\t <\/span>\n\t\t\t<\/p>\n

     <\/p>\n

    Lazy Loading in Custom Components<\/h2>\n

    LWC provides an easy way to do lazy loading with the if:true<\/code> <\/b>directive.<\/b><\/p>\n

    In the code below, ensure the property showForm<\/code> <\/i>is false, c:formcompoment<\/code> and all its HTML elements are not part of the DOM. c:formcompoment<\/code> is a custom component stub we are using for this example. This reduces the number of DOM elements, which improves page load time, and avoids XHRs to the server, allowing for scale.<\/p>\n

    TIP: <\/b>showForm<\/i> variable in Javascript can be switched between true or false with a button click.<\/p>\n

    Lightning Web Component<\/p>\n

    <template if:true={showForm}>\r\n    <c:formcomponent> - \/\/component is not visible unless showForm == true\r\n<\/template><\/pre>\n
    Aura component<\/p>\n
    <aura:if isTrue=\"{!v.showForm}\">\r\n    <c:formcomponent> - \/\/component is not visible unless showForm == true\r\n<\/aura:if><\/pre>\n
    Long custom list views<\/h2>\n
    Custom lists with a large number of rows can be a performance and scale issue. Based on our analysis, a list of 2000 rows takes approximately 10 seconds to render. Much of the time is spent in the browser because Javascript takes time to iterate each row item and render.<\/p>\n
    The list shown here has 2000 rows. Using browser tools to measure <\/b>list rendering time we see that about 9 seconds are spent on Javascript and 1 second on browser-style recalculations.<\/p>\n
    \n\t\t\t  \n\t\t\t    \"\"\n\t\t\t  <\/span>\n\t\t\t\n\t\t\t  \n\t\t\t    \"\"\n\t\t\t  <\/span>\n\t\t\t<\/p>\n
    NOTE:<\/strong> This is a sample. Time taken is subject to list types and other factors.<\/i><\/p>\n
    Nine seconds is too long for most users, so here are a few effective solutions to reduce time to perform.<\/p>\n
    Solution 1: Custom Lists<\/h3>\n
    We can use LWC for custom Lists. Javascript processing is faster in LWC, so iterating the list items will be faster. LWC provides ListUI module to import standard listviews. For custom listviews, pagination is highly recommended.<\/p>\n
    Solution 2: Pagination<\/h3>\n
    Paginate the list data on the server and on the client. Pagination shows less data at a time, making for a better user experience. With pagination, a small number of list rows can be rendered on the client side. Based on the analysis, lists with 50 or fewer rows render quickly, resulting in a better user experience.<\/p>\n
    Below is sample code demonstrating pagination in Javascript for a custom listview in LWC.<\/p>\n
     <\/p>\n
    \n\t\t\t  \n\t\t\t    \"\"\n\t\t\t  <\/span>\n\t\t\t<\/p>\n
    Below is sample Javascript code for implementing pagination in a custom list.<\/p>\n
    <pre>\r\nimport { LightningElement, track, wire, api } from \"lwc\";\r\nmport getContacts from \"@salesforce\/apex\/ListViewPlusDataController.getContacts\";\r\nimport { getObjectInfo } from \"lightning\/uiObjectInfoApi\";\r\nimport CONTACT_OBJECT from \"@salesforce\/schema\/Contact\";\r\nexport default class Listviewplus extends LightningElement {\r\n.....\r\n@wire(getContacts)\r\n  wiredContacts({ error, data }) {    \r\n    \r\n    if (error) {\r\n      this.error = error;\r\n    } else if (data) {\r\n      this.contactsbackup = data;\r\n      this.contacts = data.slice(1, 50); \r\n    }\r\n .....\r\n @api\r\n  pressRight(left, right) {\r\n    this.contacts = this.contactsbackup.slice(left, right);\r\n  }\r\n @api\r\n  pressLeft(left, right) {\r\n    this.contacts = this.contactsbackup.slice(left, right);\r\n  }\r\n  <pre><\/pre>\n
    Pagination can be as simple as using buttons to move through the list as shown here.<\/p>\n
    \n\t\t\t  \n\t\t\t    \"\"\n\t\t\t  <\/span>\n\t\t\t
    \nSample HTML code to render the list controls.<\/p>\n
     <div class=\"reccount slds-col slds-size_1-of-12\">\r\n   <h6 class=\"slds-small-size slds-section__title\" >\r\n            {leftIndex} - {rightIndex} of {numrecords}<\/h6>\r\n <\/div>\r\n <div class=\"leftarrow slds-col slds-size_1-of-12\">\r\n    <lightning-button-icon title=\"Go To Previous Page Of This List\" \r\n        icon-name=\"utility:left\"  size=\"large\" alternative-text=\"refresh this view\" \r\n        onclick={pressLeft} disabled={leftDisabled}><\/lightning-button-icon>\r\n <\/div>\r\n \r\n <div class=\"rightarrow slds-col slds-size_1-of-12\">\r\n       <lightning-button-Icon title=\"Go To Next Page Of This List\" \r\n       icon-name=\"utility:right\"  size=\"large\" \r\n       alternative-text=\"refresh this view\" \r\n       onclick={pressRight} disabled={rightDisabled}><\/lightning-button-Icon>\r\n <\/div><\/pre>\n
    Optimizing Quick Links<\/h2>\n
    \n\t\t\t  \n\t\t\t    \"\"\n\t\t\t  <\/span>\n\t\t\t<\/p>\n
    Quick links are great, they make it easy to access related data quickly. Quick links show counts of records for related objects and show a partial list on mouse hover.<\/p>\n
    In implementations with a large number of concurrent users, it is advisable to configure quick links into a tab.  <\/b>This prevents retrieving object record counts as well as accidental hovering on the quick links and thereby avoiding XHRs <\/b>back to the server.<\/b><\/p>\n
    Let us look at how much page load time is saved by moving the Related quick links to its own tab.<\/p>\n
    Measuring the benefits<\/h3>\n
    We did a simple test to measure the impact of page design on page performance. This test was conducted on a page containing 8 components, including the Related List quick links component (more details on that below).<\/p>\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n
    A<\/th>\nQuick Links on the main page<\/th>\nQuick links in a tab<\/th>\nImprovement<\/th>\n<\/tr>\n<\/tbody>\n
    Page Load Time (seconds)<\/td>\n2.6<\/td>\n2.2<\/td>\n0.4<\/td>\n<\/tr>\n
    Number Of XHRs on page load<\/td>\n42<\/td>\n35<\/td>\n7<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    We re-configured the page by moving the Related List quick links into its own tab,<\/b> which resulted in a 0.4 second improvement. This is a direct result of a reduced number of XHR calls made during page load, as the Related List quick links component does not get rendered.<\/p>\n
    NOTE:<\/strong> This data is from basic tests relevant only for this post. Results will vary based on different factors.<\/em><\/p>\n
    Creating Custom Components that Scale<\/h2>\n
    Custom components are useful for creating customized business applications that leverage the power of the Salesforce platform.<\/p>\n
    LWC is a great framework for creating new custom components. Apart from the scale and performance benefits, development is made much easier with our provided Lightning Web Component Base Components<\/a>, such as listView<\/code>, recordForm<\/code>, and more.<\/p>\n
    These highly-optimized components help your clients retrieve data without complex backend code. For more complex business transactions, LWC can always use Apex.<\/b><\/p>\n
    Using Platform Cache<\/h2>\n
    For custom components that have to be visible on page load try using platform cache in Apex. <\/b>Platform cache provides simple API for retrieval and insertion into cache. Requests from custom components are retrieved from the cache, avoiding SOQL queries and database connection setup.<\/p>\n
    Cache retrieval is usually less than <\/b>10ms, <\/b>improving component render time and protecting database resources from being impacted when a large number of users load their pages with custom components. Let\u2019s look at some sample Platform cache code in Apex:<\/p>\n
    public static String getOffers(String agentId) {\r\n        String cacheOffer = (String)Cache.Org.get(agentId); \r\n\r\n\/\/Cast to String since we serialized the value.\r\n        if (cacheOffer != null) {\r\n             return cacheOffer;  \r\n        }\r\n        else {\r\n            return null; \/\/If null check again later\/\/                      }}<\/pre>\n
    You can find more information about Platform cache in the reference section.<\/p>\n
    Client-Side Cached Apex Requests<\/h2>\n
    For custom components, client-side caching provides a performance boost and helps scale, as it reduces the number of XHR requests back to the server for data. With LWC client-side cache can be enabled in Apex as shown below:<\/p>\n
    <pre>\r\n  @AuraEnabled(cacheable=true)\r\n    public static List<String> getMetrics() { \r\n    \/\/your code here..\r\n<\/pre><\/pre>\n
    This caches data in the client for the component and avoids having to make XHRs to fetch data as long as the data is still fresh.<\/p>\n
    Server side optimizations<\/h2>\n
    Scale and user experience depend heavily on backend code. In this case, we\u2019re talking about Apex. There are a few ways to implement server-side optimizations:<\/p>\n