I’ve previously written about Google PageSpeed Service. In 2011, Google launched it alongside their Make the Web Faster movement. The service allowed website optimizations by caching content on Google’s servers, giving faster response times and a better search ranking because of it.
I pointed out that PageSpeed Service was effectively handing Google your web traffic, and all the information that went along with it. Handling a site’s traffic likely stems from the same raw data desire as Google Fiber1, but it doesn’t appear to have paid off. Why? I think it’s three things:
From a developer’s perspective, every new service or tool is a balancing act. On one hand, the gain can be dramatic, shortened development time, less mental overhead, and higher performing systems. The downside to consider is always stability. New platforms have inherent risk both from a platform perspective — will it present reasonable uptime, will it scale as more people use it, is it dependable — and from a product perspective — will it continue to be offered and what metrics does it need to be a viable long-term product. Normal cash-driven companies can have a simple formula for if a product is viable or not, does it generate profit or is it aiming to generate a profit.2
Google is — at its heart — an advertising company. Lots of people think of Google as a search engine, but its main business is identifying what people are looking for and selling eyeballs to advertisers. Google’s fundamental business model is built around that concept. Successful products and services feed into that advertising machine; unsuccessful ones get cut off.
PageSpeed Service was an attempt to funnel more web traffic through Google’s servers for data collection and analysis. Traffic logs could be analyzed to reveal significant data about users’ browsing habits. What better way to identify patterns of behavior than to collect sites’ data and watch everything?
With that, PageSpeed Service was less successful because developers realized that backing Google is not a solution for the long term. Unless it directly feeds and benefits the advertising business at Google it’s prime to be axed.
Google Product Awareness
Google’s many products make it hard to comprehend the size and scale at which the company operates.3 They are famous for rolling out small projects under alpha and beta banners4 without much applause, but after that, the “sink-or-swim” mentality can hinder adoption, posing a big question to potential users: “Will this service be around in 5-10 years when I depend on it?”
Everyone remembers the Google Reader shutdown and how much of an impact it had, specifically to the non-technical community. Replacements sprung out of the woodwork quickly, but client support and changing habits took a lot of time and headache. By not designing for the long term, Google puts itself in a bad spot between rapid iterations with frequent releases5 and sustainable business models.
None of this matters though. Google isn’t interested in alternative business models, it has one. Advertising.
Culture & Visibility
A product’s APIs are an expression of company politics and bureaucracy.
Source: Jerry Chan
Anyone using Google’s APIs knows what this means. It’s a terrible mash-up of API design. Multiple different levels of authentication, rate limits and dashboards for access — Google’s API design is terrible, and it speaks to how the company is structured at its core.
Having Android, Chrome, and Google Apps, broken out as separate companies with independent potential could go a long way. These products have potential, and unless they are released from the core obligations of Google, it’s unlikely that they will continue to succeed on the same scale as potential competitors.
Not that competition matters to Google.
- October 2004, acquired what would become Google Maps
- March 2005, acquired Urchin to become Google Analytics
- August 2005, acquired Android
- October 2006, acquired YouTube
- April 2007, acquired DoubleClick
- July 2012, acquired Sparrow for Gmail
- October 2014, acquired Firebase for Google Cloud
- February 2015, acquired Softcard for Google Wallet
Wikipedia has a complete list of list of mergers and acquisitions by Google.
Thanks to Katrishia Velez for reading drafts of this post.
Note this doesn’t hold for companies that are not aiming to be cash-flow-positive, e.g. venture-backed companies targeting an acquisition. ↩
Anyone who’s configured an OAuth application knows what I’m talking about, and that’s just APIs, not consumer-facing applications. ↩
The shining example of beta is Gmail. ↩