Performance of Lightning Components in Salesforce

Lightning Components run at the client-side, in a single page (where they are created and destroyed as needed), and alongside other components that work on the same data. Salesforce has done an amazing job with creating the Lightning Component framework.
List of Lightning Components performance best practices

• Data retrieval
• Data caching
• Component instantiation
• Conditional rendering
• Data binding
• Lists (aura:iteration)
• Events
• Third-party JavaScript libraries
• Base Lightning Components
• Image optimization
• Rendering and reflow
• Development settings vs production settings
• Performance profiling tools

Ways to improve performance of Lightning Components in Salesforce

1. Avoid Server Trips

Most evident plan to enhance Lightning Component Performance is to stay away from server trips. Suppose, you have to know the queue Id to be appointed as owner in case and furthermore require custom setting data to determine the conduct of Lightning Component. There are two different ways to accomplish this – Call Apex Controller two times versus return consolidated outcomes from Apex in single call and process JSON in customer side controller of Lightning Component.

2. Use Storable Action

In this approach, Lightning component shows cached result instead of making immediate server trips. Lightning component will make server (Apex) call in background and if cached result is stale, then it would cache and refresh the Lightning component. This is very useful for devices which has slow internet connections. If you are a Facebook or Google News user, you would be able to relate it easily. When we open these apps, it shows the previous feed and if there are new feeds, it gives us option to refresh view or automatically refresh it. All you have to do is, on client side controller of Lightning component, mark action as storable using this code action.setStorable().

3.  Use Lightning Data Service

Lightning Data Service needs more recognition instead of just saying we do not need to write Apex. Other important side of Data Service is its ability to use shared cache.

4. Custom Cache

If Lightning Data Service and Storable Action is not able to fulfill the requirement, then we can also build our own custom cache. Advantage of custom cache is that, you would have full control over life cycle and behavior of cache.

5.  Lazy Instantiation of Component

Instead of creating all Lightning Components at the same time, you can delay instantiation of Lightning component. You can dynamically create and destroy components as well.

6. Conditional rendering

There are two ways to conditionally render Lightning Components

1. Using CSS
2. Using aura:if

If we use CSS, then component would still be created and if there is any event associated with it, then it would be executed. So, this approach to conditionally render component or element is not recommended.
aura:if on other hand, would create element only if condition is true. So, we should use aura:if as much as possible to defer page load.

7. Debug mode off in Production

You can disable Lightning Component debug mode by navigating to Setup > Custom Code > Lightning Components.

8. Use aura:method for Component Communications

Instead of using events, we can use aura:method to facilitate communication between components. It is similar to exposing component API. There are few advantages of using aura:method instead of events, like the ability to name method which would help to clarify & identify behavior, ability to use same arguments and define multiple methods.

9. Limit event handlers

Try to limit number of event handlers in your Lightning component. As you can guess, multiple event handlers means your component would be busy in listening event changes resulting in performance overload.

10. Limit use of Application event

As we know, there are two types of events:

1. Application
2. Component events.

Application events are very powerful and gives lot of flexibility to communicate between any components in Application. However, we should use Application event with great precaution. As Application event is broadcasted to all components simultaneously, it might be excess for some components if its not needed.
Do you have any queries related to Salesforce? Reach out to our team and we’d love to talk!!