Tip:
Highlight text to annotate it
X
>>BRIAN O'SHAUGHNESSY: Good morning, everybody.
My name is Brian O'Shaughnessy, I'm on the Google Corporate Communications Team, here
in Mountain View. First of all, I want to thank you all for
taking the time to come down and visit us after a long weekend.
I trust you all had a relaxing Labor Day, as did we.
For those of you who think it was a brilliant marketing communications strategy to release
the comic book, it's O'S-h-a-u-g-- And for those of you who think it was a flub,
it was S-u-n-d-a-r--who is Sundar's name. So thank you again for coming down, and we're
going to do a demo today in advance of the launch.
The Google Chrome product will be available live at noon today.
And Sundar will introduce you not only to the product, but to the team behind the product.
So with that, I'd like to introduce Sundar Pichai, Vice President Product Management
at Google. [pause]
>>SUNDAR PICHAI: Thanks, everyone. So thank you for coming.
It's been an interesting 24 hours, to say the least.
The last thing I expected to spend my Labor Day on was tracking down how shipping works
at Google, how we ship stuff and so on. So hope you all had a chance to skim through
the comic. Just wanted to give you a little bit more
color behind how the comic came about, since that's how most people found out about Chrome.
So Eric Antonow, who leads marketing for Chrome, is a huge Scott McCloud fan.
So for those of who don't know, Scott McCloud is a legend in the comic world,
and he has written some great books in terms of understanding comics--how comics work and
so on. So as we were talking about how best to describe--Chrome
is technically very complex. There is a lot of work that's gone inside
Chrome. And we were looking for a good way to describe
it to everyone else. And Eric started working with Scott and so
Scott was embedded with the team. He interviewed a lot of folks and wrote the
comic, so--which we hope is a unique way of describing what Chrome is all about.
So I want to spend about 10 minutes talking about why we built Chrome, what our hopes
and aspirations are, give you an overview of what we are doing here.
I'll also introduce the team, and the goal is to spend about 30 minutes--we will give
you a full intro and demo of the product, covering both the user experience and all
the technology that underlies Chrome. And we will wrap up and take Q&A.
So--and Larry will be joining us as well, for Q&A.
So with that, let's get started. So, as you can see from the slide, on the
top left, what you are seeing is the homepage of Amazon.com in 1995.
If you look at it, it was very symbolic of web pages around that time.
These were simple html text pages. People just went to these pages to view content.
They were just reading what's on the page, nothing more.
Let's fast forward to today. In 2008, that's Google Maps with Street View.
It's very symbolic of the kind of applications you see on the web today--rich, interactive,
AJAX applications. People are doing a lot more online and the
web has evolved pretty dramatically. This is obvious to most people, but what's
less obvious is that the underlying browser architecture is still very similar to the
origin of Netscape Browser. So the guts of how browsers work is still
very similar. To be very clear, there have been a lot of
tremendous advances in the browser space. A simple addition like XMLHTTP led to many
of the AJAX applications we see today. But--you know--we believe that browsers should
evolve a lot more to keep pace with how fast the web is evolving.
You know--I'm sure most of you spend a lot of time online every day.
At Google, we kind of take it to an extreme. Personally, I do pretty much everything inside
a browser. I run my spreadsheets in a browser; my documents
are in a browser; I collaborate in a browser; all my internal HR applications, my interview
systems, HR systems--everything works inside a browser.
So when you spend that much time in a browser, you start thinking about what are the kinds
of things you could do if you rethought the browser from scratch.
And that was the genesis of Google Chrome. Next slide.
So our approach to Google Chrome was obviously deeply influenced by Google Search.
So let's think about how Google Search works for a minute.
Right, it has a very simple user experience. For most users--very sophisticated users,
like you--use Google, you find it easy and usable.
My mom and dad--who aren't that internet savvy--greatly enjoy the user experience as well.
So it's very simple, yet powerful. The thing that makes it powerful is a very
sophisticated core. So under the hood, we have our infrastructure--ranking
algorithms, servers and so on, which make this experience possible.
So when we built Chrome, we tried to emulate this.
So we wanted to build something with a very simple experience, but something which had
a lot of underlying technology, which made the experience very powerful as well.
So that's how we set out to build Google Chrome. Next slide.
So this is Google Chrome. It has a very simple, streamlined look, which
I will talk about in a minute. The dictionary definition of "chrome"--like
Chrome--it means the borders of a web browser window and includes the mini bars, tool bars,
crow bars, and so on. It's kind of an ironic name for our product.
Why we called the product Chrome--the motto in the whole team, was how do we minimize
Chrome? We used to call it Content, not Chrome--that's
what we should focus on. Our view is that--you know--the browser is
just an application--it's just a tool for people to interact with the sites and applications
they care about. So a browser should not be self-important.
We wanted to make sure people were forgetting that they were using a browser.
So what does that mean? In Chrome, as you can see on top, is a very
streamlined--streamlined chrome of the browser. So we saved most of the space for the webpage
or application you're spending time on. But it goes far beyond this.
Ben Goodger and Brian Rakowski, who are the key leaders on the user experience for Chrome,
will give a complete demo of what I mean by the simple user experience.
In Chrome, we don't interrupt the user at all.
There are no dialogues which pop up in front of you and ask you to do something.
So our goal is that the user should enjoy surfing the web and the browser should stay
out of the way. And Brian and Ben will talk about it in more
detail. In addition, as part of this user experience,
we have dramatically simplified search and navigation, two of the most common activities
you do in browsers today. About 70% of your internet browsing is going
back to things you've seen before. So we have spent a lot of time optimizing
these two use cases. Next slide.
So what's under the hood? So let's talk about what makes this browser powerful and fast
and stable. There are three main components to Chrome.
So the first thing is rendering engine. We use WebKit--which is an open source rendering
engine--which is the same rendering engine which powers Safari--Apple's browser--as well.
One of the most important principles, as we started working on this project, was while
we wanted to give more choice to users, we wanted to make sure we didn't create a
headache for developers. In fact, I was reading some of the comments
on the web yesterday. There were a few comments which were posted
out there, "Oh God, one more browser for me to go and optimize my site on."
We actually wanted to avoid that. So Chrome uses WebKit, one of the existing
rendering engines, so we have not added another rendering engine to the world.
So if you're a webmaster, and your site works in Safari, it will work automatically in Chrome.
Why did we choose WebKit? It turns out to be very fast.
Darin Fisher--who is our tech lead on the underlying technology in Chrome--will give
you a complete demo of WebKit short while. So WebKit turns out to be much faster--it's
a very simple code base and it was very familiar to a lot of Google developers as well.
It turns out that our mobile efforts are also--the browser in Android uses WebKit as well, so
it made a lot of sense for us to use WebKit. The second main component in Chrome--which
is a fundamentally different way to think about the browser--is the multi-process technology.
So let me describe this for a minute. What do we mean by multi-process?
Let's take your desktop as an analogy. In your desktop, you have many, many applications
running. You don't expect, when one application crashes
on your desktop, for it to take your entire desktop down.
That's how most browsers work today. All browsers work as one single process.
So in Chrome, we have tried to bring these good elements into the browser.
We think of the browser as a modern platform for the applications--the web applications
that it's running right now. So in Chrome, each tab--which could be an
application--runs in its own process, in its own environment.
Well what does that mean? It offers three main benefits.
One is it makes the browser much more responsive and faster.
Even if something is happening in one tab, the other tabs stay responsive.
So from a user experience standpoint, the browser--you can continue doing all the things
you are doing in the browser without any slowing down.
So that makes the browser faster. It makes it more stable.
I talked about crashing. In Chrome, if one tab crashes, you can hit
"Reload," and continue working on--you can go back to that page.
You can actually continue and use the other pages.
Your browser doesn't go down just because one application misbehaves.
Your browser doesn't slow down just because one application is slow.
The third thing is it enhances security. By putting each tab in its own process--you
know--we can also sandbox--"sandbox" is a technical term,
but literally, we can take this application--you can think of it as putting it in a box,
shutting all the doors, shutting all the lids and--you know--we strip away privileges, so
the application cannot do harm to your computer. It cannot read and write on your computer,
so it's a much safer browser as well. So the multi-process architecture is one of
the fundamental underlying advantages of Chrome and we were able to do it because we were
rebuilding a browser from scratch. This is something difficult to do if you were
layering this on an existing browser. The third main thing in Chrome is V8.
V8 is a major technological breakthrough in Chrome.
Lars Bak--who led a team in Aarhus--is one of the foremost VM experts in the world,
and he and his team reared a complete new JavaScript engine, from scratch, for Chrome.
So what do we mean by a JavaScript engine? Most web applications are written using a
common web programming language called JavaScript. And your browser needs to execute that for
it to run this application. So Chrome and V8 executes JavaScript much,
much faster than current existing technologies. So it will make your applications run faster.
More importantly, most web developers don't use JavaScript a lot because it doesn't run
that fast in a browser. So with V8, we hope it will not only run today's
applications faster, but it will enable a whole new class of applications for tomorrow.
Lars will talk about V8 in much more detail. So that's the simple user experience and sophisticated
core which delivers a very stable, fast and easy experience for our users.
So a few things--we care about making our products available to everyone.
So Chrome--it's being launched today--it's available for PC, Windows Vista and XP.
We are working very *** Mac and Linux versions.
To be very clear, we had one team, and from this thought, we designed Chrome to be multi-platform.
So Chrome was designed with all three platforms in mind, and you can see--when you use the
product--the look and the feel--you know--makes it work well in all platforms.
We decided to launch the Windows beta version as soon as it was ready, because we wanted
to engage with the community outside and get feedback and improve the product.
But we are working very, very *** Mac and Linux versions--a lot of us inside use
Mac and Linux-- and so there is enough internal pressure to
get this ready on those platforms as soon as possible.
Another thing which is very exciting or Chrome is on day one, we are launching it in over
100 countries and in 43 languages. So--which is unprecedented for a product of
this scope on day one, so we are very excited by that as well.
Next slide. So the final point I want to make is Chrome
is fully open source. So we are end-to-end--all of Chrome is open
source, under a very permissive BSD license. Our intent here is to help drive the whole
web platform forward. As we built Chrome, we benefitted a lot from
existing open source technologies. I talked about WebKit--we have borrowed components
from Firefox as well. So in that spirit, we wanted to make sure
everything we do here is available for others to use and improve upon.
To be very clear--when I say our goal is to help drive the web platform forward--as the
web gets better, that's a direct strategy benefit for Google.
We live on the web; we build servers on the web.
If the web gets better, more people use the web and Google benefits.
We can write better apps--we have evolved from a search company to a search, ads and
apps company--we can write better applications on the web.
So we care about this a lot. So with that in mind, Chrome is fully open
source and today we are announcing Chromium-- which is our open source project and which
will be going live--and the entire code is available for people to use and contribute
to. So with that, I'm going to introduce Ben and
Brian. Ben Goodger is the Tech Lead on the user experience
of Chrome, and Brian is the Lead Product Manager. So they will give you a demo on the user experience
of Chrome. Thanks.
[pause]
>>BEN GOODGER: Thanks, Sundar. So, like Sundar said, my name is Ben Goodger
and I'm a Tech Lead on the user interface for Google Chrome.
So when we sat down to design the user interface for Google Chrome, we--one of the driving
goals, as Sundar said--was to build a really streamlined user experience.
And so when we sat down to do this we thought, "Well, we'll go back to this original premise
for Chrome," which is that it is a modern platform for
web pages and applications. And so we thought how this might impact the
user interface. And what we realized is that what we wanted
to build was not so much a traditional content viewer--with the bulky toolbars and buttons
and all that kind of stuff-- but more of a streamlined thing--more of a
window manager for web pages and apps. And so we developed a very streamlined user
interface, which Brian will bring up right now.
And this is the Chrome window. And as you can see, one of the first things
that we focused on was tab browsing and tabs. And we felt like tabs should be more than
just a feature of a browser, but rather the primary element of the browser.
And so you can see our tab strip was actually put at the top of the window.
So we think of tabs as kind of like title bars for web pages and apps, and so they're
up here at the top. And as we built this functionality--and I
don't know about you, but we use tabs an awful lot--and so we wanted to make this feature
scale really well to heavy usage. And so we've done some interesting things
with the tab strip to make it work well in these cases when you have lots of tabs open.
And Brian will show you some of those now.
>>BRIAN RAKOWSKI: Okay, so let me show you the tab strip.
As you can see, it's up top and we think that tabs are the coolest thing that have come
to browsers in the last 10 years, so we spent a lot of time trying to get them
right and designing the browser around the tabs themselves.
So let me just show you some of the things you can do with them.
For instance, it's easy to select tabs. You can also grab them and drag them.
They're very friendly, they--it's almost like you want to drag them, so--you want to go
ahead and grab a tab-- I can drag it out too, into a new window,
if I want to create a separate window. You can also drag it back in if you want to
consolidate windows, and it's really easy to do--it feels really nice--they're really
grabable and dragable--and very friendly as well.
Like Ben said, there's a lot of really subtle behaviors that went into designing the tabs,
and we tried to design them for people who use tabs a lot.
I'm sure you guys all have lots of tabs open all the time, and we spent a lot of time thinking
about the subtle behaviors that makes this work really well.
So I'll show you one of those--let's say you want to get rid of a couple tabs--so let me
close a few and I'll show you what happens. So here I'll click on the "Close" box--you
can see the next tab slid over and the "Close" box is right under my mouse.
You can close another one really easily too. And this is possible because we don't actually
resize the tabs until you move your mouse away from the tab strip and indicate that
you're done closing tabs. So I'll move my mouse away and you can see
that they resized to fill the available space. It makes it really nice for people using a
lot of tabs and there's dozens of little subtle behaviors in the tabs that make this work
really well.
>>BEN GOODGER: So like Sundar was saying before, another area of major focus for us was on
the search and navigation. And like Sundar said, these are the things
that people do most in a browser, so it was important to us to get this right.
And so the first product feature that we focused on was that typical feature of a web browser,
which is the address bar at the top of the window.
Now if you look at the browser here, you'll see that we have this address bar, but where's
the search box? Is this really a Google browser without a
search box? Actually, yes.
And so what happened when we started off building this product is we did some research into
how people were using their browsers. And it turned out that it was pretty easy
to confuse the two--the search box and the address box--you know--
I myself--I would occasionally type an address into the search box and a search into the
address bar. And so it was a little bit confusing, because
what you had to do as a user was that you had to decide what it was that you wanted
to do before you were going to do it. So we thought to ourselves, "What if we create
just one box that was always the right place to type no matter what it was that you wanted
to type--" like the search box on Google.com--and it
would give you good results? Results that--you know--for pages that you
visit a lot, you would only be maybe one or two keystrokes away from getting to the pages
that you liked. So what we did was we smashed the two boxes
together--the address box and the search box. So this is the address box, but it's also
the search box and we call in the "Omnibox." And to get it work right required a little
bit of magic.
>>BRIAN RAKOWSKI: Let me show you the Omnibox. So as you can see here, it--like Ben said,
it's a little bit psychic in terms of--it's a little bit of magic--a little bit psychic
in terms of predicting where you want to go. So we used to call it the "psychic Omnibox,"
and in fact, our goal as a team was to only have to type
one or two characters into the box before it gets you to where you want to go, and that's
how it earned its name. So let me show you--turns out in this browser--I
like to go to Amazon a lot--I like to do a lot of shopping, so I'll show you the way
that works. I just hit "a" and it knows--it's learned
that I like to go to Amazon--so all I have to do is hit "a" enter and I'm already navigating
to Amazon.com. It's really nice and it's really efficient
and it learns very quickly which sites you like to go to.
You'll have to try it out and see for yourself. The next thing to point out though, is you
don't always want to go to Amazon every time I type in "a."
Sometimes I want to do some research, sometimes I want to do a search.
So let's say I want to do a little--I want to take a vacation after this launch finally
happens. Let's see, so I'll just type "Alaska cruise,"
and everything--like Amazon.com just got out of my way and I just hit enter and now I'm
doing a Google search. It's really easy to do both searches on Google,
and it's also very easy to navigate to URLs. But what about all the other search engines
on the web? We know people like to do a lot of specialized
searches--they like to search Wikipedia and Yelp and things like that--so we wanted to
make that really easy as well. So let me show you the way that works.
So here I'll go to Amazon again--"a," enter--really quick, and it turns out there's a search engine
on this site and let's use it. Let's see--let's search for something by Stephen
King-- and now at this point, Chrome has noticed
that there's a search engine on this page that I like to use.
I didn't have to set anything up, it just noticed.
So next time when I decide I want to go to Amazon, I'll type "a," and low and behold,
there's a little tip here that says, "Press tab to search Amazon.com."
This is my favorite feature of the whole product. It's tough to pick, but this is definitely
my favorite, because it makes it so efficient to do what I want to do.
So here, let's say I want to look at--look for Obama's latest book--I search, and here
I am searching on Amazon.com directly from the Omnibox.
It makes it really efficient and it's no setup; and it's a very easy way to get the answers
anywhere on the web.
>>BEN GOODGER: So as you can see, the tab to search feature is indicative of a design
philosophy that we took when we were building the UI for Google Chrome,
which is that--rather than force the user to have to think about what they want to do
before they start to take the action, and then think of what piece of UI that they
need to invoke for it--rather people should just do what they naturally want to do,
and then if we can help along the way, we'll try and do that.
So another area where we applied this approach was on the new tab page--what you get when
you open a new tab. And basically, what we noticed with a lot
of browsers was that this page is blank, and you're trying to go somewhere, so it seemed
like kind of an untapped resource. When you open the new tab, you can either
type an address into the address box, or you can pick a bookmark or something like that.
So we began to think of what we could offer in this place.
Maybe we could offer bookmarks, but--you know--a lot of people like bookmarks, but also bookmarks
can be--for some people--a little bit of a pain to maintain over time,
and unlike the Omnibox, bookmarks aren't automatic--they don't tailor themselves to suit your browsing
habits. Now if you had bookmarks in your existing
browser, they'll be imported into Google Chrome, but we thought that we might be able to do
a little bit better in what we show in this new tab page, and so that's what we've done.
>>BRIAN RAKOWSKI: So let me show you the new tab page.
I'll click right here to create a new tab and you can see what we've done.
This page is my new tab page. It shows all the sites that I like to go to.
Here are the nine sites that I visit most often and this was, again, configured automatically,
I didn't have to do any setup of my own; it just works.
There's also the search engines that I use most often, bookmarks that I've created recently,
and if I've closed a tab recently--let me do that--it shows up right here, so I can
easily get back to it if I accidentally close it or I decide I want to do it again.
We also have a little area for bookmarks here that you can manually configure and you can
add things here. Having it only show up in the new tab page
is a great way to save space if you don't want to see it on every page.
If you do want to see it on every page, it's easy to dock to the top of your window--I'll
do that--and you see it docks itself there, and now it's at the top of every page--more
like a traditional bookmarks toolbar--and it's easy to toggle on and off and it's kind
of fun to toggle on and off too, so I do that sometimes when I'm bored. [everyone
laughs]
>>BEN GOODGER: That's really cool. In fact, this is one of my favorite--[laughing]--this
is one of my favorite features because the page--you know--it does become yours.
It is the stuff that you do and so, actually our testing of this was pretty successful
and so we've decided to make this the default homepage in Google Chrome.
Of course, if you have a homepage that you really like, we import that as well and it's
really easy for you to choose to use that. Also if you have a particular set of tabs
that you like to start out with, you can choose those, or you can choose to
start with the tabs that you were using last time you used the browser.
So when we were looking at all of these features that we had built that were based on your
browsing history and stuff like that, we realized there was a little bit of a problem,
and that was basically sometimes people--you know--visit sites that maybe they're not comfortable
sharing with other people who might use the same computer.
And if you've been to some site and then it turns out--basically you don't want someone
else to come along and start typing and figure out that you've been there.
So what happens in other browsers, typically, is that people will go in after visiting these
sites and they'll clear out their history. But in Google Chrome, the consequences are
more dramatic because the contents of this page will disappear,
and all of the quick shortcuts that you have in your Omnibox will also disappear and then
you'll have to start again from scratch. So we wanted to come up with a couple of solutions
to this problem, and the first one was to create a new kind
of window, and this kind of window is called an "incognito window."
And any browsing that you do in this window is not stored on your computer.
>>BRIAN RAKOWSKI: Let me show you incognito. So here I'll create an incognito window.
You can see that it looks a little bit different than the other window--it has a little detective
in the corner to help you remember that you're in a special mode.
And let's do an example of something you might be doing incognito--I don't know what you
guys do, but maybe I want to do a little bit [audience
laughs] of research for a friend, of course, who has a disorder. [audience laughs]
So I'll do a little research, looking around trying to find a cure and okay--this looks
like I have what I need now, and just to prove that nothing is remaining
on your computer, let me show you the history view--
you can see the searches that I did for Obama and Stephen King on Amazon.com, but none of
the stuff from the toe fungus search is here. None of the cookies are remaining--none of
the cookies remain in my window--in my browser, none of the cache information--none of that
stuff is still on my computer. To be really clear, incognito mode is meant
to keep information off your computer when you're browsing sites that you don't want
to appear in your browser history.
>>BEN GOODGER: So as you can see, opening an incognito window is really easy.
All of your existing windows and tabs stay open.
It's a nice--it's not an experience that forces you to switch from one thing to the other--to
the exclusion of everything else. So you can just pop one open and browse for
some stuff, and then close it, and then it's like it never happened on your computer.
So another design theme for us building the user interface for Google Chrome, was to try
and create an invisible browser-- a browser that didn't show annoying popup
dialogue boxes that you--asking you to click "Ok," "Cancel," and stuff like that.
And so one area of the product where this focused our design was the experience you
get when you download files.
>>BRIAN RAKOWSKI: So here I'll go--using my bookmarks toolbar--I'll go to a site where
I like to download some files. And we spent a lot of time trying to make
downloads easy. I was really excited about the opportunity
to try to make the download experience work much better.
So here's a site with a lot of downloads, and our philosophy was you shouldn't have
to do a lot of stuff--you shouldn't have to manage a lot of things to make downloads work--
it should just--you should just be able to find something on the web and make it yours.
So here--let me click a few of these and you can see what happens.
They come down into this little bar at the bottom of the page, and you can then interact
with them just as if--just exactly what you want to do--
you don't have to worry about where they were downloaded to, you don't have to worry about
clicking "Ok" on a dialogue, you don't have to worry about where, on your
file system, they went. You can drag them right off of here onto your
desktop if you want; you can drag them into folders--let me do that with this one.
And if you want you can just click on them to open them.
>>BEN GOODGER: And so a final area of focus for us in building the user interface was
on what kind of UI we should provide for these web pages that act more like applications.
And sometimes these are the pages that you can keep open all day long because they're
relevant to you throughout your day. These are things like email and calendar and
stuff like that. And so we went back and we took a look at
the browser user interface, and we thought what we could do for that--for those kind
of applications. And what we realized pretty quickly was that
some of this user interface just wasn't that relevant for some of these applications--
the "Back" and "Forward" button, "Reload", the Omnibox, stuff like that.
You didn't use them that much because you kept them around and you didn't navigate away
from those pages to other pages as much, at least for some users.
And also, some of this UI could occasionally be a little bit dangerous--maybe you're in
the middle of typing something and a box in one of these applications,
and if you click "Reload" accidentally or navigate somewhere else accidentally, then
all of that is gone. So what we realized was that some of these
applications--what they really want to do, is they want to break free of the browser
window. And so we created a new kind of window to
hold them.
>>BRIAN RAKOWSKI: Here let me navigate to one of these apps that I like to keep open
all the time, and I think of as a real app. And here's Gmail, and when we were thinking
about this--like Ben said--they want to break free,
and I think of this as our Pinocchio feature--because Pinocchio really wanted to be a real boy--I
just want this to be a real app--I want it to feel like a real app.
So we have this feature here with "Create application shortcuts--" let me choose that--
and you get a dialogue that lets you choose where you'd like to create these shortcuts.
I'll create one on the desktop and you can see what happens--move this out of the way--here
I have a desktop shortcut and I could launch it just like a real app.
And when I launch it, I get this app view window which doesn't contain all the extra
browser machinery that gets in the way, and can sometimes be dangerous in the context
of applications. You also get a little thingy in your task
bar and you get an entry in your Alt-Tab menu, so it's easy to switch between applications,
just like you're using real desktop apps. It's one of my favorite features also.
>>BEN GOODGER: But we didn't just stop and user interface.
Improving the capabilities of web applications goes right to the core of Google Chrome.
And to tell you some more about that now, I'll turn it over to Darin.
>>DARIN FISHER: Thanks, Ben. So my name is Darin Fisher.
I'm another [sound of microphone bumping; unintelligible] with Google Chrome and I'm
here to talk to you a little bit about what's under the hood.
So given the opportunity to build a better browser, we took a hard look at what we could
do to improve upon some of the core fundamentals of web browsers.
We were interested in how we could improve upon speed, stability and security.
And we are very interested in the use case of users who leave their browsers running
for a long time. We noticed that--you know--I know from my
own experience that I tend to have a lot of different tasks going on at once in the browser.
I might be in the middle of composing an email and then I'm going off to do a search because
I need to get some information for that email-- maybe a calendar alert goes off and that takes
my attention away to what I just doing, and suddenly I've just got a lot of different
things going on in parallel. And it's really unfortunate when, in the process
of going off into some other tab and going to some web page that you haven't been to
in a while, that suddenly, somehow a browser bug--a rendering
engine bug--gets tickled and it's really unfortunate if that results in you losing your whole browser--
or the browser locks up, goes out to lunch, whatever--it's very unfortunate to have to
Force Quit the browser at that point, because you've lost all this work that you
had in progress. So it seemed obvious to us that it sure would
be nice if the browser were subdivided--could be subdivided into multiple processes.
As Sundar said before, when you use desktop applications and one of the desktop applications
dies, you don't expect it to affect your other desktop applications;
and the same should be true of web pages and web applications.
So that's what we did, we built this multi-process rendering engine--or multi-process browser
architecture--that puts the rendering engine down into sub child processes,
and this has many benefits. The obvious one--which is one I've already
been talking about--is stability. You know--clearly if one of the tabs dies,
you don't lose the other tabs and you don't lose the browser itself.
Performance. Well, because these tabs can now execute in parallel, it means that you
can get some very nice performance properties. For free, you get the fact that if one tab
is busy, you can quickly, effortlessly switch to a different tab and do work.
There's no delay, there's no hiccup as a result of the fact that the browser's--one rendering
engine is busy servicing one tab. This is very nice for performance, especially
if you happen to have a newer computer with a dual-core CPU.
Security. There's very--it turns out that there are some very nice security benefits
from this architecture. And security is a very complex topic--there's
many aspects to it. But what we were able to do with the multi-process
architecture is we recognize that--you know--to render web pages doesn't require a lot of
privileges. Normally processes on the desktop run with
all the privileges of the normal user. They have the ability to mess with your files,
to mess with your registry and so on. But to render web pages you don't need any
of those privileges--you don't need any of those capabilities.
So we said the rendering engine process--the process that's running the rendering engine--just
take away all of its privileges. Limit it to the point where all it can do
is talk to the browser. And this has very nice security properties.
It gives you an extra level of protection. We call this technology "the sandbox."
Now the way I liken--like to think about it is for a bad guy to get malware onto your
computer, ordinarily he's just have to find a bug in your rendering engine.
And once he does that, he has access to your computer.
But not in Google Chrome. In Google Chrome, he also has to find a way
out of the sandbox. So he has to first find a bug in the rendering
engine and then find a bug in the sandbox. And so that, we believe, adds an extra level
of security, which is very nice. Okay, so now I'd like to do a little show-and-tell
and have Brian bring up Chrome's Task Manager. So what you can see here is some user interface
that looks a little like Windows Task Manager, and what you're seeing here is a list of all
the processes in Google Chrome. I really love this feature because as a power
user, it gives me the ability to kind of see what's going on.
What do I mean by that? Well, there's columns here for memory, CPU
and network usage. So for instance, you can see that maybe some
process--some tab is actually consuming a lot of CPU--that might be really interesting
to a power user. And the rows here at the top, you can see
the browser process. Below that, in this case, there's five different
tab processes. This window apparently has four tabs, but
there's another tab process used for Gmail, which is currently minimized.
And finally there's even a process for Shockwave Flash.
That's right; we actually put plugins out of process.
We found that we could apply the same principles that give us separation between tabs in the
browser, to tabs and plugins. These are the traditional browser plugins
like Flash, QuickTime, Java and so on. We actually found that we could--we found
that it was very nice if we could have these things out in their own processes so that--
suppose you visit a web page where an advertisement is served using a plugin.
Well, and imagine somehow that plugin misbehaves or encounters a bug.
Well, all you would lose is the plugin--all you would lose that little bit of UI that
was actually dealing with that, and you wouldn't lose the actual activity you were doing.
So this sort of subdividing of processes is very nice and applied to plugins as well.
So now Brian is going to demonstrate the--an example of a tab that's misbehaving and then
he's going to show you an example of a plugin that's misbehaving.
>>BRIAN RAKOWSKI: Okay, so here you can see we have the Task Manager up.
We also have Chrome running here. And let me simulate--let me bring up the bookmarks
toolbar, so I can use it to simulate a hang. Sometimes your browser just becomes unresponsive
due to something that's going on and it gets stuck--it gets frozen--you can't do what you
want to do. So we have a way to simulate that, and I've
just clicked this bookmark, and now I can't actually interact with this page because it's
stuck. I can't click on the links, I'm trying to
click, I'm trying to scroll, I can't do anything. But the cool thing about Chrome in this multi-process
architecture is now I can still switch tabs--I can still interact with all the other pages,
I haven't lost anything. Instead of my entire browser being stuck,
now just this one tab is stuck. And because the browser process is pulled
out separately, like Darin said, I can still close this tab if I want to.
I'm not going to do that though, I'm going to use the Task Manager to do it, just so
you can see how it looks if you were to encounter a hang of its own.
So let me see which one--Google News looks like it's stuck.
You can see the CPU is all the way up because I have a dual-core machine; one of them is
completely saturated. I'll end the process and here we have the
little sad tab. [audience laughs] He's upset because something bad happened,
but I should also say--just like before--I can still interact with the rest of the browser,
nothing is broken. I can close it if I want to, but it's also
really easy to recover. I just hit "Refresh" and I'm back where I
was. And notice that even the scroll position is
preserved. I was scrolled down before, we remembered
that and now it's back to exactly where you were before.
And the next thing Darin talked about was plugins.
Plugins are in their own process. So let me go to a site that uses plugins.
We like to use YouTube a lot, so let me pick a video here that looks interesting.
How about this one? So you can see the thingy's playing.
If you look here, you can see Shockwave Flash is using a bunch of resources--stuff is happening.
Now here, let me try to simulate a crash of the plugin process.
I'll use end process here in the Task Manager, and here you get a little sad plugin, just
like the sad tab-- sort of cute, we needed something to make
ourselves feel better when we encountered a crash.
So here with have this--and again, you can interact with the rest of the page.
You can scroll down--nothing is broken except for that--you can switch these tabs here;
you can interact with everything here on the page.
And recovery, again, is really easy. All I have to do is hit "Refresh," and refresh--it
will reload the plugin and start playing it all again.
So it's very easy to get back to where you were, and it's a really nice way to minimize
the impact of a crash.
>>DARIN FISHER: Thanks, Brian. So you can see it's--you can see the stability
properties for yourself. And so now we want to turn your attention
to another topic--so we're very interested in performance when it comes to Google Chrome,
and as I said, the multi-process architecture gives nice performance--has nice performance
properties if you have a-- you know--because of parallelism.
But we were also interested in raw performance, and raw performance is part of what--a big
part of what influenced our decision when it came to the rendering--
choice of rendering engine. Sundar mentioned before that we're using WebKit
as our rendering engine. We liked WebKit because it's fast.
We also liked it because it's open source and as Sundar said, we really didn't want
to have to make web developers deal with yet another rendering engine.
And so don't want you to just take my word for it when I say it's fast, I want to actually
demonstrate that. So what Brian's going to do now is run a little--a
small little demo of loading pages. He's going to first load it in Internet Explorer,
and this is a very simple demo that's loading static content off of the local file system,
so it's taking IO--network IO--out of the picture.
So you can just see how fast the rendering engine is.
Here we see about--looks like 220 milliseconds, on average, per page for this test.
And we're going to repeat this test now in Chrome.
[pause] So Brian's going to resize the windows so
they're the same size. [pause]
So I think that's a bit faster. And so hopefully you can see why we really
were impressed with WebKit's performance. And it's very fast at loading static content.
It makes it so that our job is how fast can we feed data to WebKit?
Then we know these pages will appear quickly on the screen and will give us very nice performance
properties. Now this is the test of static content, and
of course the web is very dynamic these days. And to talk to you about our new JavaScript
engine--which is all about making dynamic content faster--is Lars Bak.
Thank you. [pause]
>>LARS BAK: [clears throat] Thank you, Darin. So, I'm Lars Bak.
I'm a V8 Tech Lead, and I'm all the way from Aarhus, Denmark to present V8.
And we like fast performance. And we talked about the WebKit that adds something
to it, but we decided we want to do more. We wanted to design a engine that would work
for the future web applications on the web. And in order to do that, we could see that
you get more and more JavaScript code in web applications, okay?
So we decided to do one that's a brand new one--one that really makes JavaScript run
many times faster than what you will see in other browsers.
When JavaScript first came around, it was used to customize buttons and simple things--it
was only a few lines. But already today, we have applications like
Gmail, where you actually download several hundred
kilobytes of JavaScript code you have to execute in order to navigate around in Gmail.
And I guarantee you, this trend will continue. So we need something that can really take
care of the future web applications. What else should I say?
I should say that I've been doing work with machines for 20 years, and this is one of
the most exciting time times I've had so far. JavaScript is a hot program language to make
fast, and the problem with JavaScript is it's very dynamic,
so when you create new objects, they look like they are very independent features and
there's no sharing between them, and the underlying system cannot take advantage
of it. Well, we came up with an idea that could change
all that. So we found a way to introduce something called
"hidden classes," and what it does--it actually monitors the
program as you run it and creates common structures of updates inside the working machine.
To a user, it's actually the same. We preserved the same semantics as the other
virtual machines, but when we have this shared structure,
we can start applying optimization techniques that are well known in other classes of virtual
machines--and I think more like Java and SmallTalk-- we can apply these ideas in JavaScript and
get a very good speed up. There are three design ideas in our engine
that makes it run really fast, and you need all of them to get JavaScript to run fast.
The first one is, we needed a compiler. Most JavaScript engines today--they do interpretation.
So whenever they go to a certain point in the program, they have to look at, "Oh, what
should I do now," and so on. That's fairly slow, everybody knows that.
So we did a native compiler, so we take the source code, we get into the browser and give
it a native code so we can utilize the hardware of the machine you're running on.
That's step one. Step two is we wanted to use these classes
we tracked when running the program and use inside the native code.
And what we do is we apply a technique called inline caching, and that has to do with dynamic
patching of native code on the fly--you all understand this, of course.
[audience laughs] But what it means is that when you run JavaScript,
accessing properties in JavaScript objects is extremely fast, and also doing function
calls. And when you have these two things being really
fast, it gives the web application developer the
option to add more libraries to the browser when running web applications right.
You can factor in code more, you can include more code into the browser and it really opens
up for the sort of creativity of the web application developer.
That is really what we are getting at. The third thing we added was a very efficient
memory management system, and that gives you fast object allocation and it gives you scalability.
So VM--the VM we have here, V8--has been designed to be very scalable.
You can add tons of code inside the browser and when you are running, you can allocate
a lot of objects and you will not see the system slow down, okay?
So that's part of the design system--or design sort of focus of our VM.
So I think we should try to see how fast it is.
What do you think, Brian?
>>BRIAN RAKOWSKI: That's a good idea.
>>LARS BAK: So we have tried--we created a small test that will demonstrate the speed
of V8. But first we will take an existing browser
and here we will take Internet Explorer, okay? So this is a small kind of demonstration of
JavaScript speed. And as you can see you have this icon moving
slowly clockwise, and for each tick, it will actually execute a benchmark.
And what you see in the middle is a number that says the estimated roundtrips per hour.
So that's not very exciting and I'm getting bored already. [audience laughs]
So let's try V8--let's hope it's faster! [pause]
Oops, not yet. It is somewhat faster, so I can see. [audience
laughs] Now when I went to school--this is actually
a big factor--this is a big factor. So V8 is running way faster than the JavaScript
inside the other browser. So I hope you're impressed even though it
was just a simple number. [audience laughter] So JavaScript is not everything when it comes
to a web application. It is clear that JavaScript is part of it,
but operating on the dawn and also fetching stuff from the net is important, but at least--
what we have done with V8--we have created an engine that makes JavaScript run really
fast. Our system is, of course, open source, and
the main purpose of V8 is to increase the performance bar for JavaScript.
We want all browsers to run much faster, right? So the other browser windows--they can take
this and include it in their system, or they can use our ideas to figure out how to do
an even better system. We like competition.
And that pretty much conclude our sys--oh, one thing I should say as well is that when
you get access to a code at google.com/p/v8, you can find the source code there,
but what you can also find is a comprehensive benchmark suite and you can try out different
browsers to see how fast they are. We have collected a benchmark suite with sort
of medium sized JavaScript programs that is a total of 11,000 lines of JavaScript,
and you can use that to actually measure V8 against other browsers.
So please go and try it out. Thank you.
[pause]
>>SUNDAR PICHAI: Thanks, Lars. Listening to Lars speak is like attending
a computer science lecture, so I hope you enjoyed that.
[background noise] So a couple points, I want to reiterate that
Chrome is fully open source. Everything you saw, including V8, and the
front-end and everything will be available today, as Chromium and we are very excited
by it. I want to stress about one more thing.
While we demonstrated Chrome with Google Search, Chrome has no tie-ins to major Google services.
In fact, when you install Google Chrome, if you are a user who was using IE and had Live
Search or Yahoo as your default search, we just migrate that preference over.
So Chrome is configured to be used with any search provider or any homepage, and so on.
So that's very important, even though we demo'd it with Google Search; we want to preserve
user choice in these things. So looking back, it's been over two years
of work. I remember when we started working on the
project, Marissa, who is here, challenged us to write a press release on day one.
She said, "Why won't you think about--"you know--"how do you want to talk about this
to the world?" We should build a meaty browser, we should
build something very different shaded. And so we actually--Brian, myself and a few
others wrote a press release on day one when we started working on this, and it's very
nice to see how far we have come. I want to thank a huge team, here in Mountain
View, in Kirkland and in Aarhus, who have contributed many, many hours to this project.
They are all watching it on webcast, so I want to say thanks to everyone.
And finally, Larry's here, and Larry was an early supporter of the project.
He stopped by many times to the team buildings and spent time with the team members, and
he's a power user of the product, so I want him to share his thoughts on Chrome.
>>LARRY PAGE: Well thank you. I really want to thank the amazing team here,
and I want to thank all of you who are here in the room and on the webcast, for participating
with us on short notice. I want to just say a few things I thought
the team hadn't said. I wanted them to be out front, because they're
again--they're such an amazing team, they've worked so *** this,
and I think you have seen that in some of the details they showed.
I've been using Chrome now for about--quite a while, actually--and I've really enjoyed
using it. I've used it as my primary browser, and I've
actually used it--to the detriment of the team--on a really slow, old computer on purpose.
It's really forced them to make it fast without a lot of memory, and on slower computers and
so on. And I think that's one of actually the main
issues with the web today, is you actually--if you look at what you're doing on the web--
you know--you're actually looking at a blank screen waiting for something pretty often.
And speed--you know--they didn't go into a lot of detail on speed, although we feel it's
very, very fast. But there's actually--it's a hard thing to
measure. It depends how much memory you have, it depends
what web pages you're on, it depends on a number of different things.
I think the team has done an amazing job of dealing with all those issues--and they're
smiling-- Because they haven't heard me say that, because
I'm always very *** them on that. They've really worked *** that, and I
think if you install it and use it, you'll really feel that,
even on--you know--maybe older computers, not a brand new computer, whatever.
The other thing I did want to say, Sundar just reiterated the open source aspect of
Chrome, but we really--as Computer Scientists--we
want to live in a world where--you know--our platforms are really advancing;
where they can be improved, where people can add new functionality, where the pace of change
and improvement is really rapid. We don't want to live in a world where all
that's locked up and kept secret and nobody can improve it.
And the open source models really allow people to do that--you know--allows any developer
in the world anywhere--you know--who's connected to the internet--
they can make an improvement to an open source project, like Chrome, and that can really
make the world a lot better. It also means that other projects like Mozilla,
and so on, can take some of the advancements we've made and the hard work that's been done
on things like V8, and they can actually choose to incorporate
those things pretty easily, potentially. And so I think that we're entering kind of
a new era where some of the advancement can be made much more quickly than it was in the
past, and--you know--this technology can be used
for learning, for development and so on, in a way that hasn't happened before,
and I'm really proud to be part of Google and to be behind that.
I also just wanted to say--you know--we--I just wanted to mention how we decided to release
this, because--you know--it's challenging to make
a browser, obviously, and we actually--the criteria we used is that we have a ton of
Googlers using it who are happy. And that's actually the best way that we could
test it and really know that it's a great project, and that's what's happened.
We had a ton of people using it internally, all the time; we've been measuring that,
and they've been happy and continuing to use it and enjoy it like I have.
And so that's why we are here today and why it's released.