Sundar Pichai, Google's senior vice president in charge of Chrome and Apps, speaking at Google I/O.
(Credit: Stephen Shankland/CNET)SAN FRANCISCO--It began with a mere toolbar, an add-on that gave browsers a handy Google search box.
That modest project is what eventually led to Google Chrome, now used by 310 million people by Google's tally. It's what got the project's leader, Sundar Pichai, promoted to senior vice president of Chrome and Apps. And it's what led to a very lucrative new source of profit for the company.
Chrome has spread steadily over its three-and-a-half years of public existence. It launched on Windows, extended to OS X and to Linux personal computers in the months afterward, exited beta testing on Android yesterday, and arrived on iOS today. It makes the company money by driving search ads to Google and, less directly, by helping enable online services such as Google Docs.
One particularly nice Chrome attribute for Google's bottom line: unlike with searches that come in from Safari or Firefox, Chrome searches are more profitable. That's because Google doesn't have to share a portion of search revenue through what's called TAC, or traffic acquisition costs -- though Pichai wouldn't comment on whether Google must pay TAC to Apple for Chrome on iOS.
But Pichai did discuss other Chrome matters with Stephen Shankland here at the Google I/O show. Here is an edited transcript of the interview.
Q: Let's start with the big picture: Why build Chrome? Have Google's motives changed since its initial launch?
The genesis was Google was built on the Web. We benefited a lot from the Web. Google search was important -- one of the most important applications ever on the Web. People accessed everything through a browser, and for us it was important for making sure we had an option there.
And this was the time we started writing [Web] apps, in 2004. Gmail came, Google Maps came. We realized that for us to really drive applications, you need a great platform underneath, and in some cases deep integration with the hardware underneath. For us the underlying platform was the browser, and having a say there was very important. We were doing Gears [a browser plug-in that extended what browsers could do] and realized a much more powerful way to influence this was by shaping the browser.
Over the journey of Chrome, I think it's even more meaningful. You are line online, you are on the cloud, but you have a plethora of devices to deal with. Both chrome and the cloud apps we are doing stitch it together to help you live online seamlessly. The browser plays a tremendous role there. It's one of the few products designed to run on all platforms. As a developer...you can give people a shortcut to a browser-based app that you can write once and deploy across your entire installed base.
Well, not exactly everywhere. Even new cutting-edge browsers support different features, millions of people still use IE6. And mobile browsers are different from desktop browsers. How bad is the fragmentation on the Web?
The mobile Web is just barely starting. Chrome on Android shipped for first time ever as the default on the Nexus 7 [Google's new 7-inch Android tablet, built by Asus and revealed at Google I/O]. We launched Chrome on iOS today. I think having the innovation on the mobile Web is just beginning. there's a lot of evolution we expect to see on APIs [the programming interfaces developers use to get the browser to do things like display text with a particular font or take a photo with a smartphone's camera]. I'm very optimistic there.
In terms of fragmentation, there's a positive view and negative view, and I think both cases are true. There are many use cases where I think we're not held back by fragmentation at all. Good companies do whatever it takes to maek sure apps are great and don't hesitate go add features. In the context of enterprises, it's particularly painful because of IE6 and IE7. That's where fragmentation hurts us more.
But at the high end I don't think the fragmentation hurts us at all. A lot of companies throw up a Chrome extension [which runs only in Chrome] and they don't even think about it.
How big is the feature gap between mobile and desktop browsers?
There is fragmentation everywhere. Writing [native apps] for the iPhone is very different from writing for the iPad. The 310 million users of Chrome, there is one version. I would argue it's one of the largest non-fragmented groups out there.
Look at the number of Android devices being sold every day...
We're up to 1 million Android activations per day?
Right. Fast forward -- they all start shipping with a good version of Chromium [the open-source project on which Chrome is based] That's how you solve the mobile browsing problem. It's about to go through a massive step up. I find when I use tablets my Web usage goes up a lot, and [also] when I shifted to this phone [a Galaxy Nexus] with a 4.3-inch screen, high resolution with LTE. Most of the world is not there. Only 5 percent of people have high-res screens with great connectivity. That will be a big driver of the growth of the mobile Web. Then as browsers become more capable -- I feel like smartphones are four to five years old. We are all planting the seeds there.
So you don't see fragmentation as a big issue among browsers.
All mobile browsers are WebKit-based [WebKit is the open-source browser engine in Apple Safari, Google Chrome, and Google's unbranded Android browser]. There is Gecko-WebKit convergence [Gecko is Firefox's browser engine]. You're going to have 100s of millions of users on Chrome, spanning mobile, tablets, and desktops. That is one unfragmented base. That uniformity is probably better than most of the issues across browsers.
Uniformity? One of the reasons you didn't put the Chrome name on the Android browser is because you felt you couldn't maintain the brand promise of speed and compatibility. Now you're attaching the Chrome brand to Apple's version of WebKit.
We don't fork WebKit.
But for the JavaScript engine Chrome uses V8 and WebKit uses Nitro.
We can do a lot more on iOS in terms of our JavaScript engine. We wouldn't have brought it to iOS unless we felt our criteria were met -- would it feel snappy, feel fast, something we can feel proud of. We feel we do.
The world is changing so fast. Chrome has more of a unique value proposition it didn't have three and a half years ago, which is the ability to be a layer that provides a personalized, consistent experience. I already see tweets that it's so great to have Chrome on iOS -- a sense of familiarity with the omnibox [Chrome's combination box for entering searches and Web address], the ability to find your bookmarks and your passwords. That matters.
In a perfect world could you bring the full browser engine to iOS?
Yes.
Are you lobbying for that?
It's how their OS is set up. We have to use WebView [UIWebView is the interface to the Apple WebKit engine that third-party apps use on iOS]. As a developer, you want as much access as possible to write code. Absolutely, we would love to have more of it.
And you can't can't write a full Chrome on Windows RT [Microsoft's version of portable Windows devices that use ARM chips.
Microsoft has made it very clear. It is what it is. With Windows 8 [which runs on more ordinary x86 chips] with Metro we can and we will. Since Chrome is built for the Web, we have a deep philosophy it should reach across boundaries, across devices.
So do you plan a version of Chrome for Windows RT using Microsoft's Trident browser engine on Windows RT, or is that too far from WebKit?
We are a lot more focused on Windows 8 Metro. We will support Chrome in Metro mode for sure
Is Chrome as a project profitable?
At a high level, it is an exceptionally profitable product for us. We don't share the number of employees or break out finances.
Most of the revenue comes from search ads?
Search is an integral part of Google revenue. That's the biggest area. But it is more. When users have been using Chrome, it tends to drive Web usage up, so it's display ads too, not just search ads. And it's a driver of Google Apps. Google Docs offline works in Chrome. Both Chrome and Android bring together a lot of our services, so they have a huge business value for us.
We have barely scratched the surface of the impact of doing Chrome on mobile. Using Chrome increases how much you use the Web.
How does TAC change with Chrome because don't have to share revenue with others that drive traffic to Google?
This is part of the reason Chrome is exceptionally profitable for us. We don't break the numbers down.
Why isn't Chrome the default browser yet on Jelly Bean [aka Android 4.1, announced at Google I/O this week]? I know it's the default browser on the Nexus 7, but you're not saying that with Jelly Bean.
It's a journey. For I/O, Nexus 7 was our focus. Jelly Bean is so new want to make sure. It's a case of two big projects intersecting. We need everything to be stable. Chrome needs to be stable.
To what extent is Chrome a vehicle to help apps?
it's a huge part of it. You can get it, sign in, and you're good to go. You can package it up. In Chrome OS [Google's browser-based operating system], we can go deeper and have Google Drive be your file manager. At a software-services tie-in it offers a more pure, integrated experience. I do think Google Apps with Chrome offers a very integrated experience.
On Android, I find the services very unified. You log in with your Google account when you first get a phone, and then everything just flows in. But on iOS it's a lot more hassle. Will you unify the experience on iOS and will you launch native Google Docs apps?
We will do whatever it take to have a great experience and not be limited. We want to give people the ability to create. We want Google Docs to be really good on iOS, and we'll do whatever it takes.
But will you do that with a native app or with a Web app that runs in Safari, like today?
The architecture of Google Docs is very complicated. I don't think you'll ever see a native app or a Web app. It'll be a hybrid. We do so many things on the server side. I think the phrase "Web vs. native" will blur. You'll see more and more apps that will embrace WebView.
So will we see native Google Docs apps for iOS?
It's a part of Google Drive, which we launched for iOS. Our goal is to expand it.
I see lots of ads for Chrome and Google Apps. What's driving the advertising strategy for that?
The value to having you switch a browser is pretty high. You have to tell someone what it is. We realized that we had an ability to create awareness with advertising and reach more users -- that we could do it in a very disciplined, very ROI [return on investment] way.
You guys really like Native Client and Dart as a way to improve the performance of Web apps, but nobody else in the browser world seems to like them much. What's it going to take to get the rest of the world to see things your way?
Dart is very, very new. Native Client has been around for awhile. We got slowed down with our commitment to make it work on all underlying chip architectures [a project called PNaCl is under way to bring Native Client to ARM processors, virtually universal in mobile phones and tablets]. We always see Native Client as something that'll help fill a gap -- something like Quickoffice, which we acquired, are candidates for things like Native Client. Bulletstorm was using Native Client. Games are using it.
We don't have an agenda to make a lot of people use Native Client. That's not our measure of success. We want you [developers] to write whatever you write and not be constrained by anything, be it performance or lack of APIs [application programming interfaces]. Native Client fills a huge, important hole.
But you have your own apps, too. Google is talking about using Native Client to run 10,000-row spreadsheets. If every browser has Native Client, then doesn't Google Docs work better?
Sundar Pichai, Google's senior vice president in charge of Chrome and Apps, speaking at Google I/O.
(Credit: Stephen Shankland/CNET)Google spreadsheets is a bad example. It's an app that existed in the pre-Native Client era. If somebody were to start from scratch and wrote something like Spreadsheets today, how would they write it? Legacy is always hard, which is why it's hard to take something like Docs, with hundreds of thousands lines of JavaScript, to make it work offline on the client. You have to go retrofit it.
We are in Chrome 20 or 21. Native Client has been in Chrome for one-twentieth of its lifecycle.
When will PNaCl arrive for Chrome on Android?
We don't know. People ask us when [features like] autotranslate will be in Chrome for Android. We have a roadmap and we are powering through.
One difficult thing we do which is under-appreciated is the level of investment to make sure Chrome works on all platforms. The others [such as Microsoft and Apple] are focusing on their underlying OS. It's particularly hard for us because of the security model. It's easy for others to hardware-accelerate, but we have to make sure we do GPU acceleration in a very safe way on multiple OSes, even older ones.
You announced you're selling Chrome OS systems at retail. Do you think it's ready for prime time, and are you selling them in those Chrome Zones to explain what it is so customers don't get any nasty surprises?
We'll have end caps in Best Buy stores to explain to customers what it is. The goal here isn't to get a quick win or quick buck. Every step has to be a positive step, and we are being very patient about it. We have been hard at work for the last year with Chrome OS. We are working at the same frenetic pace. We said three weeks ago we will have Google Drive and Docs offline, and that's what we have today. The whole UI we introduced -- we're evolving it pretty significantly.
When I went to the first Google I/O, there was no Android, but now...
It's the Android show.
Yeah. In the long run, will Google I/O be the Web app show?
I think of it as the cloud show. The underlying technology will be a choice for people. Netflix is a good example. It's a cloud service. It works seamlessly [on multiple software platforms]. The future is cloud apps. As the Web begins to work better on mobile, I think it'll be an increasingly popular choice.
But today there are two big sets of APIs that developers use to write Android apps and Web apps. Will they converge?
I think there will be convergence. Will we have Chrome on Android, so it's logical that convergence will happen. In the ecosystem view, we want to make sure there's a good Google story for our users. This is the history of computing -- there is no one answer, developers need choice. We are uniquely positioned as a company, not to take bets for the strategy as much as to do the right things for the user.
No comments:
Post a Comment