Designing for Performance: Weighing Aesthetics and Speed

I finally read Lara Hogan’s fantastic Designing for Performance: Weighing Aesthetics and Speed over the past couple days. It’s a fantastic read, along with Scott Jehl’s book Responsible Responsive Design should be read by pretty much everyone working on the design and front end of sites today since performance is such a crucial element of our work.

Lara’s style of writing is wonderful. From the moment you start it doesn’t feel like there are any wasted words, no faffing about in this book, just right into the meat of the content. I also particularly enjoyed the way the content was broken up into such small bite sized sections. It made it easy to see where she was going and it will make this a great reference in the future when I’m trying to remember exactly what she said about a particular tool or technique.

So, if you work on the web, get on it, read this one. It’s full of advice, tools, and techniques that I know I’ll be going back to again and again as I work on client projects. I read the epub version of the book and my highlights are below.

Culture change is perhaps the hardest part of improving a site’s performance. (p. 18)

A thorough cleanup effort is incredibly important for both your HTML and CSS, followed by optimization of any web fonts used on your site. (p. 20)

Focusing on creating clean, repurposable markup and documenting any design patterns. (p. 20)

The impact of page load time lasts even beyond the initial poor experience; users instinctively remember how it felt to browse that site and make choices about how often to return or use it afterward based on their experience. (p. 30)

This means you really need to prioritize performance as you optimize your site’s design for mobile devices, as page load time has a significant impact on mobile users’ experience and how they choose to use your site. (p. 39)

One of the great parts about focusing on performance benefits for mobile users is that these optimizations will also benefit your users who visit your site on any kind of device. (p. 40)

Many of the optimizations that improve page load time also improve device energy consumption, further improving the user experience. (p. 43)

…[R]esponsive web design is a huge opportunity to insert performance considerations into the design workflow. (p. 45)

The decisions made by designers are what typically drive the rest of how a website is built. (p. 46)

On one site, I was able to cut page load time in half by cleaning CSS and optimizing images, normalizing site colors, and carefully reorganizing assets in an existing site template. Rather than redesigning the site, I simply focused on killing bloated HTML and CSS, which resulted in smaller HTML, CSS, and stylesheet image file sizes. (p. 51)

Performance is a shared responsibility, and everyone on your team impacts it. (p. 52)

The sooner you can begin to get visible content on the page, the quicker the page will feel to your user. (p. 71)

It’s good to focus on how quickly your users begin to see and be able to interact with content rather than focus how long it takes for the browser to completely finish loading your page’s content. (p. 74)

It’s important to share this knowledge with others. (p. 163)

…[W]ho contribute to the site so that you are not a sole “performance cop” or “performance janitor.” Helping others understand their impact on page load time will be as beneficial to your image directory as it will be to your stress level. (p. 163)

The important part is to be deliberate with your image creation and make choices about performance as you go. (p. 165)

Though older sites tend to suffer from multiple designers or developers editing and adding to markup, even newer sites can benefit from a clean sweep—looking for embedded or inline styles, unused or unnecessary elements, and poorly named classes and IDs. (p. 168)

Be ruthless when eliminating any superfluous or outdated HTML. There’s rarely a good “just in case” reason for keeping unnecessary or convoluted markup; it’s often better to kill it and know that, if you really need to, you can reference it in the future using version control. (p. 169)

…[Y]ou’ll be able to accomplish a lot with a solid, lightweight HTML hierarchy. (p. 172)

However, grids and frameworks come at a cost. Because they are designed to cover a large number of generic use cases, they will include plenty of things that you don’t need on your site. This extraneous content can be a hindrance to your page load time rather than an aid to your development time; if you’re not careful about how much is included as you start implementing a grid or framework, you could have a lot of unnecessary assets, markup, or styles loaded on your site. (p. 180)

Look for these kinds of opportunities to normalize and create patterns. Presumably these elements share the same look and feel intentionally; as one element’s design changes in the future, you’ll probably want the other one to change in the same way. Combining them to define their shared styles will help save you development time in the future, and the shorter CSS file will help you with page load time now. (p. 190)

Focus on keeping any mixins (reusable style blocks that are defined once) as efficient as possible, and be sure to watch the output of your stylesheets over time. Bloated files can sneak up on you, and it’s good to routinely and continually check on your CSS efficiency. (p. 198)

Be thorough in your documentation while keeping it intuitive. (p. 221)

Repurposable patterns save page load time as well as design and development time. As your site’s design changes in the future, it will be even easier to update all the instances of a particular pattern, because they will share the same assets and styles. The more patterns are repurposed, the higher the chances are that the styles and other assets will already be cached, the shorter your stylesheets will be, and the faster the site will load. (p. 221)

Try to eliminate as many third-party scripts as possible. The fewer requests you have, the better your page performance can be. Attempt to combine and condense scripts; you can often do so by replicating, optimizing, and then hosting a third party’s script on your own site. (p. 227)

Many creators of responsive sites are already going above and beyond in their decision-making process: reflowing content, choosing to hide or show various elements, making smart decisions about hierarachy, and more. We need to build an additional step into this responsive web design workflow: ensuring that we are delivering only the necessary content in terms of page weight and requests, not just information architecture. (p. 236)

By being intentional in your approach to designing a responsive site and deliberate with what kinds of assets you require your users to download, you can build an excellent user experience that performs well regardless of screen size. (p. 237)

…[I]f you want to hide an image from displaying with CSS in a responsive design, you can try hiding the parent element of the element with a background-image…. (p. 246)

sizes is smart because it will look through each media query to see which applies before figuring out the correct image to download. (p. 253)

With this list of images in srcset and list of display widths in sizes, browsers can pick the best image to fetch and display to your user based on media query and viewport size. (p. 254)

One additional consideration you can make in your responsive design is to load your custom font file only on larger screens. This is something we do at Etsy, as we would rather save our users from downloading the extra font file overhead if they’re on a mobile device. (p. 255)

Building performance into project documentation, taking the time to look at your site from a mobile-first perspective, and figuring out how you’re going to measure the performance of your site across media queries will help you to create a speedy, responsively designed site. (p. 257)

The mobile experience shouldn’t be bare-bones. It should be a deliberate experience; designers and developers should use the benefits of, and be cognizant of the limitations for, each platform their site will be rendered on. Mobile isn’t just an add-on to desktop, and desktop isn’t just an add-on to mobile. Content parity doesn’t mean that each platform’s experience should be identical. We should be designing and developing with our users’ needs in mind. (p. 261)

You can also test this manually. Emulate a device using Chrome DevTools and use the Resources panel to see which image size is being downloaded for that device. (p. 264)

As you design your responsive site, be deliberate about which assets are downloaded by your users. Develop a performance budget at each breakpoint and use a mobile-first approach when designing and developing the site. (p. 271)

Be sure to routinely audit your major pages and find those performance surprises. (p.298)

Keeping an eye on performance can be a meticulous task, so you should try to automate this data gathering and create alerts when major changes happen. (p. 302)

…[C]elebrate with an alert when there’s a huge improvement in performance and thank those responsible. (p. 303)

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. (p. 307)

However, limiting the responsibility of performance to a small group of people will make it nearly impossible to keep the site’s speed under control, particularly as the site ages, changes, and is worked on by new people. (p. 327)

Everyone who works on the site should buy in to the importance of performance and understand what they can do to improve it. (p. 329)

Very Important People who care about performance will help you dramatically shape your organization’s culture. (p. 334)