Google tech tweak reveals plan for faster search

It was the kind of detail that only experts in Web traffic analysis could love, but a technical change Google is making turns out to reveal something a lot more people care about: faster search results.

(Credit: Stephen Shankland/CNET)

Specifically, Google is trying out a new way to present search results that uses the JavaScript programming language and the related Ajax interface technology, not just regular HTML, to display the information, Google spokesman Eitan Bencuya said.

The reason: with the Ajax-enhanced search results, JavaScript is used to load the actual search results beneath the unchanging boilerplate above, a tactic that means only the search results need to be loaded on subsequent searches.

"These guys are working hard to make things milliseconds faster. They're always experimenting," Bencuya said.

A few thousandths of a second--trivial, right? Wrong. Google found that shaving a smidgen off the time it takes to show results means that people search more often, and more searches means more opportunities to show search ads.

To provide fast results, Google already uses 700 to 1,000 servers to field each query, so a little speed-up on the browser side of the process can be a relatively cheap way to get an edge.

OK, then, how did this all come to light? On the Google Analytics blog Tuesday, team member Brett Crosby announced a change Google plans to make to the "referrer" code that it passes on to a Web site when somebody clicks a link in the search result.

Those who use their own Web analytics software to observe how their search ads are performing--such as tracking when a Google search sent visitors to their Web site, and what they were searching for when they did--will need to update their software to accommodate the change.

It's an arcane tweak, to be sure, but Alex Chitu of the unofficial Google Operating System blog put the pieces together on Wednesday, guessing that the change had to do with how Google presented its search engine results page.

Specifically, he dug up a March video post by Google's Matt Cutts explaining why a Google experiment in presenting search results had shut off referrer traffic in February.

Bencuya confirmed on Wednesday that the referrer change was indeed motivated by the need to fix the experiment's unintended side effect.

"We made this change so we can continue experimenting with different kinds of test results and not break links in the future," Bencuya said.

He wouldn't comment on plans to bring the Ajax change to a broader set of users.

[Hunnter2k3]

It also saves on bandwidth too.
While it probably won't affect the client end, when they are serving billions of pages, every saving is worth it. (hence their "non-standard" homepage)

I don't know why more sites don't try to create one page for browsing in.
Take Myspace as an example.
It would be so much better to condense the interface to the top of the window, then make the lower half more dynamic.
They have done the first part to an extent, but they never followed through with the dynamic page content.
It could save them massively in bandwidth costs because all they are serving is the information, rather than having to serve the markup as well.
Slashdot has switched over to something like this, could do with some tweaking for some browsers to prevent hanging, but the idea is there.

Obviously, it is still a good idea to have solid markup as well, since not everyone will be running with JavaScript, or even have a browser that can parse it.
Although the latter are a dwindling number now, former sadly increasing because of the insecure implementations
There are many solutions, but they probably won't be implemented for at least 5-10 years... this makes me a sad panda :(

[shootthecops]

this is what i love about google, they work endlessly trying to make their products better rather than forcing lock-in

[t8]

I have to agree.

[Michael_Martinez]

Webalizer users who have been parsing Google referrals by looking for "q=" should not need to change anything.

The Analytics blog post reveals some very interesting information about why Google Analytics seems to be incapable of accurately tracking search referral data. They don't seem to understand how to parse their own search referral strings (or anyone else's, for that matter).

[SankarDatti]

It seems Google is making their search much more faster. It means they can display more ads and get more money. Of course users also happy if they are getting results in lesser time. This is a good idea where Google and users both can will happy in result.

[slecalvez]

Sorry but I don't agree. Search is not only about speed, it's about relevancy. Google should focus its efforts on other things... This is plain stupid.

[Shankland]

Not to leap to the company's defense, but It's not an either-or proposition. Google is spending buckets of money on improving its search results' relevance, too.

[seangw]

I have a few points to make.

First of all I am having a hard time accepting that Google is "just now" realizing they can use AJAX to display their search results on the homepage. This tech has been out for years.

Second, @Michael_Martinez -- any analyzer that looked for "q=" for queries from google referring pages WILL have to change. The referrer will end up being "google.com" as the URL doesn't change. Google may have to help pass a URL parameter or maybe another service to identify the source of a hit to your site.

Finally -- @slecalvez -- Yes, search is about relevancy. However Google's speed is why they are worth so much. Yes, initially it was a big leap in terms of speed over more traditional "more relevent" search methods (the library). When dealing with Google, even if they were to shave just a nanosecond off of search results, the numbers are too large to ignore.

There was a study (I believe at Google) that analyzed the number of hits Google got when it decreased/increased search speed by fractions of a second. The results were quite dramatic (I wish I could cite the source here).