Daily Brush for Website Speed: Embrace the Performance Budget Ritual

Hi, everyone. My name is Ned Haddawood. I'm a senior software engineer working for Miro and a Google expert in web performance. Today, I'm going to get you on a journey to impress web performance budget rituals. But before that, let's imagine together if the website is like the human body. Human body is growing up by eating food. The more you're eating food, the more you need to brush your teeth, the more you need to floss your teeth on a daily basis, right?

If you imagine the website is like a human body, I imagine performance as your teeth. So the more you are feeding your website with new features, the more you need to care about performance. The similarity between both of them, if you have a problem in teeth, you're visiting a dentist to fix it for you. If you have a problem in performance, you might visit or hire a performance expert to fix it for you. Both of them cannot be fixed because with a smaller check-in inspection, you will find out that you were not caring too much about them.

Some people might argue and say, Well, we are not doing that and turns out just fine. Just like these two gentlemen. But here are two facts. First of all, bad teeth are working too. You can eat on bad teeth, but believe me, you're not going to enjoy food. The other fact is that you don't know for how long you're not going to suffer from a problem from your teeth or your performance. It might take a long time until you find out a lot of problems jumping in. So the sooner you are acting, the better. So let's jump on.

If you have a problem. The first thing to do is to measure this problem to just see how big or small this problem so you can act on.

So measuring performance, we have two types of measuring performance. The first one is synthetic testing, also known as lab testing using something like Lighthouse. It has some benefits and has some bad things. The good thing is that it's very consistent and it's free and it's handy. Just easy to do, but it's not super accurate. This is a problem. Why is this not super accurate? Because it depends pretty much on the machine that we are running on.

The other type is RAM testing, real user measuring, or also known as fill testing. This is more interesting for us today. And this is coming with real user, plug in, opt in, and we're getting bunch of information about them that will help us take more and better decisions. It's like geolocation, browser and time, Internet connection, and so on. It's very accurate and we can rely on it, but it's not always free. One free option could be the Chrome User Experience Report. But other paid options, like Calibre, Speedcurve, and so on, are totally worth it as well. As you can see in a bit.

So, using both of them you can measure a lot of metrics that are very useful for us to measure performance and to decide whether our website is performant enough or not. They came as well with some research thresholds and recommendations. For example, in front of us, three recommendations based on the core web vitals. For the LCP for example, we need to make it under 4 seconds at least to make it work fine. And 2.5 seconds is a recommendation for a good experience for the user. This is very useful to set your performance goal. And there is difference between performance goal and performance budget as we will see in a bit.

So, you have a problem, you went to the manager and say, Hey, we have a serious problem in our performance. We have performance issues. Just said, alright, we can postpone it after the next quarter future, right? He showed the number. This is not affecting the business, right? But it is, of course, affecting your business, online business. And you suggest to make a performance sprint for the whole team focusing on performance to enhance it. You did a good job, you and your team, and you turned everything to be green.

Your manager was really happy. Have you seen this guy happy before? This is your manager. And he said, well, let's compensate this time that we spent without adding new features or adding list features. Let's add more features now, since we have a good performance.

After a few sprints with new features with less to no maintenance, our scores have been affected. So the performance is now amber. It's not red, but it's amber. It's not green as before. Manager, look and say, right, it will be just fine, just like the guy in the beginning of this presentation. And keep adding some new features with no maintenance to performance. And this time, we are affected. We're badly affected in business.

And he found out that there is a problem. He's sitting and meeting with the team, asking, what can we do for this regression in performance with adding new features? And say, all right, let's make a performance sprint. He said, well, we tried before. We're reaching our goals, but it doesn't help in regression, as you can see. Another guy said, well, let's ignore users. We're building new features. We'll like it. And he said, no, we need to care about users. Those are the people who are paying for us. Third one said, very wise advice. He said, no new features without a performance budget. Most probably, the manager didn't listen to the last part, but he was pissed off already with no new features without a performance budget. But it was very wise, very important advice. Here is what is performance budget that will be a very useful solution for what we have. Performance budget is simply a way for limiting chances for ruining performance. Same what we have of your application by providing some rules and keep checking daily. Its main goal is to prevent regressions in both UX and business goals. This is the perfect solution for this situation right? So let's start with the rituals.

We have some steps for rituals. First of all is to create a budget, is to apply the budget. Make it stick. And dealing with new features. This evil that is affecting our performance goals.

