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
communication 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, which is Sundar's name.
Thank you again for coming down.
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 I'l like to to introduce Sundar Pichai, vice
president of product management at Google.
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.
I hope you all had a chance to skim through the comic.
I 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 you who don't know, Scott McCloud is a
legend in the comic world.
And he has been 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's a lot of work that's
gone inside Chrome.
And we were looking for a good way to
describe it everyone else.
And Eric suggested working with Scott.
And so Scott was embedded with the team, he interviewed a lot
of folks and wrote the comic, 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're doing here.
I want to introduce the team.
And the goal is to spend about 30 minutes, we will give you a
full end-to-end demo off the product, covering both the
user experience and all the technology
that underlies Chrome.
And we will wrap up and take Q and A. And Larry will be
joining us as well for Q and A.
So with that let's get started.
So as you can see from the slide, on the top left what
you're seeing is the homepage of Amazon.com in 1995.
If you look at it, it was very symbolic of the
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 in 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 original 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 XML Http led to many of the Ajax
applications we see today.
But we believe that browsers should evolve a lot more to
keep pace with how fast the Web is evolving.
I'm sure most of you spent 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.
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.
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 a powerful is a very
sophisticated core.
So under the hood we have our infrastructure, ranking, all
the 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.
So this is Google Chrome.
It has a very simple, streamlined look which I'll
talk about in a minute.
The dictionary definition of chrome, by chrome it means the
borders of a web browser window and includes the menu
bars, tool bars, scroll bars, and so on.
It's kind of an ironic name for our product.
While we call 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 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 are forgetting that they were
using a browser.
So what does that mean?
In Chrome as you can see on top, there's a very
streamlined chrome of the browser.
So we saved most of the space for that 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 for
what I mean by this 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've spent a lot of time optimizing
these two use cases.
So what's on 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 and 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 webmaster and your site works in Safari,
it'll work automatically in Chrome.
Why did we choose WebKit?
It turns out to be very fast. Darren Fischer, who is our
tech lead on the underlying technology in Chrome will give
you a complete demo of WebKit in a short while.
So WebKit turns out to be much faster, it's a very simple
code base, and it was very familiar to lot of Google
developers as well.
It turns out that our mobile efforts, 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 multiprocess technology.
So let me describe this for a minute.
What do we mean by multiprocess?
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've 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, you can continue
doing all the things you're 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 also 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 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
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 multiprocess 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 rewrote 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 also talk 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 parts
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 the start 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 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 so there is enough
internal pressure to get this ready on those platforms as
soon as possible.
Another thing which is very exciting for Chrome is on day
one we are launching it in over 100 countries and in 43
languages, which is unprecedented for a product of
this scope on day one.
So we are very excited by that as well.
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
the very permissive BSD license.
Our intent here is to help drive the whole of web
platform forward.
As we built Chrome, we benefited 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 help drive the web
platform forward, as the Web gets better, that's a direct
strategic benefit for Google.
We live on the Web, we build services 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're announcing Chromium, which is our open
source project, 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.
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 user interface for Google
Chrome, 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 webpages 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
tool bars, and buttons, and that kind of stuff.
But more of a streamlined thing, more of a window
manager for webpages and apps.
And so we developed a very streamlined user interface
which Brian will bring up right now.
This is the Chrome window.
As you can see, one of the first things that we focused
on was tabbed 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 we've actually put at
the top of the window.
So we think of tabs as kind of like title bars for
webpages and apps.
And so they're up here at the top.
And as we built this functionality, 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: OK, so let me show you the tab strip.
As you can see, it's up top.
And we think 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 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.
It's almost like you want to drag them.
So I'm going 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.
It's really easy to do, it feels really nice.
They're really grabbable, and draggable, 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.
I can close another one really easily too.
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're
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.
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 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.
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're going to do it.
So we thought to ourselves what if we could 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.
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 it the Omnibox.
And to get it to work right required a
little bit of magic.
BRIAN RAKOWSKI: Let me show you the Omnibox.
So as you can see here, like Ben said, it's a little bit
psychic 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 only to have to type
one or two characters into box before it gets you to where
you want to go.
And that's how it earned its name.
So let me show you.
It 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, 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 take a vacation after this launch
finally happens.
So I'll just type Alaska cruise and everything,
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 lots 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 the next time when I decide I want to go to Amazon, I'll
type A, and lo 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 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 set up.
And it's a very easy way to get 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, which you get when you open a new tab.
And basically, what we noticed with a lot of browsers was
that this page is blank.
Now you're trying to go somewhere, so it seemed like
kind of an untapped resource.
When you open a 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.
A lot of people like bookmarks, but also bookmarks
can be, for some people, a 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 have 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 have 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 if 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
at 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.
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.
BEN GOODGER: That's really cool.
In fact, this is one of my favorite features because the
page, it does become yours.
It is the stuff that you do.
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 home page 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 the last time you used the browser.
So when we were looking at all 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 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 you
basically 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 now
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 short cuts 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.
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
in incognito.
I don't know what you guys do, but maybe I want to do a
little bit of research for a friend, of course, who has had
this disorder.
So I'll do a little research looking around trying to find
a cure and OK, this looks like I have what I need now.
And just to prove that nothing is remaining in 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 remain 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 nice, it's not an experience that forces you to
switch from one thing to the other to the exclusion of
everything else.
You can just pop one open, and browse for some stuff, and
then close it, and 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
the invisible browser.
A browser that didn't show annoying pop up dialog boxes
at you are 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.
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.
You can then interact with them, 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 webpages that act more like
applications.
And sometimes these are the pages that you can keep open
all day long because they are 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 can do for that, for
that 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 in 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 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 can 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 stop at just 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 Darren.
DARREN FISCHER: Thanks, Ben.
So my name is Darren Fischer.
I'm another [? tech lead ?] over at Google Chrome and I'm
here to talk to a little bit about what's under the hood.
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 were very interested in the use case of users who
leave their browsers running for a long time.
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 was
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 I'm going to some webpage 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 his work that you've had
in progress.
So it seemed obvious to us that it sure would be nice if
the browser 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 webpages and web applications.
So that's what we did.
We built this multiprocess rendering engine, or
multiprocess browser architecture that puts the
rendering engine down into sub child processes.
And this has many benefits.
The obvious one, the one I've already been
talking about, is stability.
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 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.
Now security, it turns out that there's 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 multiprocess
architecture is we recognize that to render webpages
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
the registry, and so on.
But to render webpages, 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.
This has very nice security properties.
It gives you an extra level of protection.
We call this technology the sandbox.
Now, the way I like to think about it is for a bad guy to
get malware onto your computer, ordinarily he'd just
have to find a bug in your rendering engine.
And once he does that, he has access to computer.
But not in Google Chrome.
In Google Crhome he also has to find a
way out of the sandbox.
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.
OK, so now I'd like to do a little show and tell and have
Brian bring up Chrome's Task Manager.
What you can see here is some user interface that looks a
little bit like Windows Task Manager.
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 so 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 plug-ins out of process.
We found that we could apply the same principles that give
us separation between tabs in the
browser to tabs and plug-ins.
These are the traditional browser plug-ins like Flash,
Quicktime, Java, and so on.
We actually found that it was very nice if we can have these
things out in their own processes so that suppose you
visit a webpage where an advertisement is
served using a plug-in.
And imagine somehow that plug-in misbehaves or
encounters a bug.
Well all you would lose is the plug-in.
All you would lose is 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 when
applied to plug-ins as well.
So now Brian is going to demonstrate an example of a
tab that's misbehaving and then he's going to show you an
example of a plug-in that's misbehaving.
BRIAN RAKOWSKI: OK, so here you can see we have the Task
Manager up, we also have Chrome running here.
Let me bring up the bookmarks toolbar so I can use it to
simulate a hang.
Sometime 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 its 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 multiprocess
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, liked Darren 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.
End the process and here we have the little sad tab.
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's broken, I
can close it if I want to.
But it's also really easy to recover, I just hit Refresh,
I'm back where 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 Darren talked about was plug-ins.
Plug-ins are in their own process.
So let me go to a site that uses plug-ins.
We like to use YouTube a lot.
So let me pick a video here that looks interesting.
How about this one?
So you see the thing is 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
plug-in process.
I'll use End Process here in the Task Manager.
And here you get a little sad plug-in, just
like the sad tab.
It's sort of cute, we needed something to make ourselves
feel better when we encountered a crash.
So here we 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 it will reload the plug-in and start playing 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.
DARREN FISCHER: Thanks, Brian.
So 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 multiprocess architecture has
nice performs properties because of parallelism.
But we're also interested in raw performance.
And raw performance is a big part of what influenced our
decision when it came to the choice of rendering engine.
Sundar mentioned before they 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 I don't want you to just take my word for it when
I saw it's fast, I want to actually demonstrate that.
So what Brian's going to do now is run 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 network I/O 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.
Brian's going to resize the windows so
they're the same size.
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 performs properties.
Now this is a 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.
LARS BAK: Thank you, Darren.
So I'm Lars Bak.
I'm the V8 tech lead and I'm all the way from Aarhus,
Denmark to present V8.
And we like fast performance.
And we talked about Webkit that adds something to it.
But we decided we wanted to do more.
We wanted to design an engine that will 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.
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 processes.
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 that 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 shoud I say?
I should say that I've been doing virtual machines for 20
years and this is one of the most exciting
times I've had so far.
JavaScript is a hot programming language to make
fast. And the problem with JavaScript is it's very
dynamic, so when you create new updates they look like
they're very independent features and that's no sharing
between them and the online 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 is it actually monitors the program
as you run it and creates common structures of updates
inside the virtial machine.
To the user it's actually the same, we preserve the same
semantics as the other virtual machines.
But when you 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 [? small talk, ?]
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 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 generate native code so that
we can utilize the hardware of the machine you're running on.
That's step one.
Step two is we want 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.
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 developper the option to add
more libraries to the browser when running web applications.
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're 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 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're running you can allocate a lot of objects
and you will not see the system slowdown.
So that's part of the design focus of our VM.
So I think we should try to see how fast it is.
What do you think, Brian?
BRIAN RAKOWSKI: Good idea.
LARS BAK: So we have created a small test that will
demonstrate the speed of V8.
But first we'll take an existing browser, and here
we'll take Internet Explorer.
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 excecute a benchmark.
And what you see in the middle is a number that says the
estimated round trips per hour.
So that's not very exciting and I'm getting bored already.
So let's try V8.
Let's hope it's faster.
Not yet.
It is somewhat faster as far as I can see.
This is a big factor.
V8 is running way faster than the JavaScript inside the
other browser.
So I hope you're impressed even though it's
just a simple number.
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 [UNINTELLIGIBLE]
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's pretty much concludes it.
Oh, one thing I should say as well is that when you get
access to code.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 browser to see how
fast they are.
We have collected a benchmark suite with sort of medium
sized JavaScript that is a total of 11,000 lines of
JavaScript and you can use that to actually measure rate
against other browers.
So please go and try it out.
Thank you.
SUNDAR PICHAI: Thanks, Lars.
Listening to Lars speaks is like having a computer science
lecture so I hope you enjoyed that.
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 such provider or
any home page and so on.
So that's very important even though we demoed 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,
Melissa, who is here, challenged us to write a press
release on day one.
She said, why don't you think about how do you want to talk
about this to the world?
We shouldn't build a me-too browser, we should build
something very differentiated.
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 our huge team here in Mountain View, in
Kirkland, and in Aarhus who have contributed many, many
hours to this project.
They're 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: Thank you.
I really want to thank the amazing team here.
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 again they're such an
amazing team, they've worked so *** this.
And I think you've seen that in some of the
details they showed.
I've been using Chrome now for 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 to really force 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.
If you look at what you are doing on the Web, you're
actually looking at a blank screen or you're waiting for
something pretty awesome.
And speed, they didn't go into a lot of detail on speed,
although we feel it's very, very fast. But actually it's a
hard thing to measure, it depends how much memory you
have, it depends what webpages 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.
But they've really worked *** that and I think if you
install it and use it, you'll really feel that.
Even on maybe older computers, not a brand
new computer or whatever.
The other thing I do 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 our
platforms are really advancing, where they can be
improved, where people can add new functionality, where the
pace of change and improvements is really rapid.
And we don't want to live in a world where all that's locked
up and kept secret and nobody can improve it.
The open source models really allow people to do that.
It allows any developer in the world anywhere 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.
So I think we're entering kind of a new era where some of the
advancements can be made much more quickly than it was in
the past. And 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 mention how we
decided to release this.
It's challenging to make a browser, obviously.
And actually, the criteria we used is that we had a ton of
googlers using it who were 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 an internally all the time,
we've been measuring that.
And they've been happy, and continuing to use it, and
really enjoy it like I have. And so that's why we're here
today and why it's released.