Someone said my app is slow. Now what?

The dreaded support ticket gets filed: App is slow! Before you get defensive or close as "Won't fix", consider a few tips on how to successfully approach this situation.

Sign up for our Laravel tips newsletter!

Ed Balls Day wikipedia article

Creators & Guests

Host

Aaron Saray

Host

Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:16):
I'm going to pose a hypothetical situation here. You have an app that you've built which is in production.

Aaron Saray (00:23):
Okay.

Joel Clermont (00:23):
And you hear, maybe via support or an email or something, that the app is slow, all right? That's the extent of the report that you've received. Where would you start after getting such an email?

Aaron Saray (00:43):
Well, I would click mark as spam and call it a day. No, I think that's a good question because I'm sure everyone's kind of had that situation before. There's a number of different ways to approach that. I think the first way, and I think I'm going to go off a little on the side here that you weren't expecting, is empathy.

Joel Clermont (01:07):
Okay.

Aaron Saray (01:07):
You weren't expecting me to say that?

Joel Clermont (01:08):
I was not expecting that, yeah, not even a little.

Aaron Saray (01:11):
I think the first thing is when people say something is slow or whatever, they have some sort of experience that they're expecting and there's nothing you can say that's going to make them change right away what they expect. The best thing to do to get the most information out of them is to come alongside of them in an empathetic way and say, "Oh, I can imagine having a slow application, it's frustrating. I'd like to know a little bit more about the experience you're having, so could you explain that a little bit more to me?" As much as that kind of sounds a little like, I don't want to talk that way, you're really accomplishing a couple things there.
One, is coming alongside someone helping them not be so angry is actually going to open them up to give you more information. Your job is to solve whatever problem is happening and we don't really even know if it's a problem yet, but the only way we can solve that problem is getting information out of that person. While we know it's not your code, it's a problem, it might be. You can't be all defensive. You have to come along and say, "Oh, I understand that, that's a problem." When you connect with someone that way, they're more likely to tell you more information. Think about it like when you're talking with your friends and they ask... They don't try to solve the problem, they just listen and they say, "Hey, yeah, that does suck."
And you're like, "Yeah, and here's even more information about it that you don't care about." As a developer though, we need all that extra information. I think the first thing to do is when someone says, "Hey, your app is slow." Is to put pause on that angry feel, unless you don't have anger issues like I do. But put pause on that angry feel and say, "I get it, what's actually happening?" So that's the first thing.

Joel Clermont (02:53):
Even if their action rises to the level of anger, usually is a little adversarial. Because you take pride in the thing you built and they're saying it doesn't work right, and you're like, "Well, of course it does." You must be on IE6, on a Pentium computer. That's got to be the problem, right? Just to kind of go along with your thought.

Aaron Saray (03:14):
Press the turbo button.

Joel Clermont (03:16):
What's a turbo button? To put a positive spin on it, you could even take a moment to be grateful that they told you there was an issue because some users would just be disgruntled and maybe just stop using the app. I would also say that, "It's slow," is a step above, "It doesn't work," in terms of descriptiveness. They gave you a little bit more information than just the app doesn't work so there's some positive there. All right, so let's assume you've handled your emotions correctly and you've gotten to the point of requesting more information. What sorts of things might you ask them to tell you about the problem?

Aaron Saray (03:57):
Well, I think had asked them, what steps are you taking and where does it appear to be slow? Because I think if you asked them in that order, they're going to be less likely to say, "It's just slow overall." You can say, "Okay, what particular things were you doing where you started to notice it seemed a little bit more slower than you expected?" I will put a side here, I don't know if you can notice. But my very first technical job was in customer tech support, so maybe that's how I have the smoother way of talking about issues. But I think if you can ask them the steps that can really get you along the way. Then, as funny as it sounds, getting the person to talk about they expect it to be a little bit faster than that or agree that, "Here is the problem, here's what the solution is," is really going to get you to the point where you both understand the problem and the solution. Because they can say, "It's slow here," but maybe it was always slow there.

Joel Clermont (05:03):
Right.

Aaron Saray (05:04):
That wasn't what they were talking about, they were talking about something else.

Joel Clermont (05:07):
Yeah, I was thinking about that too, that context. Is this newly slow or has it been slow all along and you're just complaining about it now because you can't take it anymore? Those are important pieces of context to try to decipher. All right. So maybe you've gotten all the information you feel you need from the user what's your next step from there? How do you tackle it with your... You've taken off your customer service hat, now you have your developer hat on.

Aaron Saray (05:35):
Well, I think there's two different ways I'd kind of... I'd split it in half. One is the frontend experience on how slow it is in the browser from loading a page, making that connection, to the final painter render. The other is how long it takes the server from the beginning of a request to it sends back data. Because those are two distinct, very different funnels of time being spent. You could say the frontend kind of overlaps because there is that wait time where it's on the server. But, I mean, you can't really do anything about that if you're a frontend programmer then, right?

Joel Clermont (06:10):
Right.

