Speed matters. A lot.
Some years into the company’s life, Google’s Sergey Brin told the VP in charge of user experience that they had picked the 10-result default search page because it seemed reasonable. “But we don’t actually know the answer,” he said. So he sent her to figure it out.
Even at this point, Google had millions of requests a day. It is relatively easy to change the defaults for a small subset of the user base for a small amount of time, which generates a surprisingly huge amount of data. This is known now as split A/B testing. After subjecting a sufficiently large group of users to various configurations, they found that, actually, people didn’t want more search results on a page, as evidenced by the fact that, as you increment the default by 10, the returning searches drop off significantly. Even 30 turns out to be too many.
This might run counter to your intuition. Don’t users want more results? Isn’t information a valuable commodity? What about displaying more pages repels users?
Turns out that the price isn’t worth it, for most people. As incredible as it is that Google’s data centers can process a query, generate a result, and build a results page with 30 results, all in about half a second, users tended to not return, or to return less frequently. Yes, a wait of literally a fraction of a second caused a significant drop in traffic. Why? There are many possible reasons, but a big one may be the fact that the first few results of most searches are interchangably valuable. The way Americans search, that is, tends to be for facts. They look in the first few links, and the first one they find a fact in basically ends the search. Intuitively, it makes sense that they would simply want the results quickly. This stands in sharp contrast, for example, the Chinese, who tend to sort through most (or many) of the results, including those that are not necessarily relevant to their query. In this way, the 10-result default stayed in place.
Fast results, of course, are not always the most important thing. You probably won’t notice a relatively long wait for a Facebook request (sometimes as much as a few seconds), for example, but in that case, the wait is worth it: generating a dynamic summation of your friends’ activities (in the news feed, most famously) really takes a lot of work, and sometimes, a lot of time, but users return more frequently specifically because of that feature. So it seems that when you have a feature that is more or less imperative to user experience, a bit of a wait can be worth it. By the same token, if that feature doesn’t successfully drive traffic, you may be forced to consider that this feature is not right for the web at this time.
If you still don’t believe me, consider how many applications you consistently have to wait more than a second, or two at the most, before you can use it. Even if your answer is one (or, unlikelier still, more), you can look around you and know almost for certain that this is the case for no one around you. And when you go onto a website that takes ages to load, you can know for certain that they’ve just wasted all their money. That is an important fact to remember when you think about your site.
