Web Performance Fundamentals

Goals & Performance Budget

Web Performance Fundamentals

Check out a free preview of the full Web Performance Fundamentals course

The "Goals & Performance Budget" Lesson is part of the full, Web Performance Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Todd explains how to set performance goals and a performance budget for a web website. The performance budget outlines the size of the images, JavaScript, and other assets in a project. Identifying the main users and connection speeds makes budgeting for performance easier.


Transcript from the "Goals & Performance Budget" Lesson

>> When you're starting your process, how do you you need to make performance goals like what do you want your app to be? When you say you want it to be fast or you want it to be not slow, what does that mean specifically? And to do that you need to answer a couple of questions, about the larger ecosystem of your project.

So who are your users? I am amazed at how many developers I've talked to who actually cannot even answer this question, you're building an app, who are the people who are using it? like, tell me about them. What kind of device do they have, do they? Are they android people?

Are they iOS people? Are they old crappy iOS people? Are they old crappy android people like are they running running iPhone eights? Are they running android four? Are they in a corporate environment and they're still locked into iE 11 for some reason. Like, there's all kinds of diversity out there, and you need to make sure you understand who is using your stuff and what device they have.

Once you know that you need to think about the psychology that you've put them in. Think about the psychology of waiting. How long are they going to be willing to wait for your project? How anxious are they, how much value do they get from it. How much overhead can you give them without them being all pissed at you.

And if it's about more than them just not being pissed, how fast you need to make it for them to be genuinely impressed by yourself. What is the competitor, and how do you be 20% faster than them? How do you hit that mark? Is setting that goal. So bringing that down and making it practical, you can answer a question by saying, my site or my app should load in however many seconds and load is an ambiguous term.

It's not necessarily the load event. It could be largest contentful paint. It could be until your loading screen is done. It could be whatever, whatever that is appropriately to mean for your app. That site you should hit that marker in how many seconds on what kind of connection.

And by answering that, you can feed that into how big can you make things. There's a fantastic site called performancebudget.io where we can try this. So let's, I'm gonna do that together. You can do it too if you want, not necessarily if you do not want to play with it.

But here's performancebudget.io and so we can put things together. So if I want my site request metrics.com, if I want to load in two seconds on a DSL, how fast it are, and I go It allows me to customize things like how much of different things am I going to do?

So, all right, I'm not going to write a whole lot of JavaScript on it. I'm going to keep that like for K,12K for CSS, and that seems okay. I'm probably gonna need a little bit more images and then I'm not going to use a video. So, if I click go with this budgets, here is what I would actually achieve so, on DSL I would load in 1 point 2 seconds if I can stay within these size budgets approximately.

And in the worst case on a slow mobile 2G connection, it would take 70 seconds 56k 43. Super fast it's like you wouldn't even know that you'd hit enter and the page would be done. It'd be awesome. Now this is hitting these size targets. This is what's called your performance budget.

How big can your stuff be and still hits your performance targets? And if you're going to exceed that, you need to make it compromise in one of two places. Either something else has to get smaller or you're gonna get slower. It's an iron triangle, you can't both keep piling JavaScript in and keep getting faster at the same time.

Now, this is approximates, right? Because there's lots of variables in the equation. We talked about, CDNs and changing load times and what's necessary. So this is assuming you've applied most general performance best practices. Here's how much stuff you have to do to get to load time. Once you know this, you've set a performance budget.

And you can go from the beginning of your project, knowing what that budget is and make decisions as you go. So if you get a feature coming along you need to chart at this, beautiful interactive chart on your page. But to accomplish that you have to pull down 100 low wage jobs, and blows you out of your budget, then you can put that back to, whoever needs a good decision and say hey, we totally have this feature.

Schools slow down the site by five seconds. And maybe it's worth it, maybe that feature will make the site valuable enough that people will wait for it. Maybe you can put a spinner in and that will be okay because you're about to deliver so much awesome that they'll wait but they won't.

If that's shocking, now, the business person, the project manager, your peer, your boss, you whoever needs to know that. Think about it in terms of is this feature worth making the site slow?. This is a question that you need to ask yourself all the time. For performance to be important.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now