Design for Speed

A fast website is not simply a marvel of engineering. Speed can be designed and is an integral, yet under-appreciated, part of our practice.

The homepage of Some Random Dude as of today is 39.6Kb spread across 5 requests (13.1Kb and 2 of those requests are Google Analytics). Over 30% of pages sampled load in 1 second or less. 74.5% of pages sampled load in 3 seconds or less. These numbers increase dramatically when you restrict the sample page loads to countries with high broadband adoption. This site performs this way not because of a plugin I installed or the server’s Apache settings (although they help). It performs this way because of tough decisions made in the design process. This site was designed to be fast.

Why Speed is Important

Speed on the web makes experiences more fluid and natural. The breaks between pages creates a break in experience. In fact, speed often has a greater impact on experience than what is typically focused on in design. Page loads are more important than ever when considering mobile devices. A 500Kb page size may be annoying on desktops, but it can prove unusable on mobile. Responsive design is not just about fitting a website nicely in a smaller screen. It is also responsive to bandwidth, lower computing power and other less celebrated constraints.

Tips to Shape Your Thinking

1. Consider time as a core dimension of user experience

Speed has traditionally been considered a problem for engineering and all but ignored by most designers. However in many cases, design can make or break the performance of a site before a single line of code has been written. For that reason, the temporal experience (e.g., page load speeds, app performance or anything else that impedes the fluidity of an experience) of a product needs to be considered foundational to the practice of interaction design. This means that if a site loads/performs slowly based on its design, the design was unsuccessful.

2. Understand how design can impact speed

Grasping the basics of design’s impact on speed is simple, but digging into the nitty-gritty is quite difficult. The basics are obvious: large files and many requests will take more time to download. Anything delivered to the user takes time. The challenge is uncovering the less obvious, such as avoiding expensive database queries or CPU-intensive tasks (on both the server and client side). The main takeaway is that anything added has an impact. The goal is to take a preventative approach towards the basics and to work closely with your fellow developers to avoid the less obvious.

3. Determine where speed resides in the hierarchy of experiences you’re designing

Every experience designed has a hierarchy of needs that must be met. Those needs may shift in order based on the product’s focus on the people you are designing for. The design process is often an exercise of balancing all those needs appropriately. While speed may not always be at the top of the list in needs, it always fits into the equation. Understanding the importance of speed in the experience will help you make informed compromises and stands.

4. Make every element justify its existence

Designers already know that every pixel on the screen needs to be accounted for, every interaction justified. That same approach should be taken towards speed. Each request, byte and query added should be intentional and markedly improving the experience. If not, it should be gone.

"What would you say you do here?"

5. Treat bytes like pixels

It’s great to see an increased attention to craft, simplicity and a pixel-by-pixel focus to interface design. That same tenacity towards perfection of aesthetic and reduction needs to be directed towards performance. This means hand-optimizing your images, cleaning your HTML, CSS and Javascript. Make your sites pixel-perfect and byte-perfect.

More Concrete Tips

1. Write framework-less Javascript

Javascript frameworks are useful in many circumstances, but there are used far too often for unnecessary tasks. 90 percent of blogs do not need jQuery or any other Javascript framework (either because of their overly-narrow application or because the functionality it is being used for is inconsequential to the core reading experience). Writing bare-bones Javascript is a pain, for simple Javascript functionality, it is well worth it.

2. Think twice before using custom fonts

For far too long web designers could choose from only 5 or 6 fonts. Now, the opportunities are endless—and people have gone crazy. Just because you can use any font doesn’t mean you have to (or should). Besides, we use way too many fonts. There should be a marked improvement to the experience through the use of custom fonts to justify their application.

3. Kill your social media buttons (with fire)

Let’s be honest, social media buttons are not helpful for users. Facebook/Twitter/StumbleUpon buttons create an extra 2-3 requests each, which ads up quickly. At the very least, you should be tracking how often people actually interact with those buttons. Those added requests better be carrying their weight. They add visual and temporal noise. Unless the core use of a site is to share things on social networks, those types of things are suspect at best.

