MALE SPEAKER: Yeah.
Yeah, let's get started.
To open the summit, we're
going to welcome onto the stage
the vice president for
engineering for Chrome.
It's a warm welcome to
Linus Upson, everyone.
[APPLAUSE]
LINUS UPSON: Thanks.
Wow, a lot of people here.
So not surprisingly, I'm
here to talk about the web
and what we're doing
about it in Chrome.
Let's figure out
which button to push.
That looks good.
How many people
here recognize this?
Oh wow, there's a lot
of old people here.
So those of us old
folks will remember,
in the very early
days of the web,
there was this thing called
the NCSA What's New page.
NCSA was where Mosaic was
developed, the first really
popular web browser.
And back in those days, the
way you found things on the web
is you went here.
And it had a list of all
the sites on the web.
And so when you stood
up a new website,
you sent an email saying,
hey, I've got a new website.
Could you please link to
me on the What's New page?
And they would go do that and
have a link to your website
there.
And you can see here
in June 27, 1993,
we had one, two,
three, four, five
websites that launched that day.
Nothing on the 26th.
It was probably a Sunday.
Needless to say,
this didn't scale.
So then the next popular way for
finding things was directories.
Yahoo!
was the most successful of them.
And many conferences
were held about how
the web should be organized.
People talked about ontologies,
and they came up with ways
to categorize
everything on the web.
And when you wanted
to find something,
you'd go to Yahoo! or one
of these other directories
and click on Games
or Entertainment.
And eventually you'd
find a group of websites
that you could look down and
pick which one you wanted,
or try a few of them
to see if that's
what you were looking for.
And Yahoo!, at the peak of
popularity, had about 3/4
of a million sites
in their directory.
And I think they peaked at about
a million and a half sites.
So needless to
say, this approach
didn't scale for
the web, either.
Then came search
engines, Google being one
of the more successful ones.
The really clever thing
that Larry and Sergey
did at the very
beginning of Google
was they figured out that
just the text on the web pages
told you a lot about the web.
But the links
between those pages
were also really important.
And in fact, this chaotic
structure of the web,
with everyone linking
to everyone else,
actually told you a lot
about what was important
and what wasn't so
that you could deliver
really great search
results for people.
And so far, this is still
scaled with the web.
And when you think about
it, it's pretty amazing.
Because there are billions
and billions of web pages
out there.
Hundreds of millions
coming and going every day.
Billions of users.
And for many of us,
on any given day,
we'll consume tens,
if not hundreds,
of different sources of
information, content, services,
applications, communicate
with people, all just
by doing a search and
clicking on a link.
And so we've been thinking
a lot on the Chrome team
about what has made
the web successful.
And what are the areas that
it really needs to improve?
And so first, let's
talk about what's
made the web really successful.
And this first thing
is the HT of HTML.
Everything is a link.
So you can get to anywhere on
the web by typing in a URL,
clicking on a link.
These links can be spoken to
people, just try domain name.
They can be written
down on napkins.
They can be emailed, IMed, and
so they spread very freely.
And it makes it really
easy to try something
because all I have to do is
click on a link to do it.
The other important part of
that is it's also ephemeral.
In other words, there
should be no side effects
to clicking on links.
I don't have to
install software.
I don't have to update software.
I can just run any piece
of software-- untrusted,
third party code-- by
clicking on a link.
And then when I go
away, my browser
may end up caching it
for a period of time,
or something like
that, but I, as a user,
don't have to worry about that.
The next thing is indexable.
So web pages show you all
of their text by default.
You don't necessarily
have to write it that way,
but the easiest way to write
a web page makes it indexable.
And so this allows
search engines to appear.
And even though search
engines didn't really
exist at the very
beginning of the web,
the fact that the
web had this property
allowed it to scale
to this massive size
with all of these
different pages,
and yet you can
still find things.
And you don't have
to go manually
organize them into directories
and things like that.
The next thing--
composability-- was not
at the beginning of the web.
But not long after that,
iframes were invented.
And it made it possible
to take multiple sites
and mash them up
into one web page.
And so this allowed you to
do things like embed YouTube
videos in a page, or
put a map in a page,
or, very importantly
for many publications,
to be able to put
an ad in a page.
And the composability also had
some very important properties
that the page containing
the other page
couldn't muck with what's inside
it, and the thing inside of it
couldn't muck with the
outer containing page.
And so this allowed
it to very safely
be able to aggregate content
from lots of different places
and make much richer
applications than if you
had to go get code and
import it from someplace else
onto your website.
And that also brings me to
the last point, which is safe.
If you're going to run arbitrary
code by clicking on links,
it had better be safe.
And so one of our most important
jobs as browser vendors
is to make it so that it's
safe to click on links.
It should be impossible for a
bad guy to lure you to a site
and then install malicious
software on your computer,
or steal your credentials,
or do anything like that.
And so this set of
properties is what
we think has really
made the web successful.
Because you saw from
those early screenshots,
the web was pretty
ugly in the early days.
Everything was gray.
Someday gray will be a
popular background page
color again, but probably
not any time soon.
But even though the web was
kind of slow, kind of ugly,
the fact that it had these
really nice properties
caused it to just take off.
And for the better
part of 15 years or so,
most of the innovation that
happened in the technology
industry happened on
the web because of all
of these advantages it gave you.
Then in 2007 came the
iPhone, and shortly
after that, Android, and a
number of other smartphone
OSes.
And they completely
changed the game.
And they reset user expectations
in a number of important ways.
One of which is everyone now
expects all user interfaces
to have rock solid,
60-frames-a-second animations
and transitions.
This was not something
the web was built to do.
But now everyone expects this
in all of your user interfaces.
Other things it did--
it gave you the ability
to pre-cache a whole
bunch of software and data
when you installed an
application so that it worked
well in flaking
networking environments.
And if any of you remember
the early generation iPhones
or Android phones, everything
was a very flaky network
environment.
I can remember when I got
3G, and I was so excited.
I saw the little 3G on there
like, wow, this is fast.
Now with an LTE phone, every
time I see the 3G, I go, aww.
But being able to cache all
of your application code
and resources upfront
made it work really
well in these flaky
network environments.
Other things it
did-- it gave you
access to a lot more
IO capabilities.
It gave you direct
access to the GPU.
It gave you access
to touch sensors.
It gave you access to
raw network access,
device motion, location,
GPS, a whole bunch of things.
It allowed developers to build
more interesting applications
and ones that were more suited
to the mobile environment.
And it also allowed
you to bring to bear
a whole bunch of different
development tools.
You weren't stuck
programming in one language
or one environment.
Even Apple-- I don't know
if you guys remember this,
but a few years ago,
they tried to make it
so that everyone
building apps for iPhone
had to write in
Objective-C. They
tried to ban other languages.
And developers rioted.
And this is Apple.
The Apple development community
more easily follows direction
and is more homogeneous
than any other development
community I've seen,
and even they rioted.
The game developer's
like, we need Lua.
And they were like, I need
to write C++ GL games.
And so even Apple had
to back off there.
So the importance for developers
to use whatever languages
and tool sets and
libraries they want
to use to build
their applications
is also really important.
So these are all
the places where
mobile applications excel.
And these are all
places where we really
need to close that
gap on the web
so that you can do all of
these things on the web,
so you retain all the advantages
that web applications have
that native applications lack.
But one of our goals
on the Chrome team
is to really close that gap.
So the first thing on the
list is rendering performance.
So I mentioned before
the expectations
around mobile devices
now are everything
is 60 frames a second.
And so when the web
was originally created,
people really weren't
thinking about how
to do rendering using GPUs, how
to make it so that you don't
have stutters and
frame rates, and all
of these kind of things.
So there's a bunch of
projects we have underway
in Chrome to do
this, some of which
involve new web standards
like web animations
so that you can specify
declaratively what animation
or transition you
want to have happen.
And then Chrome, or the
browser, can then automatically
make that happen for you so that
you don't have to write code
to handle every single
frame of the animation.
And that allows the
system as a whole
to schedule activity to
maintain that frame rate so
that you don't get glitches.
Other things we're
doing are things
like reducing garbage
collection pause time.
So if you have to do
work to produce a frame,
you want to make
sure that you can
maintain that
constant frame rate.
It really sucks if you're
trying to produce a frame
and a GC comes, and you go
away for 60 milliseconds,
and you drop four frames.
And so we're working very hard
to both measure and improve
garbage collection and other
VM latencies that exist.
Because in complex VMs like
V8, they do clever things like,
oh, I notice you're running
this function a lot.
Let me optimize it for you.
And even the process
of doing that,
that could cause you to
miss an animation frame.
And so we're working
very hard to make sure
that that never happens.
And there's a bunch of
work under way to do that.
And it's particularly tricky,
both for garbage collection
as well as [? compilation ?]
pauses and things like that,
because even if you
have multi-core--
and we work hard
to take advantage
of all the different
multi-core processors--
your application might also
be competing for cores.
Or even if you're not
competing for cores,
very often you may be competing
with the garbage collector,
the compiler, for memory
bandwidth or cache
pressure, things like that.
So it's a very
challenging problem.
But we've made a lot
of progress on that.
So here's some examples of
the improvements we've made.
So this was one of our
performance dashboards
that tracks JSGameBench.
And you see some
changes were made
that dramatically
improve performance.
Now, we also look for
performance regressions.
And we have a lot of
performance dashboards.
If any of you have crawled
around the Chromium site
and tried to look at all of
the performance dashboards,
I think there are
so many of them
now that no human can
keep track of them all.
And in fact, about
a year and a half
ago, we had a massive
regression on one of them.
And nobody noticed.
Because there were just too many
for people to keep track of.
And so that spurred
the team to think
like, how do we
solve this problem?
And so since the thing we know
how to do is build software,
we actually built software to
watch all of the performance
dashboards for us.
They actually found this
really cool anomaly detection
framework that was developed
elsewhere in Google
and trained it to look at
the performance dashboards.
Because as you know,
sometimes it's hard to tell,
is it slowly getting slower, or
was there temporary regression?
Was the bot just
having a bad day?
And so now, we've
got this system
where I get email
alerts when performance
regresses in any of these areas.
And we have a team of sheriffs
that go and look at the results
from all of this,
and then go figure
out what change
caused the regression,
and go nag the developer who
does that to revert the change
or make a fix so that we
get the performance back.
And so now, even though we
continue to add capabilities
to Chrome, and the code
keeps getting bigger,
it's actually, in
almost every area
that we can measure,
faster, and uses less memory
today than the day
we launched five
years ago because of this
continual measurement
of everything.
Basically for places we regress,
they're usually in areas
that we failed to measure.
And then when we find them, we
add a new measurement for it,
and we work hard to
never regress on them.
We're not perfect, but we're
getting better and better.
Another area we've improved a
lot is JavaScript performance.
We've improved on mobile about
50% in the last year or so.
And this is an area that is,
of course, very important to us
because most of the
code that you run
is all written in JavaScript.
And so this goes directly to how
fast your applications can be.
In addition, we
launched a new version
of the Octane benchmark.
So Octane is the benchmark
we use to tune V8 against.
Because we basically try to put
things in Octane that we think
are important to make go fast.
And then we work really
hard to make it go fast.
And in Octane 2.0,
the changes we
made there were
primarily around latency.
For the first time, we
have a JavaScript benchmark
that actually
measures latency so
that if you have long GC
pauses or frequent GC pauses
or things like that, you'll
score poorly on the benchmark.
We also brought in a bunch
of code from Emscripten.
So basically, we have a zlib
compiled down to JavaScript
with Emscripten.
So we're using asm.js-style
JavaScript and include that
in the benchmark as well.
And we don't implement a special
compiler or anything like that.
But we're just trying to
make generic V8 work well
on all kinds of JavaScript, even
machine-generated JavaScript,
like the stuff that
comes out of Emscripten.
And then we also added some
other large programs in there
to really test parse time,
compilation time, and latency,
and things like that.
So large code
bases of JavaScript
so that those things get
benchmarked and tested,
as well.
So another area-- and we
talked about working well
in flaky networks and
network performance.
One of the things we've
done to make the web more
usable on mobile
devices is we've
introduced this mobile
data compression proxy.
And it gives you a 50% savings
on the data transmitted.
Right now, we're really
focused mostly on saving data.
Because a lot of people's
usage of their mobile device
is limited by
paying for the bits
that they get over the air.
And so we're really focused on
shipping fewer bits to them.
But also, there's opportunities
to get performance improvements
here, as well.
In addition to
building proxies--
and one of the biggest
things that the mobile data
compression proxy does is it
converts JPEGs to webp images,
which are about 25% smaller for
the same quality level as JPEG.
But also, by making that image
format available on the web
generally, a lot
of sites at Google
have converted to using webp
if the browser supports it.
And a number of sites at Google
have seen latency reductions
on the order of 30%, 40% because
a large portion of that page
load time is just transferring
data down to the user.
So if you can
transfer less data,
you can make the
web much faster.
And the same is true on video.
Going from VP8, which is about
comparable to H264 in terms
of quality per bit,
and moving to VP9,
we're getting a 50%
savings in the data rate.
And so there's a number
of properties at Google
that are moving to
use VP9 inside of webm
to transfer less
data down to users.
And this, of course,
is particularly
important on mobile devices.
So some of you may know-- how
many of you have met app cache?
How many of you have typed
"app cache" into Google,
but not hit Return to see
what the suggestions are?
[LAUGHTER]
LINUS UPSON: So
ServiceWorker is an attempt
to repent for those sins.
We want web applications to
be able to work really, really
well, even in flaky
network connections,
or even when you're
completely offline.
And so we're putting
a lot of effort
into ServiceWorker to make
that much easier to program
and much more reliable to
program in that kind of model.
And we're also
doing a lot to add
APIs to access all of
the different hardware
capabilities of both
desktops, laptops,
as well as mobile devices.
We've already got parts of
the device motion API in.
We already have a location.
And a bunch of additional
things are underway.
Three other big things
have landed recently.
We've got WebGL,
WebRTC, and Web Audio.
And so this allows you to do
much more interesting graphics
on the web than you
could do before.
Allows you to do very
interesting multimedia,
both video and audio.
And WebRTC, in
particular, I think
is really going to
revolutionize communications.
Because now, you can really--
when you think about it,
web is really about
communicating with people.
And it's a shame that we've
gone all this time without you
actually being able to
communicate with people.
And WebRTC is going to enable
this for the first time.
It's very cool.
I talked about some of the APIs
that have come in recently.
The other thing that
mobile applications
have gotten to take advantage
of is new UI toolkits and new UI
paradigms.
So we're working on
a number of things
here to make it much easier
to build really beautiful user
interfaces and to make them
work well in touch environments
and in different screen sizes.
So one of the things that's
obvious about mobile is typing
is a lot harder.
And so we've recently
introduced something
called request autocomplete.
And what this does is
it allows the browser
to remember sets of information,
the most important of which
is payment.
Because if you want to
buy something on the web,
having to type in
credit card number,
shipping address,
mailing address, all
of those kinds of
things, it's a real pain.
And so this allows
you to do that once,
either on a mobile
device or on a desktop,
and then Chrome syncs it across
all of the different platforms.
And then when you want to
go check out on a website,
it can just call
request autocomplete.
It shows you a dialogue with all
of your information filled out,
and say, hey, do you want
to send this to the website?
You can look at it and
say, yeah, that's great,
and click OK.
If you need to change
something, you can.
You can select a different
shipping address, for example,
or select a different
credit card.
But for most cases,
this really just brings
really, really simple checkout
flows to mobile devices.
And there's some
other things we have
in the pipeline along
this line, as well.
Another big thing
we're doing is Polymer.
How many people here
have heard of Polymer?
OK.
It's really exciting
on two levels.
One, and this may seem obvious,
but in most programming
environments, you
can write a function
in terms of other functions.
With web components that
Polymer's built on top of,
for the first time
on the web, you
can actually write HTML tags
in terms of other HTML tags
and bundle the appropriate
CSS and JavaScript
with it and things, as well.
So you can build real
first class components
and have structured
programming on the web,
and not just
cut-and-paste programming.
And so this is huge.
And Polymer is a toolkit that
was designed from the beginning
to live on top of
web components.
And it brings both the
structure of the application,
to make it much easier to build
your app, as well as a user
interface layer so that you
can have really beautiful 60
hertz animations
and transitions.
It knows what all of the
fast paths are in the browser
and tries to stay on them.
In fact, by definition,
there's this constant feedback
loop going between the Polymer
team and the Blink team
so that every time the Polymer
team needs to make something
fast, the Blink team
goes and makes that fast.
And so by using this toolkit,
it's one of the easiest ways
to stay on all of the fast
paths inside of Chrome.
And it's also got
polyfills for all
of the other modern
browsers, as well.
So you can write your
application once and deploy it
across all of the
different browsers.
So what else is this one?
I forgot what's on this slide.
AUDIENCE: Add to homescreen.
LINUS UPSON: This is what?
AUDIENCE: Add to homescreen.
LINUS UPSON: Add to
homescreen, right.
So in the latest
version of Chrome,
you can now be browsing
around in Chrome on Android,
and you can take a
web page and add it
to the homescreen of Android.
So something really
simple, but it
makes it a lot easier for
people to go back and get
to websites again.
And of course, we're working on
making handling the source set,
or what's the other one called?
Set In?
AUDIENCE: Source In.
LINUS UPSON: Source In, yes.
So that you can handle multiple
image resolutions, as well
as handling composition and art
direction and things like that,
which is really
important-- being
able to work across lots
of different screens.
And also very
importantly, we care
a lot about developer
productivity.
So we've invested a lot
in Chrome's dev tools.
How many people
here have used them?
Everyone.
OK, so you're
familiar with them.
So if you can't easily
develop debug applications,
you're not going to
be very productive.
And so we really want to
make this better and better.
So a lot of things
have shipped recently.
And let me take a look here.
See if I remember all of them.
We have-- let's see,
there's projecting.
There's remote
debugging to mobile.
And I think there's also--
what was the other one?
Screencasting?
AUDIENCE: The Layers panel.
LINUS UPSON: The
Layers panel, yes.
And in addition to that,
there's a whole bunch
of tools we've developed for
debugging GPU performance.
Because it's very
hard, sometimes--
when you're writing
something, you
see a little screen stutter--
to figure out what happened.
And being able to go
into the developer tools
and see a timeline, and
watch exactly, like, ah.
This bit of code was
running right here,
and that's why I
dropped those frames.
We also want to make
it possible for people
to use whatever languages
or tools they want,
and still be able to
deploy on the web.
So we want to make Emscripten
code run really fast so that
you take C or C++ code and be
able to deploy that on the web.
We want people to be able to
write more structured programs
than you can in
JavaScript with Dart.
We want that to be able to
run across all browsers.
We just released Dart
1.0 a few days ago.
And with Dart to JS, you
can deploy it everywhere.
There's even a number of
cases where the Dart to JS
will actually produce faster
code than idiomatic JavaScript.
Because, I mean,
a lot of you here
are very good
JavaScript developers.
But for many
JavaScript developers,
it's very easy to accidentally
shoot yourself in the foot.
And by having a more structured
language compiled down
to JavaScript, you can often
get much better performance out
of it for most programmers.
In addition, we have portable
Native Client inside of Chrome
so that you can run native code
even faster than Emscripten
or asm.js-style code.
But you can also take
that code and run it
in other browsers
with pepper.js.
So you can take all
of the pepper APIs
and emulate them
on other browsers.
And as I said earlier, the
V8 team is working very hard
to take asm.js-style code
and make it run really,
really fast in V8.
Lastly, I talked a lot
about the advantages
of the web-- of
this linkability,
ephemerality,
composability, being safe,
and it being indexable.
And these are not things
that you typically
get with native
mobile applications.
But we realized that
some people might
want to be able to ship a native
app but use web technologies.
So we've invested a lot in
contributing to Cordova, which
is the open source
project behind PhoneGap,
so that you can take what
you've built on the web
and package it up and deliver
it as a mobile application.
You don't get those core
capabilities and advantages
you get by being on the
web, but at least it
allows you to leverage
the same technology
stack for developing
across different platforms,
including the web.
So lastly, I would like to
thank you all for coming here.
There's a lot of exciting talks
over the next couple of days.
And so this is a
great opportunity
to connect not only with all
the other developers here
in the room, but with a lot
of the Chrome developers
from Google.
And we look forward to
hearing back from a lot of you
over the course of
this conference.
We'll be following along on G+.
And so let us have it.
Thanks.
[APPLAUSE]