So first of all, how to create a budget. There are steps if you have already some performance issues in your website as we start thinking about a budget. First of all, measure performance using the tools I talked about in the beginning. And set goals for each of the metrics that you care about. Next, plan and fix most of the issues until you are fairly satisfied about the result. It doesn't have to be perfect. Afterwards, you can set this goal that you reached as a performance budget. And keep iterating. Every time you are making a new progress and you feel that this budget can be enhanced, you can enhance it. Measure, fix and enhance budget.

If you are adding a new project or in an early stage of the project, it's highly recommended to start with a budget. You can use this beautiful calculator online. Give it only the target load time and target user connection. Just like 4G or 3G or whatever. And gives you recommendations about assets that you have. The budget comes in a form of JSON file, just similar to this one. This comes with specifying the target path, specifying the budget type, size or counts. And specifying the resource type, script, third party and so on. If you are measuring sizes, it comes with number. This number is in kilobytes. If you are measuring counts, it comes with just a number of this resource. So we have a budget.

How to apply it? There's tons of tools out there. Some of them are free and some of them are paid. I started with a free tool called Bundlesize.

This you can just use a bundle, budget.json file or package.json to add these rules. Based on that it can be integrated into your GitHub Actions or something and check every time your building telling you that you are on budget or not.

Another free tool, in Webpack, if you are having Webpack already in your current project, you can just configure it for performance and it gives you similar hints for bundle size and tells you as you are building are you exceeding the budget or not with this beautiful error message.

Another free tool, if you are using Lighthouse CI or not, just try it out. It comes supporting now as well budgets with something like a light wallet. What's so cool about that is you use a separate file, a budget.json file and you can run it against any URL added to your CI and you can run it against the website of your competitors as well and see how they are behaving with the same budget that you are setting for yourself.

One big tool called SpeedCurve. It comes with this beautiful dashboard telling you what is on budget, what's under the budget, and what's exceeding the budget. This is very useful and very handy but unfortunately it's a paid tool but it's totally worth it with this beautiful way and with all the warnings and all the notifications. It comes with trail version as well. What's so cool, it comes with this trend for each of these metrics. It tells you when you added something that is exceeding your budget and so on. This is very useful and very handy. Another paid tool called Caliper. You can use it more. It is doing the same thing like SpeedCurve and it comes with this web hoax and gives you also all information that you need about the user. What's profile, what's the device used, and what's the Internet connection for this moment. And much more, you can just check online just to name some. But you can check online and find out which one that fits your business best.

Now it's time to talk briefly about how to make it stick. Not to let developers work around it. First of all, you need to make it your budget concrete. You can say we needed the fastest possible. You can say I want LCP to be under three seconds and mobile or 4G connection. That's very specific, very concrete. Or say performance score to be over 95% for desktop.

You need to make it meaningful. So you wouldn't say I would like to just make performance because it's a trend or something. No. You have to connect it to business goals, business needs. That is serving for some business metrics like balance rate or conversion rate and so on.

You need to make it integrated. So you can't just run it every time manually or in a specific script locally. You need to integrate it in a ucicd pipeline. So it runs automatically and gives you reports. It needs to be visible for stakeholders and developers so to act accordingly. Stakeholders might need some breaks for their speed and telling them that some features might affect the performance. It's very important to set up this culture in the team.

You need to make it enforceable as well. So every time we exceed it we modify it. That's a bad culture. The good culture is that this is a hard line. Everyone will rally about it and this is something to change it. It has to be based on data. We have to have some specific data about the user that has been changed and based on that we are changing what we have. We have new feature so what do we do? First of all, optimize existing feature. Most of the features that are causing problem in performance are features that have been added in early stage or in MVP. Just go ahead and optimize it to leave some room for new features. Remove existing feature.

If you remove it, if it's not valid anymore or at least remove it from the critical path. Don't add new features. Yes, some features might be very annoying for performance or at least don't add them to the critical path. Just rethink it every time based on this visibility in front of stakeholders and developers that will be easier.

Finally, just run any new feature that might affect performance on EBTesting and find out the measurement and metrics how they are behaving with the new feature. With that, so the rituals should be done and you should feel the force around you. You are protected and any performance win that you are making will be protected against being broken.

Just remember that performance is an ongoing journey just like dental hygiene, it has to be daily. And promise to brush with performance alongside with your teeth on daily basis because both of them will keep a bright smile on your face just like this one. Thank you very much for watching and if you like this presentation you will be shared later on my Twitter, on this handle and for more information and more content like this one you will find on my blog metahut.dev Let's connect.