Salesforce Admins Podcast

This week on the Salesforce Admins Podcast, we sit down with Chris Marzilli, Director of Platform Success at Salesforce. We learn tons of tips and tricks Chris has for improving your org’s performance and how the Awesome Admins out there can make a difference.

Join us as we talk about how impactful smart tab usage can be, the tools that are built into Salesforce to help you check the performance of your org, and you should always take a look at standard components first.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Chris Marzilli.

The best of the best and the worst of the worst.

Chris describes himself as “an Admin who Architects” at Salesforce, where he and his team work with some of Salesforce’s largest customers implementing and evaluating hundreds of orgs. “I’ve seen the best of the best, and the worst of the worst,” he says, “so I have no shortage of war stories.” That means he has plenty of insights to help you improve your org.

“I’ve spent the last past of this year focused on just improving and optimizing Lightning performance with some of our customers,” Chris says. He thinks of Lightning performance as a three-sided triangle: browser performance, network performance, and page complexity. The third one is where admins need to focus. As Chris puts it, “how can we make the user more efficient and how can we get the page load faster?”

Rethinking tabs from the ground up.

“In Classic, as an admin, you had very limited choices,” Chris says, but in Lightning there are so many more options than just placing the field on the left or the right of the page. Hiding things behind tabs, for example, can allow them to lazy load and substantially increase performance. Admins now have to play the role of UI designer, and there’s a lot they can do in Lightning that can have a huge impact on their users’ workflow.

One of the biggest things is to start from scratch in Lightning. “Most of the customers I’ve run into that have some of the worst-performing orgs have basically just lifted and shifted from Classic,” Chris says, “and they’ve brought over a lot of their technical debt without rethinking it.” Instead, Chris recommends starting by asking yourself what you really need to give the user in order to do their job. “Don’t give them too much,” he says, “if you have 300 fields, no user, no human, no person can comprehend that when looking at a page.” The same goes for related lists—Chris strives for one or two on a page, with the rest hidden behind tabs.

“User needs are demanding,” Chris says, but it’s important to realize that all clicks are not the same. “The question is not so much what they want to see, it’s what they want to have at their fingertips,” he says, and he has a ton of great tips for how to make better use of your tabs to group things logically while making it all more manageable for all of your different use cases.

Salesforce tools to help you gauge your org’s performance.

The world of components is wide and varied—there are so many that even Chris has trouble keeping up. Before you get into custom components, Chris recommends making sure you’ve taken a thorough look at the standard components, and even considered if what you’re trying to do would be better accomplished with a Flow. “I always try to use my declarative tools first before I go into writing a custom component,” he says. It’ll perform faster and save you a lot of time.

Another great tool is the Lightning Performance App, which started out as an adoption measuring stick but now includes several great metrics for judging how your org is functioning. Some of that data is actually stored in your org as a record, Lightning Usage by Browser Metrics, which gives you the ability to take a closer look by building custom report types and reports on that object.

“The reason I wanted to come on the Salesforce Admin Podcast is to make a callout to all of our Awesome Admins out there,” Chris says, “you can have a huge effect on Lightning performance if you just take a look at the page, inventory it, and then understand what’s the best way to present it to the user.”



Love our podcasts?

Subscribe today or review us on iTunes!


Full Show Transcript

Mike Gerholdt: Welcome to the Salesforce Admin Podcast, where we talk about product, community and careers to help you become an awesome admin. I'm Mike Gerholdt.

Gillian Bruce: And I'm Gillian Bruce.

Mike Gerholdt: And joining us today is Christopher Marzilli, who, holy cow, is about to just blow your mind with all of the cool things that admins can do, that he helped coach admins, that he works with our companies while at Salesforce to increase Lightning performance on pages. We talk components. And I'll sneak peek. I think, my new word for this episode is lazy load.

Gillian Bruce: That's pretty good, Mike.

Mike Gerholdt: It's lazy load's fun.

