Anil Jacob is a Principal Engineer here at Salesforce. He is on the Frontier Scale Team, a group that works with complicated customers who have lots of users, records, or both. They work with these customers to help them increase performance on various levels.

In this episode, Anil shares some of the tips and tricks he gives to his customers with all of us. Whether you’re a “complicated customer” or not, his insights will surely be helpful for you.

Show Highlights:

  • What a single-page application is and how it’s helpful.
  • What an acceptable page speed looks like.
  • How the number of components affects page performance.
  • The difference between list components and simpler components.
  • How to divide up your lists for faster rendering.
  • How to utilize pagination to speed up the DOM. 
  • The benefits of creating custom components for different personas or users.
  • What platform caches are and how they speed things up for large customers.
  • The difference between org and session cache.
  • Additional tips for designing Lightning Web Components.

Links:

Episode Transcript

Anil Jacob:
When you’re developing in an environment where there’s not much data, the application seems to be doing fine, but when it moves to production, we see more data developing in production and that’s where the problems start happening.

Josh Birk:
That is Anil Jacob, a principal Engineer here at Salesforce on the Frontier Scale team. I’m Josh Birk, your host for the Salesforce Developer podcast. And here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Anil about his work on the Frontier Scale team, a team that works with customers that we were just describing there in his cold quote, large complicated customers with either a lot of users, a lot of records, or both. And this team works with customers in order to increase their performance on various levels. So we’re going to bring those tips and tricks to you, starting with the description of how LWC is a single page application framework.

Anil Jacob:
So yeah, Lightning itself is a framework that’s used to create single page applications. Now, single page applications are those applications where a user can do most of the work while being on the same, on a page itself, on the same page itself. The user does not have to navigate to other pages to do the work that he’s planning to do. Right? So for example, suppose we have an account executive, he’s looking at a particular account. And the details, deleted details like opportunities or contacts, when it comes to Lightning, that information is also available on the same account page. So that means the account executive doesn’t have to navigate to the opportunity page or the contact page in that case. And that’s what a single big application is, it’s a huge productivity boost because we save a lot of time loading those other pages or navigating your way through those pages.

Josh Birk:
So then why, fundamentally, is that an improvement over say traditional Visualforce, if we’re going from controller to controller and page to page?

Anil Jacob:
Right. So applications that are made from the older technology, like Visualforce, Visualforce framework, those are called multi-page applications. So multi-page applications, as I mentioned, they are in contrast, actually, users are meant to navigate to other pages to get the information that the user is looking for. Now, technically, if you go to debug, there is another fundamental difference. What happens is the multi-page applications are, like Visualforce, the pages actually render in the server. Right?

Josh Birk:
Mm-hmm (affirmative).

Anil Jacob:
And then it’s pushed to the client, which is the browser in this case. Whereas single page applications, like Lightning, the page is actually rendered in the browser itself using JavaScript and HTML. And the page consists of small components, which actually are the ones that show the data and relevant information that the user is looking for. And these components retrieve the data on need from the backend system. So that way the network bandwidth requirement is also low, and the page appears much more responsive compared to the earlier multi-page applications, or Visualforce applications. And one more reason is that the user experience is much better because of these underlying features.

Josh Birk:
Yeah. When I was doing enterprise web development, we always had that moment where the user is reengaged with the interface, like it’s not a white page, right? They know that the interface is trying to work for them. But let’s quickly define slow. What is a time span that you’ve got in your head which, if the user is still looking at that white void, that they’re feeling like this page is taking too long to load?

Anil Jacob:
Oh, okay. So when users are using the pages on a regular basis, one point I would like to make is that even if the page is slower than, say the difference between a page compared to an earlier version of the page is like, even if there’s a hundred millisecond difference in the page load time, the users can actually make out. But to answer to your question, when I say page performance or page speed, I would say anything that is about two seconds, as long as there is some response on the page. As you mentioned, there is some sort of progressive information coming from the page, that we see that the page is, the user sees that the page is loaded, the competence are entering, and there is some indication of something happening, that two seconds is pretty acceptable. Right?

