For the third and final installment of my interview series with the people who make Google Search, I spoke with Johanna Wright, who leads the search project management team. She has worked on search at Google for over six years, leading the Universal Search and Google Instant projects.
In the first installment, I spoke with lead designer Jon Wiley about the design of Google Search. Last week, Google Fellow Ben Gomes explained how Google’s search technology works under the hood. Johanna tied it all together by explaining the most important feature of Google Search: its speed.
ReadWriteWeb: What does Google actually do to make search faster?
Johanna Wright: There are three ways I think of this. The first is the bits. How many bits do you send over the wire? How actually speedy is the results page? Does it load quickly, does it react quickly, and how quickly can we get it to you?
The second piece is actually taking fewer steps. This was the core innovation from Google in the earliest days: Getting the best results actually speeds you up. If you have to go to page two or try another query, that slows you down. Internally, we call this idea time-to-result. You may load up your page faster, but if you have to load two pages, then your total time to get your answer will slow down. So relevance is actually a core piece of speed.
The third is user experience. The simplicity of our UI also speeds you up.
RWW: What is Google’s institutional process for improving speed?
JW: Every quarter, we have latency goals to make the page faster. We also have a latency review of every feature we launch. We have to have a process and a methodology to make sure that everything that goes out the door is fast.
RWW: Why is speed such a priority? What are some of the effects of speed on search?
JW:We’ve done studies where we slowed down the search results page from 100 to 400 milliseconds, and what we saw was a decrease in the amount of search queries. When we slowed down, people searched less. We kept this experiment going, and over time, they searched even less. The first three weeks, people searched 0.4% less. The second three weeks, it was 0.75% less.
Anytime you make search slower, people search less.
There was this fatigue. It’s barely perceptible in your own mind. You don’t know that this slowdown is what’s making you search less.
We kept our control group going, and when we undid this for the people in the experiment, we saw that they were still searching less by about 0.2%. So we were seeing this fatigue. The sluggishness slows you down, and it’s a lasting effect. So it has been baked into our processes [at Google] that we have to keep on making this thing fast.
RWW: As Ben Gomes and I talked about in our interview last week Google users get more demanding of search over time, giving it ever more complex questions as it gives them more complex answers. Is the same true of users’ expectations for speed?
JW: Absolutely. An Akamai study found that, in 2000, people were willing to wait for eight seconds for a page to load. In 2005, they were willing to wait five seconds. In 2009, still three years ago, they were willing to wait three seconds. So all of a sudden, the expectation is much higher.
RWW: How do newer features like auto-complete and Google Instant affect speed?
JW: So, we’re doing the prediction, and we’re giving you instant results. You can see that while you’re typing and then, almost unconsciously, you can just type a little more to get exactly what you want. It lets you get this feedback as you go along and get you the right results more quickly.
Auto-complete is an interesting speed story because it shows the conflict between our belief that just making the experience fast is important and that second component of speed, the time-to-result.
We had this auto-complete on Labs, and it was an awesome feature, and we knew we wanted to launch it. What we saw was a huge decrease in time-to-result. It was a great speed improvement.
So we went to Larry and Sergey and said, “Hey, we want to add this great feature to the Google home page,” and Sergey said, “What? Really? This feels slow to me.”
So we went to Larry and Sergey and said, “Hey, we want to add this great feature to the Google homepage,” and Sergey said, “What? Really? This feels slow to me.”
We had these grueling product reviews at the time where Sergey opened the code, and he looked at the code in front of the team, and he pointed out four or five things that he thought we should be doing to speed up the code. A lot of these ideas were right, and we were sent back to the drawing board.
So we went back for about six weeks to speed this up before we could even launch it. I think that’s a real story for me about how speed is in the DNA of the company. The thing has to be fast in order for it to go out and for us to put our brand and our pride behind it.
RWW: So did those features produce a relatively big change in time-to-result compared to typical changes?
JW: Yes. They were big changes.
RWW: What are some less visible changes that have brought big improvements in time-to-result?
JW: Let me think of a few examples. So, images are slow for a number of reasons. One is that they take some time to load, but another is that they make more connections back to the server.
So one technique that we’ve implemented within the Universal Search team is something that we call “in-lining of images.” Instead of just doing an image source call back to the server, we actually put the bits of the images into the HTML. They load right there within the page of search results, so we don’t have to make another call back to the server.
We believe that speeding up the Web is good for Google. The easier it is for you to get the information you want, the more you’re going to search.
Instant’s fast, and it speeds you up in a lot of cases, except when you have a slow machine. And then we just turn it off and let you issue your query. While your machine may have a fast connection to the Internet, it may not be able to run code on its own very quickly.
Refinements is another one where we’ve removed a lot of steps for you. This is when we give you search suggestions – we call them “related searches” – at the bottom of the page. Our engineers estimated that we’ve saved users billions of hours by being able to tell them a slightly better way to type this in.
RWW: As user expectations of search get higher and technology improves, how will search results change? What does Google want to provide that it can’t right now?
JW: Actually, last night, my dad was just telling me, “Johanna, it used to be that I got everything I wanted on Google, but I’m searching now for this complex situation where these three drugs interact with each other and diabetes.” So he gave me this whole, very complicated health condition that he has.
I said, “Well, I think Google might not answer that because there probably are no documents on the Web about that topic. You need to go to a specialist.” But he was saying to me, “Johanna, Google should have the answer to this.”
That is the expectation people have. So we’re working very hard to figure out how to pool all the information out there and draw connections for people.
One way we think about this here is as an information-[to]-knowledge progression. What really matters in the modern world is that people can make connections between bits of information. What Google has been really great at over the past 12 years has been bringing people information.
Think of a search term as a concept, like the Empire State Building. What we can do is organize a bunch of information around that topic. We can give you pages, we can give you images, we can give you a lot of information. But when we think of converting that to knowledge, well, how can we pull that out?
A baby step there is the height. Google can [now] understand that “height” is a thing, it can understand that the “Empire State Building” is a thing, and it can [produce] the height [as a search result]. I think there’s so much more we can do in this area.
Chart of Akamai results via MIT Technology Review