Gillian Bruce: It's like lazy river. It's what we all want to be on right now.

Mike Gerholdt: It's lazy load. So listen for lazy load and other fun things as we get Chris on the podcast.
So Chris, welcome to the podcast.

Christopher Mar...: Thanks, Mike. I'm really excited to be here first time. Long time listener of the podcast. I really enjoyed one of the recent podcasts with Vin Dynamic and talking about the Dynamic page builder.

Mike Gerholdt: Yeah. Vin has quite the game collection.

Christopher Mar...: Yeah.

Gillian Bruce: And Chris, we'll work on your superhero name through this podcast, too. So my brain is already thinking.

Christopher Mar...: Awesome.

Mike Gerholdt: Yeah. It just comes as the podcast progresses. Chris, you've been at Salesforce for a while. We've had the pleasure of working together on admin track. For those of you that don't know you, what do you do at Salesforce? And what are some of the things that you're really passionate about?

Christopher Mar...: Yeah. So I got my start using Salesforce about 15 years ago. For the last five years, I've been here at Salesforce. But when I started 15 years ago, I was an accidental admin and that's where my roots will always be. I'm sure you've heard the phrase admins who code. Well, I'm actually an admin who architects now here at Salesforce. I run a group of certified application architects that work with our largest customers here at Salesforce. And I've implemented and evaluated hundreds of orgs, and I've seen the best of the best and certainly the worst of the worst. So I have no shortage of worst worries.

Gillian Bruce: I love that, admin to architect at Salesforce. That's quite a 15-year trajectory there, Chris. So congrats.

Christopher Mar...: Yeah. Thank you.

Gillian Bruce: So you said you've seen the best of the best and the worst of the worst, which means you've learned a lot along the way. One of the things I think we wanted to talk to you today was about some of those things that you've learned that admins can use to help them improve kind of the performance of their org, which I think you've got a long list.

Christopher Mar...: Yeah. I mean, there's a lot of stuff out there. I actually spent the last part of this year, it being July now, focused on just improving and optimizing Lightning performance with some of our customers. I've kind of come up with some... a methodology of the way I think about Lightning performance. It's actually a three-sided triangle. And those three sides are browser performance, network performance and page complexity. And really the complexity of a page is where we, as admins, need to focus and think about how can we make the user more efficient and how can we get the page to load... The page load faster is a nice kind of KPI to look at, but really you want to make the user more efficient and those two things need to come together to provide the most optimal Lightning experience.

Mike Gerholdt: Yeah, I think, I mean, for as much as we like to put bumpers on stuff, there's no stopping people from adding too much cheese to a taco. Right? And there's also no stop... Well, I'm sure there's a limit and you can tell me how many Lightning components I can have on a page, but at a certain point, your X number of Lightning component, isn't adding value, just like your X number of pound of cheese on a taco isn't adding really any more deliciousness.

Christopher Mar...: Now, I really like cheese on my tacos, but yeah, there's definitely an upper limit there. And while I'll say that we actually... There's what you can do technically, but then what's the best practice? And I like to focus on more on the best practices. And we've recently released something new in app builder. I don't know if you've seen it. As admins, we're an app builder all the time. We'll see guidance now in the lower right hand corner. And when they trip one of our rules, like if they have more than, I think it's 20 or 25 Lightning components on a page, it'll pop up and say, "Hey, this might be too many. Let's think about how to rearrange that." And we're going to be adding more and more features there, but with Lightning App Builder and that guidance, there's so much you can do.
I always say that in classic, as an admin, you had very limited choices. Right? Do I put the field on the left hand side of the page, or do I put it on the right hand side of the page? That was basically it. Now with Lightning, you have all these different templates and you have tabs where you can hide stuff behind. And when you do that, those things can lazy load. And you have different regions of the screen that you need to think about.
So it's not just do I put it on the left or do I put it on the right? The question is, where do I put it? Where is it most valuable to the end user? And if I can put it behind a tab and increase performance, all the better.

