5 Ways to Build Lightning Fast Components

This post is based on a talk I gave twice at this years Dreamforce.

The five tips I cover here were hand picked by me out of a whole bunch of stuff I discovered while creating my latest Pluralsight course about Lightning Best Practices. The course will be released soon, so stay tuned and I will let you know. All of these tips are pretty simple to implement and I think they represent the quickest and easiest things you can do to get better performance.

So, in David Letterman style. here they are from last to first:

# 5 – Check your Settings

Specifically, you want to check the values for debug mode and component caching, which should have different values depending on whether you are in production versus development.

Debug Mode

Debug mode is what you can toggle to allow detailed debug messages to appear in your browsers console log and these messages can really help you not only to debug your components, but as you will learn about soon, they feature important messages about performance.

For the debug mode, you want that to be enabled in development, so you can get those messages you need as you are developing, but in production, you want to make sure this is turned off b/c when it is enabled, it means that all the css and javascript that is downloaded to the client is not minified, which means it will take longer to download and longer for your components to render and that is why you do not want it enabled in production.

DebugMode

Component Caching

Component caching has to do with whether pages will be cached to specifically improve performance, which is why that one is so important.

For the component caching, the settings should be the opposite and you want caching disabled in development, because while you are making changes to components and testing how they render, you do not want to have to hit your browser refresh several times before you see your changes which is what will happen if it is enabled. But, in production, where changes to the code are not happening, you want to make sure caching is enabled, since this will result in faster component rendering.

ComponentCaching

# 4 – Use <aura:if> for Conditional Rendering

To do conditional rendering in Lightning, you could use a technique known as css toggling and for a long time this was actually the way even Salesforce recommended you do toggling in the official docs. But in fact, what we now know is that you do not want to do this and the reason why is that when you use this method, any components inside the css toggled code (and most importantly any event handlers associated with those components) are rendered right away.

The alternative is to use the aura:if tag. Using this means that anything inside the aura:if will not actually be rendered until the condition is true. So in the example below, the event handlers associated with the lightning button will not be active until the aura:if condition is true.

<aura:if isTrue="{!v.isVisible}">
             <lightning:button label="Submit"
            onclick="{!c.newRecord}" />
 </aura:if>

# 3 – Check your Console Log

The number 3 tip is a reminder to always check your browsers console log because not only can you use this for debugging your components, but the lightning development team now will push performance warning messages to the console log and so even if your component is rendering fine and doing everything you want it to, you could have a performance issue and not even be aware of it.

PerformanceWarnings.png

You can access the Console log for the Google Chrome browser by right-clicking inside the browser and selecting Inspect. But know that these messages will only appear when debug mode has been enabled, so this is something you want to only check for in your development org.

# 2 – Use the Lightning Data Service whenever possible

The Lightning Data Service is just way cool and offers a whole bunch of great features. If you do not know about it, check out this great Trailhead that tells you all about how to use it.

The best thing about the Lightning Data Service (or <force:recordData> tag) is that it provides a single cached response and this can have a big impact on performance.

Let’s say you have three components that are all using the force:recordData tag. Each one will make a request for data through the Lightning Data Service Controller, and those requests will be funneled into one single request which is sent to the Salesforce server.

But what is returned is a response that will be stored in a shared data cache and also returned back to the two components that started all this. And this means that not only will those two components be able to retrieve the data faster than two components that were using their own apex controllers.

And if a third component that needed that same data were to come along, it would be able to get a cached response almost immediately without even having to make a call to the server. Boom!

LDS2

# 1 – Use Storable Actions whenever possible

So here we are at the number one tip and it is to use storable actions whenever possible, which essentially allows you to take advantage of caching and get all the benefits that you just saw demonstrated, even when you are not using the Lightning Data Service.

And a good example of this can be seen with a component that needs to access a list of data (which is something that the Lightning Data Service currently cannot handle, since it only works with a single record).

When paging through a list of records that use storable actions, after the pages are rendered once, the next time they are returned to, the rendering will happen in a fraction of the original rendering time. This can results in significant performance savings when a user needs to page through a long list of records.

And to take advantage of caching, all you have to do is add a single line of code right after you define the action, such as in the following example:

​var action = component.get('c.getRacesDB');
​action.setStorable();
​action.setCallback(this, function(response) {
​            // Code here to handle the response
​}
​$A.enqueueAction(action);

As I said earlier, I will be sure to post when my new Pluralsight course about Lightning Best Practices becomes available so Stay Tuned….

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s