Google’s unfair performance advantage in Chrome

Google Chrome for Android has a feature that gives Google Search an unfair advantage over its competition. Sure, it’s the default search engine and that’s a huge hurdle to overcome for any competitor. However, Chrome also reserves a performance-boosting feature for Google Search exclusively.

I recently poked around in the Chromium project source code; the open-source foundation for Google’s Chrome web browser. The Chromium project is co-developed by Google, and other corporate and individual contributors. The project is managed and controlled by Google, however. I was looking for something else when I stumbled upon a feature called PreconnectToSearch. When enabled, the feature preemptively opens and maintains a connection to the default search engine.

The preconnection feature resolves the domain name, and negotiates and sets up a secure connection to the server. All these things take time and they must happen before the search engine can receive the users’ search queries. Preempting these steps can save a dozen seconds on a slow network connection or half a second on a fast connection.

This optimization can yield a nice performance boost for Google’s customers. Assuming the connection only requires a trivial amount of processing power and network bandwidth, of course. Setting up the connection early can be wasteful or slow down the loading of other pages if the user isn’t going to search the web.

There’s just one small catch: Chromium checks the default search engine setting, and only enables the feature when it’s set to Google Search. This preferential treatment means no other search engine can compete with Google Search on the time it takes to load search results. Every competitor must wait until the user has started to type a search query before Chrome will establish a connection.

The feature gives Google Search an 80 % head start towards delivering its search results compared to a non-preconnected competitor. It doesn’t matter if a competitor makes enormous investments in networking infrastructure if they don’t compete on the same premises.

The Chromium change logs for the relevant code shines some light on why the feature works the way it does. The following comment accompanied the comment that restricted the feature to only work on Google domains:

“This feature allows us to experiment on Google without possibly creating issues with non-Google DSEs. This will hopefully prevent problems or regressions with other search engines.”

Google worries that other search engines might not be able to cope with the increased number of connections this feature would cause. This is a legitimate concern. An unexpected increase in connections might overwhelm an unprepared recipient. This potential problem doesn’t change the fact that Google is giving itself an unfair competitive advantage.

Chromium could have solved this problem in a better way if they wanted to. Other search engines could opt-in or out through an extension to their OpenSearch Descriptions (OSD.) OSD is a configuration file search engines provide to web browsers that tell them how to set them up as a search provider in the browser. Chrome could alternatively have used a Well-Known URI (RFC 5785) to query the search engine if they want to opt-in or out to preconnections.

I’m sure the Chromium contributors had the best of intentions when implementing this feature. At least, I’m giving them the benefit of the doubt. None the less, this one small feature in Chromium skews the mobile search market in favor of Google Search; at the expense of all the search giant’s competitors.