Gillian Bruce: So I think that's awesome. I mean, it's really interesting because we get so excited about all the flexibility we get now with, I mean, talking to Vin Dynamic, and the amazing things that his team has created, we have so many options as admins of you can put things here. You can set conditional visibility here. You can now kind of even to like a field level. I mean, there are so many things that as admins, we never had to think about that before. Like you said, it's either left or right. And now admins are kind of UI designers in a way.
So what are some things. Chris, that... You mentioned kind of putting things behind a tab, if you can. What are some kind of like overall strategy as an admin, like general best practice? Give me some top tips there when I'm creating a page.

Christopher Mar...: Yeah. So the key things to look at when creating your page, first of all, start from scratch. Most of the customers that I've run into that had some of the worst performing orgs have basically just lifted and shifted from Lightning... I'm sorry... from Classic to Lightning, right? And they've kind of brought over a lot of their technical debt without really rethinking it.
I always think that if you're going to implement Lightning or you're starting out with Lightning, you should start from a blank slate and say, "What do I need to give the user to do their job?" And don't give them too much. If you have 300 fields, no user, no person, no human can comprehend 300 fields when looking at a page. It's too many.

Mike Gerholdt: Right.

Christopher Mar...: I say 20 is what you should shoot for, maybe 30, right, on a field. And then hide everything else behind a tab. I understand that those other 150 fields are important, but not every time I go to the page. With dynamic forums, I can't wait. You'll be able to drag and drop fields on, but even now, you can use a related object and just put a couple fields on the page and then put the rest behind the tabs.
And then the other one best practice I have is related lists. 35 related lists, not great on a page, right? One or two typically is what I strive for on the top part of the page where the user loads up every time they see it. And then again, put the rest behind a few tabs and hide it, especially if they don't need it.

Mike Gerholdt: Yeah. So let me play devil's advocate, Chris.

Christopher Mar...: Sure.

Mike Gerholdt: Because if I'm an admin, I'm hearing this and I'm like, "Oh, I totally need to do that." And then the second you sit down with a user, they will give you the story of, "Well, when I load this record, sometimes I need to see this. And then other times on Tuesday afternoons, at 3:00, I need to see this. And then other times, I'm feeling like I'm on the phone with them and I need to... So I got to have access to all 35 related lists."

Christopher Mar...: Right. And the user needs are demanding. Right? I always say that you got to get to the core of what they need. And again, they'll need all 35 related list at some point in their career, right, at some point in their week or some point in their month or if they go to it once a year to look at this specific metric. That is important too, right? You need to be able to support that use case.
You can put all of the related lists into a secondary tab, and so that they can get access to it. I feel like we come off, in the classic world, and when we started doing web technology, you used to count the number of clicks, right? And then we gotten a little bit more into page load. And now we, at Salesforce, we talk about experience page time. That's how much time it takes for the page to be usable for a user.
All clicks are not the same. If I'm clicking on a tab, that's going to be pretty responsive. But if I have to click away to a different record, and I have to open up like, say, a new tab, that's going to take more time. So the question is not so much what they want to see, it's what do they want to have at their fingertips? And thinking about the different use cases that they might have to go through and how often they might have to access that data.

Mike Gerholdt: So in thinking of a page, how... because I know Gillian has a million questions, how should I approach tabs? Let's start there first.

