Weighing Aesthetics and Performance

Your site’s overall user experience is made up of so many different pieces: look and feel, accessibility, information architecture, usability, and more. Performance is just one piece of the overall user experience. We can use performance to boost other areas of the site. If you cut down on page weight, you’ll make it more accessible to users on limited bandwidth. If you improve perceived performance, the site will feel better.

However, speeding up your site can have costs. You’ll lose development time that you could be spending working on other areas of the user experience. You may find yourself making sacrifices in other areas of the experience (like the look and feel) in order to improve performance. In this chapter, we wrestle with when to make tough calls about doing performance work, what it can cost you, and when it’s worth it.

Finding the Balance

You now know how browsers request, retrieve, and display content to your users. You understand how different image formats work and what they’re best used for. You’ve thought about the semantics and repurposability of design patterns in your HTML and CSS, and you understand the importance of tweaking load order for the critical path. You get performance. Now it’s time to leverage your new skill set.

Performance is closely linked to aesthetics. Frontend architect and consultant Harry Roberts notes, “it’s not about how nice something looks, it’s about how nicely it works, how it feels. There’s no point designing a nice, shiny, beautiful UI if it’s going to take 20 seconds to end up on a user’s device. They’ll have left before they even got to see it.”

If it were as easy as always following the same patterns and guidelines, maybe more people would be doing performance work today. But unfortunately, it takes tough decision making to do performance well. Thankfully, having all this knowledge about how the Web works will help you make the right choices for you and your site. By understanding the way that JPEGs find areas of a picture to compress, you can make a call about the export quality of that image and whether you should even use the JPEG format. By understanding character subsetting and how the number of requests on a page affects performance, you can make decisions about how many font weights you should call on a page.

Sometimes you’ll make choices that favor performance; other times, you’ll make choices that favor aesthetics. The key is using all the information available to you to make the right decision for you and your site. At the outset of a project, you may find yourself weighing tough choices like those in Table 7-1.

The answers may differ every time, due to new context like the codebase you’re working with, deadlines, the team members with whom you’re working and their skill sets, the look and feel, and more. Table 7-2 shows example decisions made after weighing these considerations.

While doing work for their client Fasetto, Roberts and brand designer Naomi Atkinson made tough calls about when to sacrifice aesthetics and performance. In one case, they wanted to showcase how simple Fasetto was to use, and decided to go with animated GIFs. But, knowing that GIFs (especially animated ones!) can be very heavy, why did they choose to go this route?

• Atkinson was already skilled at making animated GIFs. Roberts and Atkinson recognized that they needed to account for familiarity with tools and development cost as well as balancing aesthetics and performance when making this decision.
• Replacing GIFs with CSS animations would have inflated the size of the CSS, which they were aiming to deliver in a single request. Roberts was focused on the critical path of the site, and wanted to allow the GIFs to render progressively during the page load rather than as part of the critical path.
• Atkinson was able to limit the color palettes of the GIFs to leverage this file format’s compression algorithms. She focused on striking a balance between appearance and file size.

The resulting animated GIFs landed at just under 35 KB, with one outlier at 90 KB. Atkinson and Roberts relied on their performance knowledge to make smart design decisions and deliver the best possible user experience for their client.

When you encounter these choices, weigh:

• The performance difference
  • How many requests would it add or remove?
  • How much page weight would it add or remove?
  • How would perceived performance be impacted?
• The aesthetics difference
  • How would this affect the brand?
  • How would this impact existing design patterns?
  • How would this change affect the overall user experience?
• The operational cost
  • How maintainable is this solution? Will this make the site’s codebase cleaner?
  • Is this team able to contribute to this solution?
  • How much time will this take to build?
  • Is there a benefit to the team in learning this technique? Can it be leveraged on other projects?

It can be very challenging to find a happy medium when you’re weighing this many varied and sometimes oppositional aspects. However, you’re now equipped with an understanding of performance, and you can use this knowledge to make good decisions for your end users. There are some additional techniques you can use to make these choices easier: incorporate performance into your daily workflow to diminish its development cost, approach all new designs with a performance budget, and continually experiment with designs to learn about how your decisions are paying off.

Make Performance Part of Your Workflow

One way to minimize the operational cost of performance work is to incorporate it into your daily workflow by implementing tools and developing a routine of benchmarking performance.

There are a variety of tools mentioned throughout this book that you can incorporate into your daily development workflow:

• Automate image compression as new images are added to your site.
• Use an image resizing service and caching by breakpoint so you don’t need to manually create a new image for every screen size.
• Document copy-and-pasteable design patterns in a style guide for easy reuse.
• Check your page weight and critical path using browser plug-ins.

By making performance work part of your daily routine and automating as much as possible, you’ll be able to minimize the operational costs of this work over time. Your familiarity with tools will increase, the habits you create will allow you to optimize even faster, and you’ll have more time to work on new things and teach others how to do performance right.

