Performance As Design

Too often, any talk of web performance quickly ventures into the land of heavy geekery. Terms like DNS lookups, Gzipping, minifying, far future expires headers, caching, ETags and more are thrown around and consequently lose the attention of most non-techy people. This perpetuates a mentality that performance is solely a technical concern that only developers need to concern themselves with.

It’s time for us to treat performance as an essential design feature, not just as a technical best practice.

We all feel it

From time to time I get asked what I do for a living. Whenever I mention that I work in mobile, I’ve had people immediately react FACEBOOK SUCKS!

Why such an immediate, visceral reaction? They aren’t reacting to the intuitiveness of Facebook’s navigation, nor questioning the elegance of the Timeline redesign. The whole Facebook clusterfudge had everything to do with the fact that their app was slow as shit.

Facebook App Loading

The average web page is increasingly obese. We now have more toys to play with, and that means more potential to do damage. Phil Hawksworth brilliantly called out the ridiculousness of these gratuitous, parallaxified websites:

Grolsch Website Slowness

If your website is 15MB it’s not HTML5, it’s stupid. Christian Heilmann

While these sites may be visually arresting (though for a lot of them that’s certainly debatable), a good many visitors will never stick around to see them. 74% of mobile web users will leave a site if it takes longer than 5 seconds to load. That means you have 5 seconds of someone’s time to get them what they want, or they’re gone.

Good performance is good design

The road towards better performance doesn’t start with developers or technology stacks (though I’m certainly not suggesting those things are unimportant). It begins with a shared interest on everyone’s part in making a product that’s lightning fast. Some things to consider:

  • Include performance in project documents—Statements of work, project proposals and design briefs should explicitly and repeatedly call out performance as a primary goal. “The goal of this project is to create a stunning, flexible, lightning-fast experience…”
  • Get designs into the browser as soon as possible—A picture of a website design comp hanging on a wall may look purdy, but it’s a terribly unrealistic way of gauging how effective the design will be once it exists in its final environment. As we enter The Post-PSD Era, we’re able to see performance implications of a design direction much sooner than a traditional waterfall process.
  • Test on real devicesStephanie Rieger properly states that it’s impossible to gauge a design’s performance in a shrunken viewport or emulator. It’s essential to test and test early on real devices to see the true ramifications of every interface element you introduce into your designs.
  • Collaborate—Developers should be involved early on in the design process and should call out potential performance concerns in wireframes and comps. It’s important that this process isn’t just a yes/no grunting match, rather a truly collaborative session between disciplines.
  • Educate—Many people in the design process simply don’t know a lot of performance consequences of their design decisions. Help them understand that including five font faces is going to do some damage. Help them think twice about adding tons of massive images. Do a quick prototype in Codepen to demonstrate an idea, then sit together and use it on a real device on a 3G connection.

Ultimately performance is about respect. Respect your users’ time and they will be more likely to walk away with a positive experience. Good performance is good design. It’s time we treat it as such.


  1. Here here!

    Two of my favourite performance presentations/articles in recent times are from

    – Chris Coyier:

    – Harry Roberts:

    Also this was a MAJOR focus point for many of the clever folk we interviewed about responsive design over the christmas period (yourself included).

  2. @Justin Avery: Thanks for the two links! Really nice stuff in there, I really appreciate it.

    @Brad Frost: Thanks for the post! Sadly the technology side of the implementation often ruins everything. There are two many folks out there who produce 10 JavaScript requests because they need 9 jQuery plugins.

    There should be an easy way for people to see that a website is slower than it should be. That would lead to more awareness and developers / agencies would care more about what they deliver to a customer.

    Currently the customer just assumes the slowness is “normal”. Nobody will check with web inspector and point out what is wrong.

  3. Another amazing and easy to follow article is from CSS Wizardry:

    A definite must-read.

  4. I like what you are thinking. I’ve found the biggest inhibitor to education is ego. Though I try my best to educate my clients on speed being more important factor for conversion than window-dressing, they often still go for window-dressing.

  5. Well put. Respect is an important thing. Don’t waste someone’s time and they’ll appreciate it on any platform.

  6. Great article! Unfortunately I’ve seen many instances where performance hasn’t been thought about as it hasn’t been implicit in a project methodology (Its slips between the gaps). The other phrase used is “Performance by Design” …

  7. Smitty

    I think you’re saying something worthwhile here, but I’m having a hard time getting past that incredible “visually arresting” pun. It’s just that good.

  8. Jennifer Showe

    Great summary and excellent links. Education and respect really are essential in building a bridge between disciplines with regard to this subject. Technologists have a responsibility to help designers understand that speed and performance impacts user experience and IS an aspect of (his/her) design.

  9. Well put, Brad.

    I think there’s a common misunderstanding in our industry about what good design is. There is a constant struggle between sites that look incredible and sites that function superbly. I believe it’s possible to do both, but it requires that performance be part of the conversation from the beginning—as you state above.

    I agree with Matt Griffin at Bearded (, but can’t help but think the level of design he describes requires all members of the team to be involved throughout the process. This means that big organizations with separated disciplines (most that I’ve talked to) will struggle to achieve “good design” until they’re able to restructure. And, that takes time.

    I love that we’re finally starting to think about the possibilities—and the challenges—of our medium. It’s an exciting time!


Comments are closed for this post. If you've got something to add, feel free to reach out on Twitter.