Last month I spoke at the Conversion Conference, and after my talk I met a developer who had been tasked with single-handedly making her company's site faster. We talked for quite a while, and she expressed good-humored frustration at the vagueness of this directive.
Some of the things we talked about:
What does "faster" mean?
Who defines "fast" within an organization?
How do you know when the site or app you're building has achieved mythical "fast enough" status?
And how do you respond when the same people who tell you to make the site faster are also adding images, features, and scripts that are killing performance?
Today I'm going to try to answer these questions... and hopefully help lay to rest any anxiety you've been feeling if you've been given a similarly vague directive.
What's the ideal page load time?
Depending on whom you ask, you'll get a different answer...
Usability expert Jakob Nielsen has been testing people's reactions to varying response times since 1993. The results are unchanging over the years: load times of 1oo milliseconds or less give us the most satisfying illusion of instantaneous response. This illusion is crucial to maintaining "flow" -- a task state of maximum productivity coupled with personal well-being. ("Flow" is a concept popularized by psychologist Mihaly Csikszentmihalyi, who explains it really well in this TED talk.)
Google has been pursuing a slightly less aggressive -- but still ambitious -- goal of pushing that pages should render in 1000 milliseconds or less. This is largely driven by the need to serve faster, less bandwidth-intensive pages to mobile users.
User surveys are interesting, because they serve as a barometer of what people believe they want. For instance, according to one Akamai survey, 47% of consumers expect web pages to load in 2 seconds or less.
Similarly, if you ask the people responsible for creating and maintaining websites how fast they think their pages should be, you'll get a mixed bag of responses. In this thread on a discussion board for marketing professionals, one commenter said that "I myself wouldn't consider it very important. Granted if page is too slow it's loses users, but I believe if page is loading in 5 or 6 seconds it doesn't make much difference
There's no single right answer
That's because there's no one-size-fits-all number that applies to every user and every website. Your own patience threshold varies throughout the day, depending on whether or not you're in a hurry, how tired or hungry you are, what kind of site you're on, how distracting your environment is, and countless other variables.
Here are a few examples to illustrate the variability of user expectations...
People are more willing to be patient with specialty sites than with sites selling general merchandise.
We looked at data from two ecommerce sites: one of which sells specialty goods and the other of which sells general merchandise. As the graphs below illustrate, when pages slow down, both bounce rate and conversions suffer much more for the general merchandise retailer than for the specialty shop.
People are more patient at some points in the sales funnel than they are at others.
Looking at more real user data, we can see that for a typical ecommerce site, the conversion rate drops by up to 50% when the load time for "browse" pages increases from 1 to 6 seconds:
But looking at the same set of user data, we see that the impact on conversion rate is much less when checkout pages degrade in speed:
Visitors in some countries are more patient than visitors in others.
Breaking down user data by geography, we found that, when faced with slower load times, people in Australia were much less likely to bounce than visitors in the US.
Sometimes, making the user interface TOO fast is a problem.
Admittedly, this is so rare that I hesitate to mention it, but according to Jakob Nielsen, about 1% of the time the user interface is too fast. In the example that Nielsen cites, UI elements loaded so quickly that the user didn't notice that they were still loading as she tried to interact with the page. As a result, she repeatedly clicked on the wrong page element as her intended target kept moving.
The Sophie's choice of performance optimization
All the examples I just cited serve to illustrate that, while having the goal of making every page as blazingly fast as possible is simple and makes you feel like a performance superhero, it may not always be necessary -- or even helpful. If, for example, you know that your Australian shoppers don't seem to care whether pages render in 2 seconds or 5 seconds, why invest in optimizing pages for that audience, when you'd be better served by investing in your much less patient US shoppers?
Yes, there's the idealistic, altruistic argument that we should serve the best, fastest user experience to all visitors. But sometimes you have to make a Sophie's choice about where to invest your limited resources. You need data to help drive those hard choices.
So how do you determine what's "fast enough" for your site?
The only way to answer the question "how fast is fast enough?" is to come up with a set of metrics for "fast enough" that work for your company and your visitors. Here's a quick guide to getting started.
I've read scores of case studies about the impact of performance on business and user experience metrics for great companies, ranging from retail mega-entities like Walmart to smaller "mortal" companies like Smartfurniture.com and Edmunds.com. I love these case studies because they shine tons of light onto the business value of performance. But none of these case studies shine light on your website and your visitors. That's why you need to collect and analyze your own user data.
The best tool for measuring (and then proceeding to the next steps: correlating and monitoring) your website's performance is a real user monitoring solution, which gathers data about every user who visits your site. In addition to the usual page metrics -- such as load time, etc. -- real user monitoring can teach you a great deal about how people use your site, uncovering insights that would otherwise be impossible to obtain. There are a number of paid and open-source RUM tools on the market, though I'm partial to mPulse. 😉
Next, using your real user monitoring tool, you need to graph the correlation between load time and whatever business/user experience metrics are relevant to your business. These can include: bounce rate, conversion rate, revenue, order value, and time on site, to name just a view.
Here's a sample histogram, which shows the distribution of converted and unconverted users across load times. It also shows the conversion rate for each cohort of users who experienced each load time.
Using this graph, it's easy to connect the dots and define the performance sweet spot. For example, if your goal is to convert at least 2% of your site's traffic, then your performance sweet spot is between 1.9 and 4.2 seconds. The highest conversion rate -- 2.4% -- correlates with an average load time of 2.5 seconds.
If this were your site's data, you could then create a target: all pages must load in 4.2 seconds or less. You could then set an alert within your real user monitoring tool, which flags you every time one of your pages exceeds this target.
This is a very simple example. Your targets and alerts can be much more nuanced than this, if, for example, your RUM data tells you that some pages and geographies are more sensitive than others to performance issues.
Your performance sweet spot isn't a fixed target. It will fluctuate. You need to monitor user behavior constantly, noting how correlations change over time and adjusting your targets accordingly.
4. Don't forget to issue high-fives!
This relates back to the conversation I had with the developer at the conference. If you've been given an ambitious task with no clear goalposts, how can you be expected to know when to celebrate your performance wins? This is the kind of frustration that leads to developer burnout -- which is something you need to avoid, both for yourself and for the people on your team.
(Side note: Lara Hogan, senior engineering manager at Etsy, has an awesome habit of celebrating personal and team triumphs with doughnuts. If you're not into doughnuts, that's okay -- find another way to celebrate.)
Takeaway: Don't kill yourself any more than you have to
Faster is better. It's the mantra of everyone in the web performance community. As a staunch user experience advocate for almost two decades, I find it extremely weird to even find myself saying this, but sometimes it's okay not to deliver the very fastest user experience.
I know, this flies in the face of our idealistic drive for UX perfection. (Believe me, this is at least as hard for me to accept as it is for you.) We're all perfectionists, and we'd all love to deliver sub-1000ms pages to all our visitors. But this is the real world, and you don't have the time or money to optimize all the things. You need to identify your fast-enough performance sweet spot and optimize for that. Trust me, that's hard enough.