Your long-term routine should include performance as well. Continually benchmark improvements and any resulting performance gains as part of your project cycle so you can defend the cost of performance work in the future. Find opportunities to repurpose existing design patterns and document them. As your users grow up, so does modern browser technology; routinely check in on your browser-specific stylesheets, hacks, and other outdated techniques to see what you can clean up. All of this work will minimize the operational costs of performance work over time and allow you to find more ways to balance aesthetics and performance.

Approach New Designs with a Performance Budget

One key to making decisions when weighing aesthetics and page speed is understanding what wiggle room you have. By creating a performance budget early on, you can make performance sacrifices in one area of a page and make up for them in another. In Table 7-3 I’ve illustrated a few measurable performance goals for a site.

You can favor aesthetics in one area and favor performance in another by defining your budget up front. That way, it’s not always about making choices that favor page speed; you have an opportunity to favor more complex graphics, for example, if you can find page speed wins elsewhere that keep you within your budget. You can call a few more font weights because you found equivalent savings by removing some image requests. You can negotiate killing a marketing tracking script in order to add a better hero image. By routinely measuring how your site performs against your goals, you can continue to find that balance.

To decide on what your performance goals will be, you can conduct a competitive analysis. See how your competitors are performing and make sure your budget is well below their results. You can also use industry standards for your budget: aim for two seconds or less total page time, as you know that’s how fast users expect sites to load.

Iterate upon your budget as you start getting better at performance and as industry standards change. Continue to push yourself and your team to make the site even faster. If you have a responsively designed site, determine a budget for your breakpoints as well, like we did in Table 5-1.

Your outlined performance goals should always be measureable. Be sure to detail the specific number to beat, the tool you’ll use to measure it, as well as any details of what or whom you’re measuring. Read more about how to measure performance in Chapter 6, and make it easy for anyone on your team to learn about this budget and measure his or her work against it.

Experiment on Designs with Performance in Mind

The most important superpower you have when doing performance work is the ability to measure its effects. You can measure everything: how much time did it take you to make this improvement? How did it impact bounce rate? Was it worth the aesthetic sacrifice? Better yet, can you compare two options side-by-side and measure what’s better for your users (A/B testing)?

Learn how your decisions are paying off by measuring them. If there’s one thing I’ve learned from years of doing A/B testing, it’s that I will always be surprised. As developers and designers who have gotten to know our user base, we often jump to conclusions and assume we know what’s best for the user experience, rather than measuring how our users are really responding to our choices. If you haven’t been running experiments, it’s time to start.

In an A/B test, you can run two different versions of a page on your site at the same time to different segments of your users. The number of users who see the test will determine how long your site needs to run. By running the two versions concurrently and measuring how your users behave after seeing the test, you can learn how your decisions about aesthetics and performance impact the overall user experience. Read more about how to set up and run experiments in this primer on A/B testing.

I’ve been surprised by the results of performance experiments. For example, there have been times when users react more positively to the addition of font weights, even though it slowed down the page. However, many performance experiments have confirmed for me the power of page speed as part of the overall user experience, like when we added 160 KB of hidden images to a page and saw a 12% increase in bounce rate from our users on mobile devices. If you have a tough decision to make about a design, run an experiment to see how your users really react.

Too often, the “aesthetics versus performance” mentality results in a “designers versus developers” culture. But developers don’t have to be in a silo making performance improvements, and designers don’t have to be on an island making aesthetic improvements. The team can and should work together with a common goal: a great user experience. Harry Roberts, who has teamed up with many designers and clients to make beautiful websites that are optimized for performance, says,

“Now instead of a design team who wants beautiful, an engineering team who wants fast, and a product owner who just wants delivery, you have a whole team who all want to make beautiful, fast products, quickly.”

It’s always going to take a human brain to make these kinds of decisions. Rather than a “versus” mentality, opt for a “What’s best for our users?” mentality. Sometimes you may find yourself ignoring the outcome of an experiment because it’s not best for your users. For example, what if a performance gain results in poorer security for your users? How often do you see a site being a little sleazy in its user experience (like making it all too easy to accidentally spam all your contacts) just to make more revenue? When an outcome of an experiment is better for your business metrics, gut-check it to make sure it’s still great for your users.

At the end of the day, a great user experience is what we’re aiming for. In his blog post “Page Weight Matters” Chris Zacharias outlines an experiment that he ran as a developer at YouTube. The video watch page had climbed to 1.2 MB of page weight with dozens of requests, and Zacharias decided to prototype a version of the page with limited functionality that loaded significantly faster. He launched this prototype, dubbed “Feather,” as an opt-in experience to a fraction of YouTube’s traffic.

The results, as Zacharias says, were “baffling.” The measured load times had increased for these users, even though the page was significantly smaller. The reason? Zacharias wrote, “entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to.”

This is why we do performance work, and why we measure it. Finding that balance between aesthetics and performance requires considering the entire user experience and testing to make sure what your gut says is right. However, it can be tough to get an entire organization on board with this work. It can be difficult to convince upper management that the cost of the time spent on this work can benefit the business as well as your end users. It can also be difficult to get the rest of a design and development team on board with doing this kind of work. In the next chapter, we’ll walk through what you can do to change the culture of your organization to focus on performance.