Performance Culture

[00:00:00]
>> Now let's get started with part 3, which is the shortest of our 3 parts. I'm sure you will be excited about that. I'm not gonna keep you that much longer. But we're gonna talk about three important things. In the first 2 parts, we were trying to understand performance and how to work with it.

[00:00:18]
In this part, we're gonna figure out how do we give ourselves the opportunity to work with it? How do we justify our performance work to the people around us, to the businesses we work in, and how do we figure out how much is enough? When have we done enough work on performance and we can move on to other tasks?

[00:00:40]
And how do we justify keeping our application performance over time? Now, in the examples that we put together, I had a website that was pretty slow, but it wasn't that slow. Even at the beginning, my very slow version of requestmetrics.com wasn't that slow, it was kind of okay.

[00:01:03]
I've been to real websites, they were a lot slower than that, and part of that is design up front. If you visit the real requestmetrics.com, It's super fast. And it's super fast for a bunch of reasons. One, I've optimized all those things, but also there's just not that much on the page, it's a pretty simple design.

[00:01:29]
There's light colors, there's lots of spacing, there's a few images. The images are all kind of Ilustrationing, there's not a lot of detail in them, and so they can be much smaller in size. And once you approach something with that kind of simplicity that I want things to be fast from the beginning mindset, it's kind of hard to mess up down the road like I had.

[00:01:54]
It actually took me four days of making things really, really bad to get that website in a state that I could show you how to make it better. It wasn't easy to take a fast website, a website that was designed to be fast from the beginning and make it slow.

[00:02:12]
So that's interesting in its own right. If we make something fast from the beginning, we spend way less time trying to figure it out, and the fixes that we need to do are easier. And we can do that by making performance a team value up front. If you think about the app you're building, or the site you're making, or whatever you're working on, and you think that performance is something that is a core feature of this product.

[00:02:42]
It's something that I wanna compete on. I want to deliver this service and I want to deliver this service 20% faster than our next competitor. And to do that, you need to approach it from the beginning. Performance is not a task. Too many times in too many organizations, this would be a plan of something.

[00:03:03]
We're gonna build a web app and here's a simple compound board. And we've gotten login done, and new user creation done, and we got a bunch of pretty charts, and we're building a change password thing, and we're gonna do send alerts next. And then a week before launch, we're gonna worry about making it fast.

[00:03:21]
I mean it's not gonna work. You can apply some of these techniques and you can improve the performance, but it's never going to be fast. It's going to be not slow. It's going to be less slow than it would have been. But it's never gonna be fast unless you start with fast from the beginning.

[00:03:41]
So how do you start with fast from the beginning? Well, performance needs to be a cross cutting concern, along with other important things like security and quality. If you're building an app that's gonna be open to the internet, you kind of need to start with security ideas right up front.

[00:04:04]
How are we gonna protect this from unauthorized access? How are we going to authenticate our users? How are we gonna do these things? You can't just figure that out at the very end, this are things that need to be built in to the system from the beginning, quality too.

[00:04:20]
You're building something you wanna make sure it's bug free or as close to bug free as you can make it by the end. Well, you can't all of a sudden do huge bug fixing sections at the end. You need to be testing things as you go. Your unit testing and interaction testing., and smoke testing, and whatever other testing is appropriate for your situation, but you need to be doing that along the way.

[00:04:46]
Performance is just like that. You need to be thinking about the performance of your system as you go. How do you do that? You do it with data. So you need to start testing the performance of your site early, do it often, and constantly be getting data. So as you're beginning, when your project is just a twinkle in your eye, the first time you put code on a page, you should run Lighthouse on it.

[00:05:12]
You should run some performance, you should get an idea of how well it performed at the beginning, and periodically take more Lighthouse reports. You can even export them in the UI, you can save them over time, and compare them. As soon as you have it out in the wild, you should be gathering field data and seeing how real users experience your site.

[00:05:34]
This is the only way to really know what to work on. You don't know what's slow unless the users tell you what's slow. And they probably won't call you up and tell you what's slow in any kind of valuable way, you probably need to gather some real data.

[00:05:51]
So monitoring performance from the beginning is incredibly valuable to keeping it fast. Here's an example of some data. So one of the things that Request Metrics can do is we do this flame chart and we can send this out every day. And this is what a lot of companies use to just say, do I need to care?

[00:06:13]
Here's how on the page or here's how the app performed in the last 24 hours with some top level things of, hey, here's how many people visited. Here's what the median user saw, here's what the worst user saw, and here's a chart. And that stuff from a glance, if I'm not aware of any performance issue and I'm not actively working on something, I can look at that and say, okay, that's all right, not worried about it, delete, move on with my day.

[00:06:42]
But without that, you never really know when the performance of your app has fallen because it's gonna do it slowly over time. You're gonna lose 10 milliseconds today, and 20 milliseconds tomorrow, and 100 milliseconds next week when you add that other library. And before you know it, it's gonna take 17 seconds to load your app because you've just piled on and piled on, and piled on.

[00:07:04]
Unless you're monitoring that over time, you can't necessarily see how bad it's gotten. So how do you do this? You need to make fast part of your planning. So when you're planning your work, I don't know what your planning system is, it doesn't matter. I really post notes on a wall, but some people don't.

[00:07:25]
Here's a post note, we're gonna write a login feature for our app. Also, when we're specing out what does login mean, there's various level of details of saying here's what the feature is. The user has to login with a password, cool. Well, you need to be a little bit more specific than that sometimes.

[00:07:44]
You need to say maybe, hey, they shouldn't be able to get to the system if they don't have that password and, hey, it should work on all the browsers. If you got it working in Chrome, that's not enough. You should have it with a wide set of compatibility so that it works on everywhere you need it to work.

[00:08:03]
And maybe what you should include is how fast is acceptable. If you can't log in, if this isn't accomplished in less than two seconds on a mobile device, that is not done. You haven't figured out how to do this performance yet because you're not gonna be able to figure that out at the end.

[00:08:22]
When you're writing the login process is when you need to figure out how to make it fast, not at the end. So this covers all of the main things you need to think about as part of planning work. Here's the feature you're gonna write, you're gonna keep it secure.

[00:08:36]
You wanna make sure it's of high quality, and meets the broadest needs, and you wanna make sure it's fast. By making performance part of this definition of done if I can borrow an agile term, you can bake it into the process and make it part of your culture.