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.

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.

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

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%.

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.

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:

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:

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:

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!