Christopher Mar...: My thought around that is that you can basically drag and drop tabs anywhere you're not want now in the app builder. It's really powerful. You don't want to go crazy though, right? You don't want to have everything be tabbed. So I like to have one set of tabs. The default tab is the, again, those key things, maybe those 20 fields, those two related list is in the default tab. And then everything else, I have behind that.
And I've seen actually a lot of different implementations. Some people have thought of some different ways to break out the tabs. I saw one company that had tabs basically by core role. So they might have a number of different sales roles, right, that all access the opportunity. Right? And they all want the same information, but some of them, they want these three related lists and the other ones want a different two related list or fields or whatever. They actually have five tabs on the opportunity page that actually is done by role. And I was like, "Wow, I never thought about that." You could also do it just by, "Hey, here are all your fields. Here are all your related lists. Here's all this stuff that deal with assets. And here's all this stuff that deals with revenue." So if you think about logical ways to group some of the fields and related lists, that's another method, too.
There's definitely no one, "This is the right way to manage your tabs." I think it's about working with those demanding end users and figuring out what's going to be best for the different use cases you need to support.

Gillian Bruce: I like this. This is like tab palooza. There's so many. Wasn't Tab like a soft drink at some point, too? Or is that still a thing?

Mike Gerholdt: It was.

Christopher Mar...: Yes.

Mike Gerholdt: Still exists. Still exists.

Gillian Bruce: Okay. I am like, I'm envisioning it. I don't think I've ever actually had it. So I can't tell you what it tastes like.

Mike Gerholdt: I feel like it was in the '80s thing.

Gillian Bruce: Yeah.

Mike Gerholdt: Because don't they talk about that in a big movie that came out in 1985 about time travel?

Gillian Bruce: Sure. Yeah.

Mike Gerholdt: Put it on my tab.

Gillian Bruce: I was a little young, I think.

Mike Gerholdt: Yeah. I know. I'm old or something, fine. Give me a Pepsi without sugar.

Gillian Bruce: All right. So I love this tab strategy. And now everyone's thinking of drinking a Tab soft drink. But one of the other things, when you say tabs, it makes me think of console. So can you talk to us a little bit about console versus tabs in the kind of standard out of the box experience? I mean, I love console. I think it's amazing. And that is like the ultimate Tabba Palooza. Right?

Christopher Mar...: Yeah. So there's definitely a big difference between the tabs that you have in app builder and the tabs that exist in the console Lightning application. Even though they probably look relatively the same, they function a little bit different. What's important to know about the console tabs is that unlike the app builder tabs, they don't do what we call lazy load with the app builder and you put a tab on, it loads the default tab when the end user hits the page. And then when they click into the next tab, that's when it actually does the loading there. So you get a speed advantage, a performance advantage there.
With service console, each time it's opening up a tab... Or I'm sorry, the Lightning console, each time it's opening up a tab, you are actually loading that record. And furthermore, if you use navigation rules, which I know a lot of our admins do where you can open up multiple tabs, so if I click on a case, I open both the case and the account, you're actually opening both records.
That could be a big performance hit if you have a thousand users all clicking on tens of thousands of cases every day, you're now loading both the case and account every time someone clicks on a case. There's some performance trade offs there. It could be very useful obviously for a service representative to be able to look at both the account and the case and flip back and forth. But do they need it every time? If the answer is yes, then go ahead and use the navigation rules. The answer is no, well you can actually speed up the performance by reducing those navigation rules.

Gillian Bruce: I see. That's, again, a tip I had no idea about. So this is good.

Mike Gerholdt: Yeah. I love your point that you make in your presentation about console users are generally power users. I feel like it even took me a while before I was what I would consider myself a power user to have a console and be able to navigate around. Right?

Christopher Mar...: Yeah. I mean the console users are not people who are working on one thing at a time, right? They are working on multiple cases, multiple opportunities, multiple leads, and they are flipping back and forth and they are definitely the quintessential power users, and they need a little bit more thought put around their performance because every second you can reduce the page load time is more time that they're going to be able to juggle multiple things.

Mike Gerholdt: Yeah. So let's jump into... Because I feel we did justice to some tabs. I bet there was a Diet Tab, too, Tab Free. What about Lightning components? It's interesting, coming from the world of Classic, you kind of had the record detail, and then all of your related lists and you had this one page and as you mentioned, there's really, do you put it in left? Do you put it in the right? And then once it's in the left or the right, "Ooh, do you put a blank space in between it?"