The points laid out are not too far removed from what is typically prescribed for effective design. The difference is that normally designers talk about stripping away elements and features for the purpose of simplicity in interaction. Those same practices of refinement and reduction can yield equally worthwhile results in creating more fluid web experiences.

11 thoughts on “Design for Speed”

  1. P.J.
    This is a great post and something I struggle with on many wordpress blogs. Speed is a killer when trying to balance form, function, and marketing. In marketing I include an element of Social Proof where the Facebook and Twitter widgets come into play. People lower their defenses a bit when they see their peers or others have liked a page, or see that the owner of the site tweets on a regular basis. So I agree each of the widgets or add-ons must justify themselves accordingly. But where is the balance for non-developer power-user types like myself. I go out and buy WP Themes and optimize them as best I am capable. The challenge is getting the design for speed message out enough to find a midpoint for all of this.

    GREAT Post!!

  2. Good point Jimmy. This theme is open source for a very specific reason – I wanted to offer up a theme that was designed specifically for performance. A lot of available themes are by nature slow, which makes optimizing them an uphill and relatively futile process. So part of the process is to start with a theme that performs well.

    Beyond that, the next best thing is to do no harm. This means strictly limiting your wordpress plugins, the amount of images you use and the amount of content you display at one time. That can go a very long way.

  3. regarding:
    >4. Make every element justify its existence
    >5. Treat bytes like pixels

    while you compress html source, why do you keep w3tc comments?

    why do you keep so much post classes:

    do you use tags to beautify post page? can’t see them anywhere

    also you don’t need this line any more
    _gaq.push([‘_trackPageLoadTime’]);

    you don’t need hgroup in main header

    you dont need header at all in  http://html5doctor.com/avoiding-common-html5-mistakes/

    you have h1 twice on this page – one for blog name, another one for article title

    you use “span-3” for sidebar which is overwritten by #sidebar with the same value of 215px…

    do you need id’s like menu-item-9680 for menu li’s wp_nav_menu -> wp_get_nav_menu_items and do it pixel by pixel 😉

    ok, i got the message but showing your ultra light personal blog theme as a performance masterpiece, while you dont have any constraints regarding features or layout is not a good example.
    show me the same approach on real life example.

  4. actually why don’t you use these rules on http://seabrightstudios.com/work/asics ?
    media css as a separate files? don’t you know that they’re downloaded anyway and you should simply put them in one big css file with media queries?

    http://seabrightstudios.com/about
    section.john { display: none } but images are still loading…

    still, nice article.

  5. @Rushan – I don’t know actually. I would certainly hope not, that seems like a serious conflict of interest on Google’s part…

    @lury – Good points. The site is still in beta and a lot of the things you brought up have actually been fixed in the latest commit (which I should be pushing live today). Also, keep in mind that this theme is open source and intended for public use, so I need to straddle the line of über optimized and usable for others.

    As for Seabright, that’s a whole other story, we just relaunched out website and haven’t had the chance to do an optimization pass on it. Although I don’t think that example is any reflection on me or this blog post.

  6. Some good tips, as @Lury mentioned above, it’s really easy to implement these things on a personal, text based blog theme.

    It’s a shame seeing sites such as the Seabright one mentioned being launched without even a cursory “optimisation pass” being done. That strikes me as an odd thing to miss out when developing a site as these sorts of optimisations should be done as you go along. 

    Good advice though!

    J.

  7. Regarding social buttons:

    To reduce the load time but keep the buttons it’s possible to provide a standard link to twitter without using any javascript to share something:

    http://twitter.com/share?text=urlencoded%20string

    For Facebook we simply link to our page with a button asking them to like it when they get there.

    I might be that neither of these is particularly slick, but swapping them for the JS buttons these sites provide took us from a load time of just over 3s to just under 1s.

    1. Really good point Lewis. I’m considering doing something along those lines for this site. No extra requests are needed to enable readers to post content to Twitter…

Leave a Reply

Your email address will not be published. Required fields are marked *