Josh Birk:
Mm-hmm (affirmative).

Anil Jacob:
Beyond that, I think users start getting impatient or start getting frustrated. Right?

Josh Birk:
Yeah.

Anil Jacob:
So that’s basically what I would define. So two to .5 seconds. But if you ask me, being a performance and a scale, I would see anything better than one second. Right?

Josh Birk:
Right.

Anil Jacob:
Our goal is that. Our goal is one second and better.

Josh Birk:
Right. Right, because on the flip side, you’re not trying to actually analyze slow. You’re trying to analyze fast.

Anil Jacob:
Yes.

Josh Birk:
And in fast, you’re really thinking in terms of milliseconds, not seconds.

Anil Jacob:
Exactly. Yeah. Yeah. Anything that is in milliseconds. Yes, that’s what our goal is. But it’s not a realistic goal every time. Right?

Josh Birk:
Yeah, yeah.

Anil Jacob:
We’re flexible.

Josh Birk:
Yeah. I’m trying to remember what our quote was back in my old job, it was something like five seconds is an eternity. You don’t think about one, two, three, four, five, but when you want to interact with something and get your job done, it’s an incredible long period of time.

Anil Jacob:
Yes, yeah. It’s that experience, at the end of the day it’s the user who’s using it day-in, day-out. Right? We have to give them the best experience, and that is the numbers I quoted.

Josh Birk:
Yeah. So let’s tick off a couple of simple things. An application built on Lightning web components is effectively a series of components doing a series of parallel requests. How does the number of components being rendered on the page affect performance?

Anil Jacob:
That is a very relevant fact, in the sense that the number of components on a page, as I mentioned, so pages are single page applications, Lightning applications are made up of components. Right?

Josh Birk:
Mm-hmm (affirmative).

Anil Jacob:
So the number of components makes a huge difference in terms of the page load time itself, because what’s happening is the framework of the page is already loaded. It’s the components that have to load, and when I say components that have to load, they have to get data from the backend and have to render themselves, JavaScript has to execute a history of my last rendering. So that time is basically what the user is looking at, and so when we have a large number of components, and I will give you the exact number to be beneficial.

Josh Birk:
Okay.

Anil Jacob:
But when you have a large number of components, what happens is all of these components have to send the request back to the backend systems, database, other systems, and get the data back. But we have to remember that the browser has only limited number of connections that it can open to backend systems, it has only six connections servers. So that means six components can render in a decent amount of time, as long as the compliments are optimized, the backend systems, everything is optimized. And so if it’s optimized, then what happens is the other components on the page will also appear as if they’re loading fast, because the previous components are already loaded and the conditions are now available for this other componential load. Right? So the component performance makes a difference. And the number of components makes a difference because if there are too many components, then components have to wait, based on the theory that I just mentioned. And also the speed of those components makes a difference because then these components that are not loaded will keep spinning, and that can lead to user frustration.

Josh Birk:
Yeah. So first of all, it’s fascinating to me that I’ve been doing web development for, let’s just go with a really long time so that I don’t age myself on my own podcast, and that’s actually the first time I’ve heard that number six. How is that baked into the browser? Is that a standard that the browser’s accepted on? That like, Hey, this is a reasonable amount of transactions that we’re going to do with the server at one time.

Anil Jacob:
Yeah. So basically it’s six to a given domain.

Josh Birk:
Okay.

Anil Jacob:
So for example, let’s take different use case-

Josh Birk:
Oh.

Anil Jacob:
Yeah. So if, suppose you have a bunch of images that are coming from, say some other domain, like maybe netflix.com, and then you have another competent data that’s coming from Salesforce. So then those six can load at the same time from the other domain, because it opens six connections to each domain. Right? Whereas since we are getting data from the database, which is within the Salesforce domain, we have six connections available for them. Right? So that is the limit over there.

Josh Birk:
Okay, okay.