Christopher Mar...: Yeah. Right. Yeah. Oh, fancy.

Mike Gerholdt: Those fields. I remember when the blank space came out. It was like, "Oh my God, this is a game changer." Now we have on top of the page apps, we have components that we can put in pains. And for the most part, we have standard components we can drag and drop in, and we also have custom components. So if we have developers that are building components, how should we go about thinking about components?

Christopher Mar...: Yeah, it's a great question because that's one of the powers that we have in Lightning that it's so much more powerful than classic, it's those standard and custom components. In the standard components, we keep adding more and more every release. It's even hard for me here at Salesforce to keep up with all of these components that we have, the highlights panel. I really like the accordion, just because it's fun to say accordion.

Mike Gerholdt: Right.

Christopher Mar...: And there are so many great different components. And then there's third party components. There's a huge number of app exchange, third party Lightning components out there that you can go and get free and paid. So there's just no end to it. And then there's of course the custom built components that you work with your developers to build.
Anytime I talk about the custom components, I always say, "Make sure that you're looking at the standard components. Make sure you're thinking about using flow before you even get into the custom components." But there's always going to be those things that you're going to want to build those custom components for and engage those developers to do it, but you want to have those requirements upfront. Like this is what we did. I was always try to use my declarative tools first, right, before I go into the, "I need to start custom writing a component."

Gillian Bruce: Yeah. I mean, Chris, to your point, I remember early days of when we were kind of spreading the Lightning news and going and doing like Lightning tours in cities. I remember, there was a moment where actually one of our like broader team members was super stoked about a Lightning component he'd built. And then we were like, "That's actually a standard component."

Mike Gerholdt: Right. Yeah.

Christopher Mar...: Yeah.

Gillian Bruce: You did all this work, and actually it already exists.

Christopher Mar...: Yeah. I've definitely run into that certainly with customers and then I show them not only does it exist, but it actually performs faster. Right? One of the things I wanted to get too techie here on the admin call, but when developers are building components, they actually have the option to use something called base components, which are basically the underpinnings of our core components. Right? So that it's very similar to the ones that you see in app builder, but then they can extend them. Developers can extend them.
And the reason why that's so important is that as we make improvements to the core Lightning experience engine, those base components that are standard components improve the performance. So it's kind of like by using Lightning components, you're investing anyway in Salesforce, right? By using those base components, now we can invest in you and actually help you speed up. And we do that release to release, basically.

Gillian Bruce: I think that's really cool too, because I mean, we've briefly touched on kind of the more complexities that come with Lightning components and building them once in a while on this podcast. And I think the idea of base components is something that admins can very easily understand, right, because it's very similar to the admin experience in that, "Hey, here is a..." I mean, it's almost like a template that you can use.

Christopher Mar...: Right.

Gillian Bruce: And reminding developers that they exist, I think, is a really good thing for admins to do.

Christopher Mar...: Absolutely. And Gillian, not only can they... They can actually see them, right? So you can go and I would encourage even admins to go to the Lightning component developer docs. And in the documentation, there's a tab for base components and you can go and look at them and see them, and then you can get the code and you can even send that link to one of your developer and say like, "This is the component that I think we want to..." This basically, it's a UI. Ultimately it's a base UI. You go, "This is what I want. This is the component that you should put it in. And here's the data that we need to pull in or the functionality that we need." So the admins can actually go and see them, see all of our base components.

Gillian Bruce: So awesome. I love that. I love that. So Chris, what are some kind of other things that you've got tip wise for admins who are building pages in Lightning who want to optimize performance? We talked about tabs. We briefly touched on console, talking about components. What are some other top things that come up to mind for you that you've seen?

