Let’s talk about the performance budget. What is it? Why do we really need it? What are the problems when we start a new project and what's the general idea behind this? Watch the video with CTO Krzysztof Wyrzykowski We can help your company with development issues: contact us via form on https://frontendhouse.com.
In the "Performance Budget. Idea, Core Web Vitals, Tools" episode you will find:
- 00:00 - Intro
- 00:49 - Agenda
- 04:08 - Types of performance budget
- 05:09 - Core web vitals
- 09:44 - Example budget
- 12:13 - Tools we can use
Have a nice watch! Don’t forget to like the video and leave comments to share your impressions!
Transcription
What’s up everyone, welcome in Expert Zone. I'm Chris, you already know me from the Fronten News podcast and Expert Zone Talks. I'm also a technical leader and technical director at Liki and in Frontend House. Today we're gonna speak about the performance budget. Hopefully, you will like it. It's a super important topic. So guys, watch the intro and see you soon.
Agenda
Welcome back. First thing first, let's check the agenda. The first starter, we're gonna talk about the performance budget. What is it? Why do we really need it? What are the problems when we start a new project and what's the general idea behind this? Last, I’m gonna talk about Core Web Vitals and that kind of user-centric metrics. And obviously, about tools we can use to track it. So guys, bear with me and let's get started.
I want to have my app fast
I'm sure all of you know the client and know the problem when you start a new project, you talk with your client and they say “I want to have my app fast”.
What does it really mean? Fast. What is fast? What is performance? Nobody knows. To answer this question, we need to have metrics, we need to have a set of rules, and to help us with this we have a performance budget. And once you implement it and you start using it, I'm sure we'll be able to tell your client that ”Yeah, I'm going to deliver your application fast”.
Talking about a fast website, but in the meantime, the median, the average size of resources requested by page is around 2 MB, a little less on mobile and more on desktop. We have 75 requests on desktop, and 69 requests on mobile is the average number. Of course, it can be less, it can be more. But guys, remember every request means more things to load and longer loading time.
We have a median number of TCP connections set to 14, which is absolutely ridiculous. And the last one, we have an average loading time set for 15.3 seconds on the mobile page. Can you really imagine users, even you, waiting 15 seconds to load a mobile website? I don't think so.
One more thing to add: around 53 percent of mobile visitors leave a page within 3 seconds if it doesn't load completely. 3 seconds. Going back to the previous slide, the average loading time is 15 seconds.
How to answer this problem? How to fulfill the gaps? We have the performance budget. I think it's an answer to all your needs. We use it in every kind of project. I use it in every kind of project where I’m a technical leader.
There's a very good quote on Google. So let me read it out loud. “A performance budget is a set of limits imposed on metrics that affect site performance. This could be the total size of a page, the time it takes to load on a mobile network, or even the number of HTTP requests that are sent. Defining a budget helps get the web performance conversation started. It serves as a point of reference for making decisions about design, technology, and adding features”. Very good quote. Nothing too add, to be honest.
Three types of performance budgeting
Let's jump and discuss what that really means. We have three types of performance budget metrics. One is Quantity-based metrics, second is Milestone timings, and the third, last one, Rule-based metrics.
The first one is quite self-explaining - Quantity-based metrics. It means that for the performance budget, you track the size, the maximum size of the image, the maximum size of JavaScript code, CSS code, HTML code, videos, number of videos, number of images... multiple things you can imagine and those we track in the first type of performance budget. I still recommend you to use it at the very beginning of the project and later switch to Milestone timings.
The Milestone timings. They are based on the Core Web Vitals and user-centric metrics - about this a little bit later - and the last one, Rule-base metrics, is based on Lighthouse score and that kind of tools score.
Core Web Vitals
Okay, first, let's start with the Core Web Vitals. We have three main points, which are Largest Contentful Paint, First Input Delay and Cumulative Layout Shift.
Large Contentful Paint, like the good score, is below 2.5 seconds. A very bad score is anything more than 4 seconds. As you can see, a good First Input Delay is less than 100 milliseconds, bad is more than 300 milliseconds. And the good Cumulative Layout Shift is below 0.1 seconds and the bad one is above 0.25 seconds. Let's jump a little bit to details.
Largest Contentful Paint
Largest Contentful Paint - what does that really mean? It's a metric that measures the time, reports the random time of the biggest asset that is visible in your viewport. Let's say you have a hero, and that hero in most cases has an image, a video, that kind of asset. And the Largest Contentful Paint means that 5, or 3, or 4 seconds passed until the page loaded to the time that the user can actually see. It is very important, it can make a big difference, so it's usually a good thing to keep it as fast as possible. Because if you have a hero, it's like the first thing that users see, so it's very, very important for him to not see the empty page, not see broken pixels and that kind of stuff. He wants to see this hero image after all, so yeah, that's why it's very important.
First Input Delay
We have the First Input Delay. This one measures the time from when the user clicks something - I don't know, link button, custom control, and that kind of stuff - until the time that browser can actually handle this request. So that means that let's say during the website loading, obviously if everything is loaded and the user clicks the links, he will be redirected immediately, if you don't have any kind of issues with your code. But during the loading the time can be a little bit longer. It doesn't need to happen immediately, so the First Input Delay means during the loading, I click something, I want to be redirected immediately, I'm not, and that delay is the time that this Core Web Vitals actually measure, again very important.
Cumulative Layout Shift
Cumulative Layout Shift. This is also important, but it's also very annoying. That means, once you open the website you need to load CSS, typography files, phone files, and that kind of stuff. So in the meantime, I mean during the loading, if you don't code things properly, they might be like very annoying layout shifts. So I imagine you want to click something, but suddenly everything drops down a little bit, it’s like shifted. And this time for the last layout shift, it's called Cumulative Layout Shift. Very annoying, let's care about this.
Other metrics
And there are some other metrics. So First Contentful Paint means the time from when the page starts loading to when any part of the page's content is rendered on the screen. Other, Time to Interactive. It's like a time when the page starts loading to when it’s main sub-resources... So obviously when you build the website, you have external libraries, external JavaScript, external CSS code. So the period of time when the page starts loading to when those resources are loaded and they are fully functional and the user can actually use them. And the last one, Total Blocking Time. So it's like the amount of time between First Contentful Paint to Time to Interactive, quite important as well.
How to measure the performance budget? Example
Okay, we know everything. Maybe not everything, but we know a lot about Web Vitals and user-centric metrics. So I think we can measure one of the performance budgets... But how to really care about performance budget? How to work with it?
So let's imagine you start a new project and you have a technical leader, a team of developers, a project manager, and a client obviously. And you set up the performance budget. The performance based budgeting can be like: our product page must ship less than 200 KB. Our search page must include less than 2 MB of images. The home page should load within 5 seconds. Our blog must score on the Lighthouse more than on the performance audit. That kind of metrics. There are multiple of them. You can choose freely, but I recommend you to be smart, like not putting everything in, because it's not possible to handle everything and having them.
Let's imagine the situation when one of the developers had a task to code the hero image. He writes all the code, he does the pull request, and in the pull request technical leader should check if every set of rules are okay, if they are not broken.
Let's say the image is bigger than 2 MB but in the performance budget we said it needs to be less than 2 MB. He should return the pull request and ask the developer to fix it. If the fix is not possible, and it happens of course, there is a set of ways how to deal with it, but I will talk about this later. So again, to sum up, the developer does pull request, technical leader and team of developers try the pull request, they make sure everything is within their rules. If it’s okay and the code quality is good, they merge, if not, they don't. They leave comments, they think about how to deal with this issue. And this is all about, to be honest. I mean, it's quite easy, but trust me, when you start using it, it's so powerful. I love it. I use it in every project, in Liki and in Frontend House.
We use it for every project. So hopefully you will also get used to it. Once you start, you will never go back.
Performance budget in your build process. How to check it?
How can we check the performance budget? I mean, we can obviously check it manually. Go to the Lighthouse, check the image size, check the bundlesize, but there is also a set of tools that we can use. And I strongly recommend you to use it anyway. So we have a webpack that can measure the bundlesize, that can measure the size of the image and that kind of stuff.
So whatever you set, there are multiple tools that we can use within the webpack. One of them is a bundlesize. So obviously it measures the bundlesize, which is very important also, like Lighthouse CI. So once you do pull request, it's very handy. It measures everything and ships you the metric, so you know that performance is good, that accessibility is good, and so on and so on.
Let's keep things fast. I mean, not manually, let's use the tools. If you Google it, you will find a lot of tools you can possibly use, so I strongly recommend you to check and play with it.
What if you exceed? What if you broke one of the rules in the performance budget?
And a very important question, what if I broke one of the rules? So I can optimize the code and make sure it stays within the rules. If it's not possible, I mean, I did everything I can, I can try to optimize other features.
So let's say there's a rule that says that JavaScript needs to be less than 200 KB. I did my code, everything is optimized as hell, but I see that other features can be optimized, the code can be reduced, so I do this. I write in the pull request. I optimize this because thanks to this I was able to keep a good performance budget. Okay, everything's correct. Let's imagine a situation where everything is optimized, I can't do anything more.
So I need to confirm with the team, the technical leader, the project manager, the business site, like the client, agency or product owner, or someone from the product department, if this feature is worth to be implemented? Because we need to redefine the performance budget. So let's say the rule will say it's not less than 200 KB but 300 KB and we really need to think if this really single feature it's worth bending the rules. To make a new rule that is like 300 KB. In most cases, it's worth bending the rules, to be honest. Rules are there to be broken.
And the last thing, I mean a very strict one, is not adding this feature. It never happened in my career, but let me know in the comments if it happens to you.
Handy tool to start a new budget
What can we do to start a new budget process? That is a very handy tool. I use it very often, it's called performancebudget.io. You can specify everything, all performance indicators, sorry if you don't see the entire screen, but hopefully, that will work for you anyway.
So I want my site to load within 5 seconds, let's say 3G connection, calculate... and we get all the rules we should keep. So like 25 KB, HTML, CSS, JavaScript, fonts, image files. And let's say I know that I need images to be a bit bigger, so I sent the rules to be like 1000 KB. Next, I got my preview of the budget. I see all the asset sizes, I see estimated loading time on all types of internet connections here. I think it's okay. I confirm this. I put it to Jira, whatever. Click next. And here is the last step where I can test my website to make sure if I have a good start. You write the URL, you click the test, and the last one - you can download the budget and include it somewhere. To be honest, guys, that's it. I hope you like it.
It's very important. I strongly recommend you to use it. Once you try, one or two times, you will really get used to it. You can say to your client that you have that kind of rules and they will really like it. Trust me, clients, agencies, all public sector, they really like it.
So if you like this Expert Zone, feel free to contact me. Talk about the details. Talk about your story, about your projects. We are on Facebook, Twitter, Linked In, and Instagram. Have a look. Stay in touch, and guys, see you in the next Expert Zone.
