Web perf basics - Performance Budgets

Web perf basics - Performance Budgets

Resource & metric based budgets

Now that we’ve talked about performance metrics and introduced ourselves to SpeedCurve, I would like to continue with performance budgets and the role they play when building performant web experiences.

Performance budgets are made up of two things, resource budgets - limiting asset file size, and metric budgets - monitoring Synthetic & RUM data and the many many metric acronyms that belong to that segment.

Let’s begin on the more uncomplicated side and talk about resource budgets first. Resource budgets are simply file-size constraints on normally all of your resources, like the HTML document, your CSS, your fonts, your images, JavaScript, and so on.

Resource budgets

To define a resource budget, ask yourself the question:

What's important for my site to be able to perform, to be valuable?

Odds are pretty high you may need to cut down on a few things to reach your set target, and you might be surprised that cutting down doesn’t need to be a bad thing.

If you don’t know where to begin there are many resources out there that can assist you in the process of creating your own resource budget, and a favorite one of mine is the site performancebudget.io

Their idea is simple - you create your budget simply by filling in the blanks in the following sentence:

The generated budget is purely a result of full resource load vs connection speed, so to reach the goal of loading a site in 5 seconds on a Fast 3G mobile connection (1.6 Mbps), your budget would look something like this:

HTML - 25kb | CSS - 32kb | JavaScript - 165kb | Images - 630kb Video - 97kb | Fonts - 50kb

Total budget: 999kb

Now let's look at a full load in 5 seconds but on a slower 3G connection (780 Kbps)

HTML - 12kb | CSS - 15kb | JavaScript - 79kb | Images - 302kb Video - 46kb | Fonts - 24kb

Total budget: 478kb

The numbers paint a pretty clear picture - images and scripts are seemingly our largest resources and thus our biggest problem area.

And although the "reduce one, increase the other" mindset does work, remember that it's generally considered a bad thing to increase on the script side due to its blocking (parsing, compiling, and execution) nature.

So what's a good resource budget?

Well, it depends entirely on your application. While keeping Javascript to a minimum is sought after in an e-commerce context where speed equals money, you might actually be working on something that resembles more of an app than anything else. And in that case, your budget needs to take that into account.

In other words, whatever you have - use that as your initial baseline and make sure you don't exceed your budget from now on. Then start questioning whether you really need [ X ] or [ X ], or isn't [ X ] more a nice to have kind of thing?

Staying on track

Making sure your team doesn't exceed a set resource budget can be done in several ways, something I find to work is by setting up a step in your deployment or PR pipeline by running LightHouse CI with Puppeteer, making sure that pull requests that introduce budget regressions are invalidated.

Metric budgets

The reason why metric-based budgets are considered to be more difficult is that they require additional insight into the world of performance, reasoning about filesize feels more intuitive than knowing what a good threshold for a CLS score is, or if CLS even matters for you (bad example, it does).

That being said, it doesn’t need to be that hard either.

So what do you measure?

Before the Web Vitals era, I would say this question was a lot harder to answer, and it still is to an extent. The main reason being:

Performance metrics are highly personal for your type of client and their interests.

Your e-commerce client might be interested in their visitors being able to checkout as fast as humanly possible, while the client your colleague is working with needs to make sure a certain type of UI flow runs as smooth as possible from a certain point in time, thus more interested in runtime performance ( hi Ivan Akulov 👋 ).

Still, I would say that - if you don't know where to start? Start with the Google Web Vital metrics and continue on from there.

If you feel there's nothing out there that really matters for your project then why not follow the likes of Twitter (they measure TTFT - Time to first tweet) and create your own metric using the PerformanceObserver API or the User Timing API.

How do I measure all of these unknowns?

With a tool like SpeedCurve, measuring is made dead easy as every dashboard you create gives you the opportunity to set a performance budget (not only that but email alerts too), the real question is what that budget threshold should be.

One way of figuring that out, in the true spirit of competition, would be to use SpeedCurve to benchmark your competitors and then use that output as a way to produce a target you strive to beat by 20%.

Final thoughts

Performance budgeting is a big fish in the bigger pond of web performance and it needs to be taken seriously, but it's by no means the one answer. Think of it as a compliment to your other tools in your belt, like above-the-fold optimizations, caching strategies, image optimizations, etc.

The possibilities are many, it's the knowing of what to measure and how that metric, whatever it may be, directly affects your client's needs and business values where you find the good stuff.