Anil Jacob:
Because the browser has to do a lot of its own work, in terms of layouts and organizing the page, et cetera, so that’s optimizing itself.

Josh Birk:
Got it. So if it’s pulling stuff from a CDN, that’s not getting in the way of another Lightning web component. If I’ve got one really heavy, complex component, but I limit my other components down to say four to seven, then that page is going to be really, relatively performing. And we’ll talk about component structure and stuff like that here in a second.

Anil Jacob:
Sure.

Josh Birk:
But if I’m mindful of those groups of six and how much they can do at one time, I can think about what my page needs to have on the screen at any given time and try to get that cue executed correctly. Does that sound about right?

Anil Jacob:
That sounds right, yes. Absolutely. Yeah.

Josh Birk:
Nice. And so let’s do talk about that a little bit. How do components, like lists and tables, compare to simpler ones like maybe just a simple form or a button component?

Anil Jacob:
When it comes to lists, so what happens is when we have longer lists of data, like for example, a list of opportunities on an account page, or a list of contacts, right? So what happens is the data where it comes back from the… There are two levels to this. One is the data has to be repealed from the backend system, that can be to a sorted query, or if it’s a custom list. And then once the data comes to the data group layer, or the UI layer, it has to be rendered onto the browser. Right?

Josh Birk:
Mm-hmm (affirmative).

Anil Jacob:
So the browser has to iterate through each of the list items, and it has to create the layout and then throw it on the browser. So for this reason, lists can have a bigger impact because of this iteration. We see that list have this longer list because of this iteration, it takes much more time, and you see that lists spend more time in the browser then in the backend.

Anil Jacob:
So we can pull that list of 2000 elements very quickly from the backend through effects or through, and to a circle query. Whereas when that data is sent to the browser, that’s where the delay is, and we see that it’s a good amount of delay. So our recommendation in this particular case, when it comes to list, is always keep the list small. That means show a small list. This has got two benefits. One is the user sees a smaller set of data, it’s much more easy to interact with that data. And also the rendering is much faster because the list is small.

Anil Jacob:
And then when the user wants to see more data, we can always do a page addition, either through a button or through a scrawl based page additions, which is what the Salesforce components do. Compare this with other elements, like a form, et cetera. So those don’t have this kind of issues, but forms can have their own. I have seen a form where in there were about 50 to 60 fields in the form. Right? Those can have their own impact, but what happens is those elements don’t have this kind of iterations. So they can be, if the number of fields are limited, et cetera, they can be rendered pretty fast.

Josh Birk:
Sure.

Anil Jacob:
But I would take it one step further. One thing is that if it’s strictly a form or a list, or anything like that, or buttons, et cetera. It’s always good to keep the number of elements on the page within a certain limit, because all these reside in the DOM of the page. Right? So then the page, if the DOM has too many elements, it will take longer time to render the page.

Josh Birk:
Mm-hmm (affirmative). I just, I keep going back to a conversation with [Chris Gray 00:13:35] and conversations with some of the… Just the Holy Grail of web development, at some time, became the fastest data table that you could produce, because it’s complicated, it’s tied to a lot of data, and everybody wants to use one.

Anil Jacob:
Yes.

Josh Birk:
They’re so organizationally friendly that… I’m trying to remember how [Greg Rouse 00:13:56] put it, but it was like, it’s the thing that you’re always trying to get as most efficient as possible. And it’s the thing that’s going to be pushing you to have as much going on as possible.

Anil Jacob:
Yeah. So that is the reason lists are everywhere. Right?

Josh Birk:
Mm-hmm (affirmative). Mm-hmm (affirmative). Right, right.

Anil Jacob:
Almost every page has a list, some more than others.

Josh Birk:
Right, exactly. So let’s touch on one of the things that you talked about there a little bit though, there’s pagination, and then you can also use tabs. And how can structures like that help reduce what’s going on with the DOM?

Anil Jacob:
Okay. So let’s go back to the page itself, so as we mentioned, we have the components on the page. And we touched upon the fact that the number of components makes a difference. Right? As the lower the number of competence, the page would load fast. Now we cannot tell our developers, or our users, or our customers to limit the number of components, which would affect functionality. Right?