Christopher Mar...: Well, one of the things that I work the most with is doing investigations with customers. How do we troubleshoot Lightning performance? Because you're obviously not starting from a blank screen. Almost nobody's in that position, unless you've just spun up a new org today. Right? So how do we go about if our users are saying it's slow, what are the next steps you should take to then kind of troubleshoot that and figure that out? And I spend a lot of time working with customers. So I'd like to kind of talk a little bit about some of the ways I go and do that.

Gillian Bruce: Yeah. That'd be great.

Mike Gerholdt: Yeah. Let's jump into that.

Christopher Mar...: The first thing I always tell people is go look at your Lightning Usage app, right? That app came about because we wanted to see how people, how users are adopting Lightning. But now, there's two additional sections in that for pages and browser, and you can get performance. You can see how each browser type is performing, whether you're using Chrome or Safari or whatever browser types you might have. And then you can also see it by page. And I think we showed you right now the top worst performing pages. And we grade them based upon what I talked about earlier, that experience page time, or EPT.
So there, right there and then, by an admin or even a developer going to the Lightning Usage app, they can see what pages they might want to refocus on because they're not performing well. What's even better is that some of that data is actually stored in your Salesforce org. A lot of people don't know that, that behind the scenes, that Lightning Usage App is using a record called Lightning Usage By Browser metrics. It's actually an object and you can actually build custom report types and reports on that object to kind of slice and dice the data a little bit more if you want to get detailed.

Gillian Bruce: Ooh, that's so cool. I didn't even know that. That's great.

Mike Gerholdt: All of that is new. And going through your presentation, I actually saw where you could append the URL to have the EPT show up on the page.

Christopher Mar...: Yeah. And this is a great way to kind of test, from any computer, anywhere in the world, what the EPT is on a page. And you can actually append what we call a URL parameter to the end of the URL. It's just EPT visible equals one. And you'll be able to see how long that page load.
We recommend, or we strive for all pages loaded under the three seconds. And I can tell you at an aggregate here at Salesforce, we hit that number. If you have pages that are six, nine, 12 seconds in EPT, you need to start focusing in on what that page is, how it's configured, and then how you can kind of rearrange it to increase the performance.

Gillian Bruce: So, Chris, this is a lot of great data that now admins are understanding how to access and how to analyze kind of their org. Once we kind of gather this data, I'm wondering when you're working with people and their orgs, how do you kind of interpret this and use all this data to start making a plan? Like, how do you prioritize your like, "Okay, so this page is slow. We're going to try doing tabs first or..." How do you kind of take all of this into action?

Christopher Mar...: Yeah. And that's the key part, right? So the information is great and the Lightning Usage App can tell you where you might have some problems. Your users are obviously going to speak up and say, "It's slow here." The question is, what do you do next? What I've done is you kind of start have to take basically an inventory of the page and understand what you have on the page, what's on the details, how many related lists. Do you have visual force on the page? Are you using third party components? Are you using a managed app exchange component that was built for Classic and hasn't been moved to Lightning?
Those are the key things that we look at, especially with Visualforce. I've worked with a lot of companies that spent a lot of time and they have a lot of things in Visualforce. If you have too many Visualforce components on a page, that can severely slow you down. And I basically worked with a lot of customers, and this is a great story. I worked with a large customer. They had six architects. They were looking at one of their custom object pages. It was taking about 12 seconds to load. They really weren't sure what was going on. They started the Lightning Usage App, but they didn't really know how to break it down.
I sit down with them and I look at it and I say, "Well, you've got 30 related lists, 300 fields, and four Visualforce pages. This is not going to perform as well as you think." And there's a lot of call outs. And I said, "If you put some of these, a few things behind tabs and maybe move Visualforce to some of the standard components," because I saw some of the Visualforce and I said, "That looks like a standard component to me," they could increase their performance.
They were a little bit worried, first off, when I told them that you would need to make all these changes in their UI. But I told them, it's all in the app builder. It's all very declarative. I'm sure your admin can give you a quick estimate what the turnaround is. And of course, there was silence in the room. They had never invited the admin to the call. So you can imagine six architects in a room, scratching their head, trying to figure out why the app is not performing the way they want it to. And meanwhile, the administrator, she's sitting out there, could basically fix their problems in probably less than an hour. She actually turned it around in the next day. They sent me something in the sandbox that reduced their EPT from 12 to three and a half seconds. And then they went even further than that before they ended up deploying it in their next release.
So it's really, one of the reasons I wanted to come on the Admin Podcast is to make a call out to all of our awesome admins out there, all of our app builders to say, you can have a real huge effect on Lightning performance if you just kind of take a look at the page, inventory it, and then understand what's the best way to present it to the user.

