Tim is an independent Web developer living in northern Wisconsin with his wife and three daughters. He is very passionate about the Web and can frequently be found speaking about what he's learned at a variety of Web conferences.
He wrote Implementing Responsive Design: Building sites for an anywhere, everywhere web (New Riders, 2012) and was a contributing author for the Web Performance Daybook Volume 2.
He sporadically writes about a variety of topics at timkadlec.com. You can also find him sharing his thoughts in a briefer format on @tkadlec.
Someone on Twitter recently asked aloud whose responsibility performance was. A few of the responses quickly said “the developers”. This is a typical mindset, but a fundamentally flawed one. Performance is not just a developmental concern, it’s a fundamental component of the user experience.
Our relationship with pages and applications online are made up of a series of interactions. We type a URL into the address bar and wait for the page to appear on our screen. We scroll down the page to find what we want. We expand a toggleable section. We change tabs. We click a link and, once again, wait for a new page to load.
Each of these interactions is a commitment on the part of us, the user. We are offering up our time, even in a minor amount, in exchange for the information we want. Anytime we make an exchange for something, we expect that the return will justify our investment. If you give $30 to a restaurant, you expect the combination of food and service will justify that expense. When these expectations are met, we’re happy.
But what if the food at the restaurant is lousy and the waiter is slow and spills your drink all over you? Suddenly the value no longer outweighs your investment.
This is the same effect a poor performing site has. If there is a sizeable lag while you switch between a tabbed interface on the site, or the pages take a long time to load, or scrolling is janky—you’ll start to get upset and frustrated. The experience is no longer up to your expectations. That site may be easy on the eyes, but if the performance isn’t up to par then your experience suffers.
You can’t make a beautiful site and ignore performance and still consider the job done—it’s a half effort at best. That’s why performance isn’t just the developer’s job: it’s everyone’s.
Project management
Deadlines shift, problems take longer to solve than anticipated: tight timelines happen. That’s reality, and that’s ok. What’s troublesome is what happens to performance in those situations.
Unless performance is given some level of priority, and unless people push for it, it’s very likely to be on the chopping block when time gets tight. Usually the plan is to circle back and optimize later, but that’s a huge mistake.
For starters, despite all the emphasis placed on pre-optimization being the root of all evil, when it comes to a typical project post-optimization is the root of all evil—because so often it doesn’t happen. We make something that looks ok and works ok and say we’ll come back to making it faster later. Then later never comes. There’s always another bug to squash and another feature to fix.
There is also the matter of first impressions. Making performance improvements is important, but if that first experience is slow it leaves a bad taste in people’s mouths. This is something Google learned first-hand when they experimented with delaying page load time for a subset of users. Even with the delay removed, user behavior metrics remained down.
When push comes to shove, we can’t let performance move into the backseat. If we do, we risk jeopardizing the impact of that snazzy new site—in both the short and long term.
Content strategy
At first glance, it seems unlikely that content strategy would be a performance consideration. Frequently the people doing content strategy seem to be as far removed from the process of performance optimization as we could possibly imagine. But content decisions can have powerful, and long-lasting, impacts on performance.
In a recent talk, the NY Times revealed the burden their decisions around content left them with in terms of performance. Since 2004, they had built static pages for their articles—eventually totaling over 1 million. The problem with this is that the way things were handled, these 1 million pages were tied to the markup used when they were created. Updating them was far too timely and costly, so legacy markup was a given. This lead to CSS and JS bloat galore.
In addition, content creators were allowed to drop in all sorts of stuff into the CMS. This meant that there were @imports and inline styles scattered throughout posts. Some JavaScript had to be kept at the top of the page to account for anything that may get dropped within a post. Fundamental considerations for performance had to be ignored because of the way the content creation process was handled.
In 2004, when they started down this road, it’s unlikely anyone considered the potential long-term performance impact of the way they would create, update and store content. And because of that the site was burdened with excess weight until years later when they could finally make the switch back to dynamic pages giving them the flexibility they needed to be able to clean things up a bit.
Design
The design of the site has a significant impact on how it performs. Make the decision to use full-screen carousels, or include 7 web fonts on a page and it’s going to be awfully hard to make that page lightweight. The implications of these sorts of decisions need to be considered early in the design stage, before they become fixed requirements.
Going further, much of performance can be designed. After all, what matters is how quickly things feel for the people using your site.
Consider the popular mobile polling app, Polar. When you create a poll using the app, a temporary local version of the polls is immediately displayed to you. It is indistinguishable from the real thing, and you can even share it and vote on it. Meanwhile, completely hidden from you, the app is busy trying to get the real poll uploaded in the background. This way, if your connection is slow, the experience still feels fast.
Instagram does something similar. When you add a photo, you have to walk through a several step process to add filters and information such as labels and a description. Instead of waiting until all information is entered, Instagram starts to upload the photo as soon as you get past the first step. The result is that by the time you’ve entered all the information necessary, the upload time is going to feel incredibly quick—if not instantaneous.
These aren’t technical solutions to the problem of performance. Though there are technical bits involved, these solutions were designed. Thought was giving to the way these interactions felt—not just how they looked or how they functioned from a technical perspective. The reality is that the actual time it took to complete these operations didn’t change—but the perception of them did.
It’s not about technology
Bad performance online is not a technological problem; it’s a cultural one. Tools are increasing in number and improving in quality. Posts and books are written explaining the tricks and techniques to use to make your site weigh less, load faster and scroll more smoothly. Yet for all this attention, performance online is getting worse, not better.
This isn’t exactly groundbreaking stuff—Steve Souders wrote about creating a culture of performance last December and companies like Etsy live and breath this stuff on a daily basis—but it is very, very important.
If we want to reverse the troubling trend of increasingly bloated and slow sites, we need to attack the cultural and procedural issues with the same fervor that we attack the technical ones. Only by thinking about performance throughout the process can we reverse the trend and start making experiences that delight our users, not frustrate them.