Josh Birk:
Mm-hmm (affirmative). Mm-hmm (affirmative).

Anil Jacob:
So what we would recommend in that case is have the components that you need on the page, but put them based on what the user requires, as soon as the page loads. Right? And then the rest of the components, have them moved into tabs, because Salesforce, the page itself provides options to create tabs. And then the components that are not immediately required for the user to start doing his work, his or her work, can be moved into tabs.

Anil Jacob:
Now what happens with that is, when the page loads, the components that are visible, or the active tab, and anything that may be outside the tab, would load first. Right? But the components that are within tabs do not load at all. So that means they don’t take up space in the DOM, and the number of DOM elements remain low because only few components are active and visible when the page loads, so that way the page loading is really fast.

Anil Jacob:
Now I can give you an example in this case, like for example, going back to the account executive. If he’s looking at, say an account page, and he immediately wants to look at, he or she, immediately wants to look at only opportunities that are related, there’s no point showing contacts. Right? A list of contacts, the list of contacts can be put into a tab. And is only visited when the accountant executive actually wants to look at contacts. But, right away, as soon as the page loads, the opportunity list loads, and the opportunity list is available, but since it’s only one component on the page, the page loads really fast.

Josh Birk:
Got you. And talking about that account executive, another thing that you bring up in your blog posts, which we’ll link to in the show notes, of course, is thinking about it from the component level and asking yourself, does that persona need to have access to that UI element? So how careful should developers be about, not just a whole component like a list or something like that, but within their custom component, do I need to show this button? Do I need to show this field? Does the user actually need this? Or can I be a little bit more careful about conditionality it, either based on a situation or a person?

Anil Jacob:
Exactly. That is, yes. So the fact is that, as I mentioned, if the page has to be planned based on personas, the reason is, typically what would happen is we would plan the page based on functionality. So what happens in that case is, Hey, this is a sales functionality, what are the components that I need? Opportunities, contacts, maybe products, et cetera. All these are put onto the page, all these are visible at the same time. The page can take long time because a lot of components load. Right?

Josh Birk:
Mm-hmm (affirmative).

Anil Jacob:
But instead of that, Salesforce, the Lightning platform gives a really good feature where we can customize the page based on individual personas or profiles. Right? So what we do in that case is create pages that are relevant to a certain persona. Again, going back to the account executive or sales persona, we can show, okay, what does that user that belong to that persona, really want to see? Maybe only opportunities, he’s only going to work on that. And maybe at the same time, if there’s another persona, like maybe a business development executive, they want to see leads. So each day each page can be tailored in such a way that the data that’s shown in the components, the components that are relevant, can be tailored for the persona itself and then assigned to the profile based on what they’re planning to do with that page. Right?

Josh Birk:
Got you.

Anil Jacob:
So that page components are reduced and the page is much efficient.

Josh Birk:
Got it, got it. Okay, cool. Well, moving into the world of Apex, what exactly is platform cache? And how can it be used to speed things up?

Anil Jacob:
Oh, that’s my favorite topic actually, because-

Josh Birk:
I like it.

Anil Jacob:
So platform cache is cache layer, is in-memory cache that is accessible from the Apex, from the platform. Right? So Apex has access to it. Now, the way we recommend users to, our developers to use it, is that they can move the data, which is based on common queries that happen all the time. So common SQL queries as part of their custom component, teacher result from those queries can be saved into platform cache. Now it can be a list of opportunities, a list of contacts, et cetera, and they can be kept there in the platform cache. Apex has access to it right away, and then when the component renders, it reaches out to Apex and Apex retrieves the data from the cache. So the difference is, the request from the component or from the user’s browser, doesn’t have to go all the way back to the database. Right?

Josh Birk:
Mm-hmm (affirmative). Mm-hmm (affirmative).