Gillian Bruce: I love that story. Yay. Awesome admin power.

Mike Gerholdt: Chris, that's a really good point. And thinking through always being in the conversation, right? So for some of the teams that you work with, do you find that often, some of that standard functionality was rebuilt or they're just not including everyone in the conversation when they're looking at their performance?

Christopher Mar...: Yeah. I mean, certainly in this case, they didn't include the admin in the conversation when they were looking at performance because they felt they were so customized that it wasn't important, which is the exact opposite. Because they were so customized, they needed to have the admin in the room. You know, I also feel like the Visualforce has been around for so long. And I do really love Visualforce. I built a lot of stuff in Visualforce, but a lot of the stuff that we built for standard components came from us seeing people building the same Visualforce page over and over and over again. Right?
So there's some level there that we built for you that you need to now use. A lot of customers when they, again, when they migrate to Lightning using a lift and shift mentality, it's just not optimal. They won't get a optimal Lightning experience because they didn't think about using the standard stuff first, using the declarative stuff first. They just brought over all of that customization, all that Visualforce they made.
I still, on occasion, get asked when will S-Controls be supported in Lightning. I'll just say it here, it'll never happen. And it's a good thing. It's a good thing that we don't do that, because it just kind of relieves yourself with technical debt and you now can use standard stuff for a lot of these things.

Mike Gerholdt: Well, and a lot of the features that we have coming out are quicker than what the previous, the one it replaces, right?

Christopher Mar...: Absolutely.

Mike Gerholdt: The analogy I think of is email's way faster than sending a letter in the mail. Right? It's got mail in the title, but it's way faster. One thing that you touch on that I do want to help admins with... And I'll admit that I'm not the most inept at troubleshooting. We talked a lot about page performance and I feel that admins have that ability to really make that effect, and you've seen that. When troubleshooting, you have a whole slide and a whole kind of section that you talk about browser performance.

Christopher Mar...: Yes.

Mike Gerholdt: Often, when an admin's out walking around, a user will kind of pull him over to be like, "Hey, this is slow. Is there something you can help?" I'd love to know, like, what are some of those things that we can do to kind of jump in and just check and kind of make sure that things are running optimal in that user's computer?

Christopher Mar...: Yeah. Browser performance is key for Lightning. One of the big differences between Classic and Lightning is Classic is rendered all on our side, what we call the server side. It's almost rendered entirely by Salesforce then sent as a old school HTML file all at once in a big, huge, basically text blob. With Lightning, it's a little bit different. We're still doing stuff on the server side, right, because you're still connected to Salesforce. You're still probably running your apex or whatever on the server side. But on the client side is where all the rendering really happens and all the processor happens.
So we need to have... The physical piece of hardware that's in front of you needs to be able to do that rendering. So we have something that we built right into the application called the speed test. It uses a score called octane score, which was invented by Google. And it evaluates your browser's performance specifically within a tab. Does it have a good connection to the Salesforce data center? Is it powerful enough? Does it have enough Ram? Does it have a good upload and download speed? I know with people obviously working a lot from home these days, network connections can really vary. So it's a good thing to look at that.
And when you run that speed test, you really want to get an octane score between 20 and 30,000. And when you have older pieces of hardware, you might need to think about refreshing them or upgrading them. I always say that at a company, those employees that are the most tenured tend to actually have some of the oldest hardware and see the worst performance. Right? And that's just because sometimes, refresh schedules, they get extended or they're simply just not implemented. And today's browsers-based technologies, you don't need to have this mega machine obviously. But having a decent octane score is certainly the first step to ensuring good browser performance.

