JetLib News

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.

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 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.

We had to make the homepage load in no slower of a time. We were looking at how quick a person could put their mouse into the search box. So if it took any time for that Javascript to load, and therefore you were slowed down, well, then we couldn’t launch it.

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.

Next page: Ways Google Speeds Up Search Without You Noticing