Aaron Saray (06:10):
It just takes that long. I think I would figure out... Hopefully I can duplicate at least some of the issue and try to figure out which area is probably the one that is causing the issue using tools like the Network Inspector inside of DevTools. You can also use tools like Telescope in Laravel to see how many queries are running and things like that. Then I think really when it comes down to it, there's only a couple of things that really make it slow most times in an application and nine out of 10 times it's one of those things. Those things starting in a backend would be very complex calculations which is probably the least likely. Then it would be doing stuff that should have been in the job but you did it in forefront, which is like sending mail or something. Takes a little bit longer. Or it's N+1 type queries or many queries, or not eagerly loading or loading too much data and whatnot with the eloquent models.
That's probably usually the most common situation I ran into with applications on the backend. Then on the frontend, I mean, that's a whole other discipline. But you can take a look at each one of those and say, "How long does it take for this file to load? Is there anything blocking?" Understanding the difference between what blocks in the browser and what doesn't. JavaScript taking place over CSS, paints that happen in the browser, things like that. That's something we could really get into. But you can see that and say, "Maybe this file is too large," or, "Maybe I should investigate a little bit into Webpack chunking or stuff like that, I don't necessarily need to load all of this. Another common thing is applications that have huge admin sections. Or, the user has no need to get that JavaScript, so stop sending it to them. Things like that.

Joel Clermont (08:04):
Right, yeah. Now, you mentioned duplicating the issue, do you go as far as logging in as them? Or, do you try to just reproduce it in a more generic circumstance? Because I'm just thinking. Sometimes, let's say it's a user that has way more data than the average user, maybe it's just slow for them because of how much data they particularly they have in their account.

Aaron Saray (08:27):
Yeah. Well, I think your question was leading. Do you sometimes log in as them when their account is special and that's probably the problem? Yes-

Joel Clermont (08:36):
That's been answered, overruled

Aaron Saray (08:39):
Yeah, I think that's one case. But what I would generally try to do is get it quick from the step of identifying it's something unique to their account, to duplicating their account locally then versus using their live production account or whatever. Because a couple different things I want to make sure of is not changing any data or anything like that but I also... To be honest, I've worked with a lot of marketing teams. I don't know what they're measuring to be honest but I know they're measuring stuff. And the more I use production, the more I'm offsetting their numbers to possibly be incorrect.

Joel Clermont (09:15):
That's true.

Aaron Saray (09:15):
Why is someone loading a dashboard 27 times every minute? That seems weird. Oh, sorry that was mean.

Joel Clermont (09:22):
Well, and if the thing that's slow is generating payroll checks or something that you just can't reproduce it in production because it's doing things in the outside world. That's a good point too. Yeah, just my own observation is sometimes I might ask too much information of the user. Like, "Well, what browser are you using? Do you have any extensions installed?" It's kind of almost implying it's their problem. So I was just thinking of that too because maybe another facet of that empathy is, get enough information for them to describe what happened but maybe don't go overboard asking them to give you technical information until you've done your initial analysis. Because maybe you'll find that you won't need that information and it's not browser-specific. And you only ask for that other stuff when you run out of options on your own.

Aaron Saray (10:15):
Well, it's like, what do they say in the financial world? The past performance doesn't guarantee future gains or whatever, something like that. I find that I had to work really hard over the years to treat each situation as new. Yeah, there are a lot of things that are the same. But it doesn't mean just because the last six people you talked to had a messed up browser, that the seventh person has a messed up browser.

Joel Clermont (10:40):
Right.

Aaron Saray (10:41):
We try to take all these shortcuts in the sake of efficiency, sometimes you can actually go down the wrong path that way then.

Joel Clermont (10:50):
Yeah. Well, this has been useful. I think it's a good place to start gathering information, reproducing the issue if you can, how to handle the emotional impact of getting a bug report like this. But how about next episode, we dive into the more technical aspects of this and we could talk about some specific techniques for making the code faster once we've identified the issue?

Aaron Saray (11:12):
Cool.
I have used Facebook and Twitter for a long time and what I find interesting is all the different UI and UX changes they've made over the years and how you might do updates or search for things. I've been using it for quite a long time and I still get a little afraid when I open up Twitter especially and I'm going to search for someone or a topic. I start searching and then I have to click to make sure I'm not just posting this person's name to my timeline, am I? Or, let's be honest, if you're on Facebook searching someone you want to know about them.
You put in their name and you're like, "That'd probably be the worst thing to just have a status update that says, 'Joel Clermont.'" It's pretty easy for us who have been... Well, I wouldn't say pretty easy, but it's easy enough for us who have been using these services for a long time. But I think about other people who maybe got involved with it or didn't have that much experience on internet or websites and that reminds me of Ed Balls Day. Do you know what Ed Balls Day is?

Joel Clermont (12:26):
I didn't, until you told me about it some time ago. But why don't we share this nugget of internet history with everyone?

Aaron Saray (12:33):
Ed Balls is from London, England, he is a Member of Parliament. In April of 2011, he got on Twitter for the first time and he was looking to search someone or something like that, he wanted to checkout stuff. So he just put his own name in the tweet box and hit Tweet. Basically one of his first tweets is Ed Balls, his own name. From then on, it was retweeted by thousands and thousands of people. He was unaware that you were able to delete tweets so the tweet has never been deleted now. And now the incident is now celebrated as Ed Balls Day every 28th of April. If you're on internet on the 28th of April and you happen to see Ed Balls Day, know that it was a gentleman who maybe did the same mistake that we all could do when Twitter and Facebook and all those move around their little status updates and put your own name in.

Joel Clermont (13:39):
Yeah, I will tell you the experience I had learning about Mr. Balls. Is that prior to hearing about it, I really never gave this second thought. But since it, I'm like, if I'm about to search for something, I have just that hesitation. Like, "Am I going to pull in an Ed Balls here? Or am I actually using the search feature correctly?" I think this is both a PSA and a cautionary tale to people. And it certainly might be something you think about the next time you do a search on the internet.

Aaron Saray (14:13):
Can you just not wait till the next episode to get tips on how to make your Laravel application better, faster and stronger?

Joel Clermont (14:21):
We can help. Head over to our website, nocompromises.io/tips and sign up for our free weekly newsletter.