- May 29, 2014
Designing with a (Performance) Budget
Lately, the web industry has been focusing on ways to improve performance—specifically, by applying the idea of a “performance budget.” A performance budget involves establishing a target page weight (usually in kilobytes), and then making sure no single page exceeds that value. While sticking to this number may seem like a developer’s burden to bear, as Mark Perkins puts it, “performance is everyone’s problem.” As a designer, it’s important to keep your budget in mind throughout your entire process—all the way from discovery through implementation. When both designers and developers work closely to set and stick to a budget, a sweet spot will emerge where neither performance or design will be compromised.
When I first heard the concept of a performance budget, I groaned quietly, rolled my eyes, and thought, “Oh, great. One more technical thing to stand in my way.” I worried a budget would restrict my vision and suck the life out of any potentially-totally-awesome ideas I may have had. But, as us designers do, I learned to love the challenge of solving a problem within a set of strict parameters. In the same way that we focus on better user experience and accessibility across devices, performance should be part of our standards.
The challenge of incorporating yet another guideline into your design process can be worrisome at first. This challenge can be even worse if you try to go back and alter your designs to meet your budget after you are well into development. It’s imperative to set expectations with your team from the beginning. You must be aware of how you’re going to approach your budget in the design.
Even when designing for performance from the start, you need to be ready for curveballs at any time. If clients make requests to add a large video or a carousel of 10 hi-res images, you need to be prepared to have candid conversations with them. Tim Kadlec guides us on these compromises: “If [the new feature] exceeds the budget, you have three options: 1) Optimize an existing feature or asset on the page, 2) Remove an existing feature or asset from the page, [or] 3) Don’t add the new feature or asset.”
Collaborate with your developers to help determine the best course to take. Having conversations early and often with your team will help point out any red flags for performance and allow you to iterate on potential solutions. At worst, you have to be willing to pull a little from other elements on the page—but it’s a great exercise in hierarchy. Don’t be married to specifics, and be willing to talk through the best solutions, both visually and for performance.
If you want a large hero image or video, you may need to cut down on the number of typefaces in use. You could design with only one display face and keep a system font for body copy. Depending on your icon usage, you may want to consider SVGs over icon fonts. Making these seemingly little decisions early can yield huge payoffs toward the end of a project. Focus your energy and budget on the specific components and modules you want to shine, and the rest of the page will fall into place.