Anil Jacob:
So then the cache saves it, and so it saves a lot of network hoops that have to be covered. And then because it’s in memory, there’s no coding, et cetera, happening, the data is already there in memory. We always see that the retrieval from cache is always less than 10 milliseconds, or it can be much more faster than that. So this way, if you can imagine, the component and the page will load really fast because the data is almost instantaneously coming back from the cache.

Josh Birk:
Right, right.

Anil Jacob:
So that is where platform cache is really useful.

Josh Birk:
Talking numbers here, you have seen people have… So faster data layers, so faster Lightning web component. And you’ve seen people take the strategy of converting things over to platform cache and have huge wins from a performance gain, right?

Anil Jacob:
Correct. Yes. That is very true because we’ve seen some of our large customers use platform cache because they have requirements for, because as so many users are using it, having that data in cache and… Also one more thing, database is much more precious resource, right? It’s more limited in terms of resources, and so saving that resource and having data served from cache makes it much faster. And we also recommend, it’s also a way of thinking that cache provides extra memory for the data that cannot fit in Apex, right? So it’s external memory, so we can go up to two gigs of memory. Right?

Josh Birk:
Mm-hmm (affirmative).

Anil Jacob:
And that amount of data, the data that resides there can be retrieved fast, so it’s a win-win situation. We’ve seen all of our customers being really happy with platform cache, and every one of them want to use it for more and more use cases. Yes. So that is what we’re seeing.

Josh Birk:
Nice.

Anil Jacob:
Yeah. It’s a product that’s good.

Josh Birk:
Yeah. And I think it’s interesting because, going back to a lot of the things that the Frontier scale sees when it comes to database performance, and not understanding indexes, or knowing where some of the curves and the gray areas of database design in general in the platform, but this kind of bypasses that, right? The goal is to not even get to, you’re not walking into those problems because you’re not going to the database in the first place, you’re just pulling things directly from the cache.

Anil Jacob:
Totally. Yes. I’ll give an example. I mean, we have a customer who was actually going, had a use case where the front-end page was constantly pulling the backend, in terms of making these queries. And he pulled that data from the backend, and then whenever the data is available, it would send the data back to the UI. Right?

Josh Birk:
Right.

Anil Jacob:
So this pulling was actually causing them to run out of capacity, because it was constantly hitting the database-

Josh Birk:
Boom, boom, boom. Yeah.

Anil Jacob:
Yeah, exactly. And every request, even if the request is fast, it still takes a lot of resources. So when we put platform cache in between that and the database, and the request was served only from the cache, they could use the database for everything else. Right? It was totally free and they were able to use more features, more users, without having to worry about any capacity issues.

Josh Birk:
Nice. Quickly, what’s the difference between org and session cache, and how do we use them?

Anil Jacob:
Org cache is, both are part of platform cache, right? So you can partition, or you can divide the cache into partitions, and each partition can be allocated as an org cache or a session cache, or both, depending upon what space is given to both of them. Right?

Josh Birk:
Got it.

Anil Jacob:
So the main difference between org cache and session cache, the data in org cache is visible to any user or any process within that org.

Josh Birk:
Got it.

Anil Jacob:
So that means if there is another Apex application, or maybe a trigger, can access the org cache data based on if the key is known to that particular application, where a session cache is very private, only to the user’s session. So that means if there is a cache configured for a partition when the user session starts, that session gets an attached space for session cache.

Anil Jacob:
And that session cache is only visible to the users’ session. And during that, so for example, let’s think about a shopping cart. So a shopping cart is where, okay, it’s private to the user. The user would keep putting whatever items he or she would purchase, into the cart. So this cart can go into the session cache, because then it’s private to the user. And when the user finishes processing, that cache can be removed. Or when the user logs off, the session cache is detached and removed, whereas org cache can remain for a longer time and visible to all the users in the org.

Josh Birk:
Got it. All right. Anil, am I forgetting anything? Is there one other tip that you want to make sure people know when they’re designing their Lightning web components?

Anil Jacob:
Yeah, there are actually, yes. There are a few more items I would think about.