Mike Gerholdt: Yeah. I can tell you, and I'm sure our admins out there have some stories of users. I had a user on old Internet Explorer. This was right around the time when Salesforce was definitely upgrading some stuff. I said, "You've got to just download Firefox. It's also supported by our IT." Truth be told, some users are shackled by IT only supports certain browsers, and only certain browsers can be downloaded. And thankfully, our IT department support IE and Firefox. And I said, "Just download Firefox and it'll be quicker," and I went back to their desk. And they said, "I downloaded Firefox. It's not any faster." And I look at their page and their page is still open in IE.

Christopher Mar...: Yeah.

Mike Gerholdt: Well, the point of downloading Firefox is that I use Salesforce in Firefox. But to that point, that was one of my most tenured users. And they did have some of the oldest equipment.

Christopher Mar...: Yeah. What I see actually, what typically happens to customers that have some of the worst performance is that it's a combination, right, of poor browser performance, poor hardware, and just massively over-customized pages. And when those two things come together, that's when you see some of the worst performing Lightning pages.

Mike Gerholdt: Yep. Well, great, Chris. I am glad we had you on the podcast. We obviously, a lot to talk about. We can always dive into learning more about how we can set up Lightning pages and troubleshooting browser performance. And we didn't even touch on network performance. But I appreciate you getting on and helping our admins make the users as productive as possible.

Christopher Mar...: Yeah. I just wanted to make one last shout out to Trailhead. There's a great trail called Lightning Experience Performance Optimization. That's going to go into the details of everything I've talked about here. It'll talk to you about EPT and the Lightning Usage App and how to get your octane score and all that sort of stuff. It even talks, we didn't even get into it, but it talks a lot about optimizer. I know you had Niket on a few podcasts ago. And that trail is an awesome trail. Again, the Lightning Experience Performance Optimization trail, go check it out.

Mike Gerholdt: Yeah. And I'll be sure to link to it in the show notes. Thanks so much, Chris.

Christopher Mar...: Thanks so much, Michael.

Gillian Bruce: All right. So for three things that I got from our conversation with Chris, I mean, I got a lot, but my top three are admins, think about using tabs. That is so easy to create tabs on your Lightning pages and use them to make your pages more useful for your users and customize. Chris talked about a whole bunch of different ways you can do that. And maybe you want to drink a Tab while you're playing with tabs.
Next, check performance in your own org. In fact, there's a couple of tools that Chris mentioned that you can, as an admin, use right now to check the performance of your org. There's the Lightning Usage App. And that's where you can view EPT and browser performance. And you can also create a custom report type by using the object Lightning Usage by Page Metrics. So really cool way to get all that data there.
And then you can take actions, like Chris talked about. And then finally, when you're thinking about Lightning components, remember to always start with the standard components. And if you do need to build something custom, remind your developers to start with the base components. It's going to make your components perform better on your page. And there's tons of capabilities there. So don't discount them. Start there. You don't have to build everything from scratch.
If you want to learn more about all things Salesforce admin, go to to find more resources. And a reminder, if you love what you hear, be sure to pop on over to iTunes and give us a review. I promise, Mike and I read all of them. We love them. We need more of them. So give us more reviews. And you can always stay up to date with us on social for all things admins. We're @SalesforceAdmns, no I, on Twitter, #awesomeadmin. And you can find me @gilliankbruce and Mike...

Mike Gerholdt: @MikeGerholdt.

Gillian Bruce: Thank you so much for joining us today and we'll catch you next time in the cloud.

Direct download: Lightning_Speed_with_Chris_Marzilli.mp3
Category:general -- posted at: 11:30pm PDT