You’re on an old version of this site. Please visit for the latest.

How to Make a Performance Budget

Two weeks ago, some interesting discussions flared up around performance budgets. I can’t help but feel somewhat responsible.

It all seems to have stemmed from Chris Coyier’s tweet, and I was coincidentally on stage at An Event Apart San Francisco talking about performance budgets at that very moment with Chris in the room. In response, Tim Kadlec posted Performance Budget Metrics, a great categorization schema for the different ways you can measure performance. I should mention: just about everything I know about performance budgets comes from Tim, either from his writings or through the stuff I observed while we worked on the Grantland and Radio Free Europe redesigns together.

Lots of people have been writing and talking about performance budgets, but I had yet to see anyone exhaustively explain how to make one, especially to less technically-savvy designers (like me). So I decided to take it into my own hands. I didn’t do a great job of giving the appropriate disclaimers in the talk—cut me some slack… it was my first time giving that talk—so I think Chris’s concerns are legit. I’ll attempt to correct that here.

Earth as a reference, from Apollo 13

There’s an amazing scene in Ron Howard’s Apollo 13 where (spoilers ahead) the crew loses power of their spacecraft. They have no way to know how they’re oriented because their instrumentation is dead, so they use Earth as their frame of reference. As long as they keep that view of Earth in the window, they know they’re on the right track.

The main reason to create a performance budget is to have a tangible starting point for conversation around a web page or website. It shouldn’t act as gospel, but it’s a thing you can measure against. It’s your frame of reference.

I believe designers do their best work within constraints, and knowing those constraints before starting a design can be incredibly enabling. I can’t tell you how many times I’ve ignorantly designed “the perfect comp” and was then told that I blew the performance budget we never established in the first place. What I wouldn’t give to know that I could use up to 10 images and 4 webfonts before starting a design! What a day that would be! Here’s how to make that possible.

In Tim’s article, commenter Mike Petrovich wisely points out a summation of Tim’s categorization:

“Milestone timing and Speed Index describe the user experience‚Ķ Quantity and rule metrics describe the low-level browser experience.”

In my opinion, a good performance budget balances user experience with browser experience. Again, it’s not an all-encompassing strategy, but it’ll get you in the ballpark. I know there are better ways, but none of them give me something to act on in Photoshop. Personally, I’m with Tim in thinking Speed Index is the most accurate metric to shoot for, but it is pretty tough to explain.

So, if I’m searching for something a bit simpler and a little more communicable, I’ll generally start with a milestone—a fully loaded page in 5 seconds or less—and try to get some approximation of a budget (10 images/4 webfonts or 2 images/10 webfonts). But where do you get that milestone? Should you just pull it out of thin air? (Beware: your CEO just might!) Well, I like to be a bit more methodical than that.

Pop open a blank spreadsheet and WebPagetest. Pop your current site in there and let it ride. Record these three times: Start Render, Document Complete, and Fully Loaded.

Site name Start Render Document Complete Fully Loaded 7.388s 9.321s 11.940s

For the purposes of this exercise, I’m recording all times against WebPagetest’s Mobile 3G connection speed (768 Kbps).

Then, do a little benchmarking. Run 3 competitors’ sites or sites you admire through WebPagetest, and highlight the fastest site of the bunch.

Site name Start Render Document Complete Fully Loaded 7.388s 9.321s 11.940s 1.492s 3.150s 3.527s 5.290s 7.769s 9.882s 4.891s 28.394s 29.980s

Tim blows away the competition, as expected.

Tim found this great statistic that people perceive tasks as faster or slower when there’s a least a 20% time difference. So, let’s take our fastest times and try to beat them by 20%.

  Current Time Target time (20% faster)
Start Render 1.492s 1.194s
Document Complete 3.150s 2.52s
Fully Loaded 3.527s 2.822s

This gives us the milestones we’re shooting for. How does that translate to constraints to bring into a design tool? It depends on your assumed network speed. Since we’re using WebPagetest’s Mobile 3G connection speed, that assumes a transfer speed of 768 kilobits per second. But, we measure resources in terms of bytes, not bits. One byte = 8 bits, so 3G translates roughly to about 96 kilobytes per second. We can use this number to calculate some rough conversions.

  Target Time Kilobyte Weight
Start Render 1.194s 114kb
Document Complete 2.52s 242kb
Fully Loaded 2.822s 271kb

If we split that 114kb evenly among the things we need to load—HTML, CSS, JavaScript, Images, and Webfonts—we might get a distribution that looks like this:

Type Weight
HTML 22.8kb
CSS 22.8kb
JavaScript 22.8kb
Images 22.8kb
Webfonts 22.8kb
Total 114kb

While that makes for a nice, even split, it’s not entirely realistic. While it’s possible to get a 22.8k webfont, many that I’ve used are a lot heavier. This may make a good case for us to say that we’ll forego webfonts for the Start Render milestone. (The ability to practice this kind of reasoning is exactly why having a literal budget in front of you is important.) We can take that 22.8kb that would have gone to webfonts and instead reallocate it to something like images. That gives us this kind of distribution:

Type Weight
HTML 22.8kb
CSS 22.8kb
JavaScript 22.8kb
Images 45.6kb
Total 114kb

Or, we might be able to get away with not needing any JavaScript or images for that first render and instead want a beautiful typographic experience, so we could allocate it this way:

Type Weight
HTML 22.8kb
CSS 22.8kb
Webfonts 68.4kb
Total 114kb

Wikipedia’s definition of the word budget is perfect:

“A quantitative expression of a plan for a defined period of time.”

For a designer, having a quantitative expression of a plan that suggests a Start Render experience of 2 images (~45.6k) or 2 webfonts (~68.4k) and knowing that you can still nail a 1.194s time is incredibly empowering. It gives you some flexibility to negotiate with yourself, your developers, your bosses, and your customers about performance.

You’ll notice I keep using words like “approximate” and “rough.” Keep in mind: this budget plans for a best case scenario, but the web is often an environment of harsh conditions. Lots can go awry, so make sure to plan for performance responsibly. This type of budget is just a set of guides for us to use, not a rulebook to follow dogmatically. There are a lot of people writing smart things and better ways to create fast websites, but I think having a tangible approximation of what resources you can work with is a good start.

And, here’s a Google Sheet template that you can copy and edit, if you roll like that.

Happy performance budgeting!

blog comments powered by Disqus

Article Info