Josh Birk:
Okay.

Anil Jacob:
Web components. One thing I can think about is, we have this great feature called Quick Links, which can be configured on Lightning pages. It’s a competent, right? So Quick Link components. And it’s a great productivity feature because it gives us a list of all the related items for a particular record.

Josh Birk:
Okay.

Anil Jacob:
And when the record page is rendered, it shows up, okay, what are the deleted lists? Like list of opportunities, or list of contacts, list of leads and stuff, campaigns, et cetera, for a given account. So what the Quick Links, though they are really good as far as productivity is concerned because the users can right away know what’s related to that particular record. We would recommend it to be used a little more carefully, especially when the org has a large number of users, when the scale or the usage is high, because these Quick Links have a feature where they show the number of records for each of these Quick Links. So that number is actually a count that happens against the database for each of these deleted records. So we would say the best option for that is, if the usage is high, move these Quick Links into a tab.

Josh Birk:
Okay.

Anil Jacob:
Use them, definitely, but move them into a tab, so they’re not part of the page load.

Josh Birk:
Got it.

Anil Jacob:
So we have seen that if that is optimized that way, the page loads slightly faster.

Josh Birk:
Got it.

Anil Jacob:
And it’s actually beneficial for the end-user. One more thing is, there are a lot of things that we can do in Apex. If the page uses custom components, in Apex what happens is that when we have these components rendering back data from Apex, if the component is going to get a lot of small items or small records, a small amount of data from Apex in the backend, then it’s going to make too many requests. Right?

Josh Birk:
Mm-hmm (affirmative). Mm-hmm (affirmative).

Anil Jacob:
And so that eats up bandwidth, network bandwidth. Right?

Josh Birk:
Mm-hmm (affirmative).

Anil Jacob:
So imagine where the users are sitting in remote areas, or in COVID situation where we have users working from home, the network bandwidth can be pretty variable.

Josh Birk:
Yeah.

Anil Jacob:
In that case, it’s always best to get a decent amount of data from the backend for one request, from the competent to the Apex. And then basically reduce the number of requests that go back and forth between Apex and the browser.

Josh Birk:
And that’s our show. Now there’s more information from Anil on our blog, we will point to those articles in the show notes. Now, before we go, I did ask after Anil’s favorite non-technical hobby, and be sure you stick around for this one, because, well, I added in a little bit of twist towards the end.

Anil Jacob:
I’m into painting and-

Josh Birk:
Oh nice.

Anil Jacob:
Sketching a lot. Right?

Josh Birk:
Okay.

Anil Jacob:
So I do that all the time on the weekends. I go for classes, I go for open model sessions, and I enjoy it a lot.

Josh Birk:
Very nice. Okay. I’m going to ask one follow-up to that, only because I was stalking you on LinkedIn and I saw this, so I just have to ask, do you still play table tennis?

Anil Jacob:
Not in the last one year, three months. Right?

Josh Birk:
Right.

Anil Jacob:
Yeah.

Josh Birk:
It’s a little harder to [crosstalk 00:29:36].

Anil Jacob:
[crosstalk 00:29:36].

Josh Birk:
Not a socially distant friendly sport, understood.

Anil Jacob:
Yes. Yes. So apart from that, I claim as being a very good table tennis player for, within all of Salesforce, but my colleagues and my friends don’t agree with that. So that’s not even, they’re always going on, but I do play, yes. It’s my favorite activity.

Josh Birk:
All right. Well, I hope in post-pandemic times we can have a Salesforce table tennis championship and see-

Anil Jacob:
Yeah.

Josh Birk:
See who’s right on that, I would love to see that.

Anil Jacob:
I’m looking forward to that.

Josh Birk:
I want to thank Anil for the great conversation and information. And as always, I want to thank you for listening. If you want to learn more about me, you can catch me on Twitter @Josh Birk. I’m also on Twitch as Josh Birk. We do have a weekly Fortnite charity match that we do stream over there on Twitch. Now, if you want to learn more about the show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again, everyone. I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.