Claire Corlett

Fish Food, Fish Tanks, and More
Keynote by Darin Fisher, VP of Chrome (Chrome Dev Summit 2015)

Keynote by Darin Fisher, VP of Chrome (Chrome Dev Summit 2015)


DARIN FISHER: Welcome everyone. Welcome to Chrome Dev Summit. It’s really awesome to
be here with you all. We have over 300 of you here in
Mountain View joining us live, as well as many people on the
live streams, really fantastic. I also want to give a special
shout out to the live stream viewing parties that we’ve
organized in Montreal, Waterloo, London, and Paris. And to our friends
joining us from Paris, I think I say this for
everybody, our thoughts go out to you. Thank you everyone
for being here today. I just want to
take a quick moment and reflect on where
we’ve come with Chrome. So Chrome has been a product–
we have had Chrome out for a long time on desktop,
but on Android, actually, it’s only three years old. It was in 2012 when we first
brought Chrome to Android, and we’ve been working
very hard to make it a much better product on mobile. To make sure that we are
building the best web platform we can. To help developers reach users
on mobile through the web. A lot of work’s
gone into Chrome. A lot of work’s gone into
making the web better. We’re going to be spending
time today and tomorrow talking about that. Chrome Team’s also put a lot
of work into the web view. And for users on
Lollipop and later, it’s the web view and Chrome. And I’m very pleased
to say that web view and Chrome both auto
update together, and that’s a fabulous
accomplishment. So we’re very excited
about the things we can do to make the
web ecosystem stronger, as well as to make
the web work better in the context of native apps. So I put this
slide up last year. Last year we had 400 million
users on Chrome on mobile. We were very proud
to share this, and this year I’m pleased
to announce that actually the number has doubled. We’re up to over 800 million
users on Chrome on mobile. [APPLAUSE] So we’re excited about this. Obviously we put a lot
of work into Chrome. It’s great to see users
liking the product, but I think it’s
really exciting. Even more so because it means
web developers get access to this set of users with
a modern, up-to-date web browser that Implements modern
features on the platform, and it makes for a very
large addressable population of users for web
developers trying to reach users on mobile. So we’re going to get
into some of that, but first I want to spend some
time talking about the web. And we talked about
this last year, but I think it’s
worth highlighting. So the web has
many, many virtues, things that are great
about the platform, but one that really stands
out is that it’s low friction. And so, it really stands
out that it’s low friction. And what I mean
by low friction is that, to a user trying to
engage with developers, when it comes to the web
platform, interactions are just a tap away. A user taps on an add, a
user taps on a search result, a user taps on a URL in
a tweet, and they end up taken to a website. What does that mean? They’re landing on the front
door of the web developer. The web developer
now has a chance to interact with that user,
present some experience, allow the user to interact
with their service, develop a relationship. There’s no install friction. This is really powerful. It means that the
experiences you can build can be presented to
the user right away. There’s no need to get them
over some install hump. And so we’re all about trying
to make this work better, and I want to spend a little
more time digging into numbers. So earlier this
year, in June, there was a comScore report
that was announced. And it had this sort of
numbers that, on average, users have about 25 apps
installed, and that they interact with every
month on their devices. When we look at
Chrome browsing data, we see that on Android, users
are opening over 100 sites every month. What does that mean? That means that– well it’s,
not only four times larger, but it means that the
users are interacting with four times as
many developers, if you think about it. And this reach is really
interesting, really interesting if
you’re a developer. And to put this into more
perspective, of those apps that users are interacting with
each month, 80% of that time is dominated by just
the top three apps. This is also really interesting. And in that report, they
looked at monthly unique users, they looked at the
amount of traffic that these top sites
and top apps are seeing. And so comparing the top 1,000
apps to the top 1,000 sites, they actually see this
kind of disparity– that there’s actually a lot
more unique users reaching those top 1,000 sites than the
corresponding top 1,000 apps. And this reach is
really powerful, again. And it makes sense, given the
low friction nature of the web. Just a tap away to a
whole new experience. Just a tap away
to the user being engaged with the developer they
never interacted with before. And the other fascinating
thing that they reported on is that this
disparity is growing. In fact, the mobile
web traffic is growing at a much faster
pace than app traffic, by the factor of 2x. Again, looking at
the top 1,000 sites compared to the top 1,000 apps. And then when you zero in
on just the top 50 apps, you see that it’s only the
top 12 of those apps that have a corresponding
site, that actually enjoy more traffic
on their native app than on their website. And these are the
YouTubes, the Instagrams, the Pinterests of the world. Makes sense, but it’s
not very many apps that enjoy that sort of benefit. And so earlier this
year, Flipboard put together and launched a
whole new responsive design, mobile and desktop
web experience. And they reported an
astonishing number, that they saw a 75% increase
in their active user base on mobile, thanks to
targeting the mobile web. I think this is
really impressive. It makes a lot of
sense, though, again, given the reach, given the low
friction nature of the web. Now this is a great quote. “All great apps need to
be on the web, especially the mobile web.” We totally agree. Chrome’s focus is
helping you all be successful at doing this. And so, I think it goes
without saying at this point, and it’s obvious,
that the web should be critical to your
mobile strategy. Some of the strongest,
smartest businesses today are targeting the
mobile web, and you can see how that plays out. And so from Chrome
Team’s perspective, we’re trying to make
the web work better. This means figuring out
how to make the web really work well in mobile. But I want to call
attention to the fact that the web is not just Chrome. So although we have 800 million
users on Chrome on mobile, and that’s a very
large user base, there’s a lot more
users on mobile. And we really care about
the web being great, and that means that
everyone should enjoy a modern web browser, a
modern web platform, on mobile. And so we’re very committed to
working with standards bodies, working with other
browser vendors, working with web
developers, working with others in the community
to build new web standards, features for the platform
that are built to last, that other browsers
are going to adopt, so that we can move the web
forward in a very positive way. We’ve been having a
lot of success here, and we’re getting only better at
working on building standards. I’m very excited about that. And so I want to take a moment
to take a drink of water, but just a second. I want to talk about
the things we’ve done to make Chrome better,
make the web platform better, and it’s really
along these axes. The axes of reliability,
performance, and engagement. And let’s just get
into reliability. So when I talk
about reliability, I’m not just talking about
does it crash or not? I’m really talking about, can
users count on the web working? Can they count on the mobile web
experience being good for them? And when you think about mobile,
what are you thinking about? You’re thinking about
unreliable network connections, flaky network, inconsistent
access to the internet. And as a web, we’re talking
about web apps, well, web apps are deployed
over the internet. So they’re reliant
on the internet, and so this is an issue. But I want to say
something crazy, which is that I think as
a developer’s targeting the mobile web, we shouldn’t
assume a consistent network connection. We shouldn’t count on that. With this in mind,
we really set out to try to build enhancements
to the platform that would make this the case. That it would let
[INAUDIBLE] developers to reach users, even in the
presence of really poor network conditions. And our answer to this is the
Service worker API, something we talked about last year. And I’m pleased to say
that this has been deployed in Chrome for some time now. And developers are
creating great experiences on Service Worker. And we’re going to talk
more about that a lot, throughout this
whole presentation today and tomorrow. But the Service Worker, in a
nutshell, so you have context– it allows a web
page to designate a piece of script that would run
outside the context of the web page. And that script has the ability
to serve network requests on behalf of your pages. It can control both resource
fetching and caching, and gives you the
kinds of control you need to create a
robust experience offline. Just for instance, I understand
that The Verge is live blogging this event today. And their live blogging app
actually uses a Service Worker so that it can be robust. I think that makes
a lot of sense. You can imagine conference
Wi-Fi is not always so hot, and being able to
have access to such a tool in the presence of a poor
network makes a lot of sense. So I encourage you
to check that out. Another example that’s really
great to see is The Guardian. So The Guardian did something
quite simple, actually. They deployed a Service Worker,
so that instead of a user experience being like what
you see on the left there, Chrome’s error page when
you’re offline– instead of a sad dinosaur, what you see
instead is a crossword puzzle. So they’re able to provide an
experience that’s interesting when you’re offline. I think that’s a clever use
of Service Worker, and not terribly complicated to
add to an existing web app. So another thing that’s
really great– like I said, we’re seeing a lot of
use of Service Worker, and and over 2.2 billion
page loads per day through Service Worker. This is great, and
I want to call out that this is pretty evenly
split across desktop and mobile. And for those in the
know, this number does not include the Service
Worker used by Chrome itself, or the new tab page. The new tab page is
actually a special variant of the Google home page
that uses Service Worker. We actually use it in Chrome
so that we can make sure that the new page is always
fully functional whether you’re online or offline. Now performance, I want to spend
a little time digging in here. We put a lot of work into
making the engine faster, and a lot of focus has
been on understanding characterizing performance. And when I say
performance, I don’t just mean micro benchmarks,
JavaScript micro benchmarks. JavaScript performance
is important, and I don’t just mean
traditional page load performance. What I really mean is the
things that users really care about–
responsiveness, interaction. When a user touches
your phone, and they tap on something on
your application, it should be responsive. It should indicate
that it’s listening, that something is happening. Animations should be
smooth, et cetera. So we’ve taken to characterizing
performance with a metric that we call RAIL. And I want to introduce this. We’re going to talk a lot
about this today and tomorrow. And RAIL stands for Reaction
time, Animation time, Idle time, and Load time. So let me just detail
this a little bit. So reaction time–
the idea here, the guidance is,
within 100 milliseconds your application should
respond to the user input. It should indicate that
something is happening. If it can’t complete
the task then a progress indicator is present. Something so the user
understands that I got you, I got this, I’m working on it. Animation time, this is
the classic 60 frames per second, the gold standard. This means there’s only 16.67
milliseconds to get work done, and that includes the work
that the browser needs to do. And so we’re very focused on
making sure people understand how to achieve good
animations in the presence of these kinds of constraints. And what that really
means is making sure your idle work is
managed properly. And our recommendation
is that idle work is chunked up to the units
smaller than 50 milliseconds. This means that
the idle work that maybe is happening
in the background isn’t interfering with your
app’s ability to be responsive. We’ll talk a lot more
about how to manage that. And then, of course,
the classic load time. In here we set a very
aggressive goal of one second. You think about it, this is
even– the very first time a user navigates to your page,
being able to achieve a load time like this is important. It doesn’t mean your whole
application has to load, but it means that enough
of your application should have loaded
so that you can start interacting with the user
and start responding to them. So you can start showing
progress according to what your app needs. And I think this is
really important. There’s, of course, tools
like Service Worker and such that allow you to
manage your caches, and make sure that subsequent
loads are always fast. But even the initial load should
be fast, and tools like HTTP2, and new protocols
like Quick, these are all designed to help here. So put it all together. These are the kinds of metrics
that we’re really focused on. The kind of user experience
we’re really focused on. Things that make sense to users. And we’re going to
spend a lot of time helping web
developers understand how to achieve
good RAIL metrics, but also, as Chrome Team
we’ve put a lot of energy into making the engine
faster along these same axes. So this has been a
big focus for us, as well, just looking
at Chrome itself. And so under the hood,
I’m pleased to share some of the stats, some of the
improvements that we’ve made. There’s been a ton of
work, and this is just capturing a few items. A lot of focused work went into
V8 and the Garbage Collector. And on the whole, we’re actually
reducing JavaScript memory by 10%. But on sites that use
a lot more JavaScript, actually, the
reduction is even more. And this just comes from
being a lot smarter about how we’re managing the
Garbage collection. And doing all this
cleverly at idle time, so that we’re not
interfering with the things that the page needs to do,
it’s all very important. We’ve also made a lot of
strides on startup time, and power reduction. Power reduction in particular
on Mac has been a big focus. Really delighted about that. So there’s just
some great stats. And moving on, I just
want to call attention to the AMP Project that was
recently launched by Google, Accelerated Mobile Pages. And to put this
into perspective, the way I look at it, is it’s
a great, great prepackaged way of doing static content
on the web that achieves great RAIL performance. So, following this,
it’s like a guide RAILs to help you achieve
a really good performance on the mobile web. So I’m very excited by that. And Polymer is a
more general solution for achieving great
performance on the web. Again, not only have we focused
on making Polymer faster, but also Polymer
includes a whole bunch of elements that are
designed to enable you to have a very easy
time creating web apps that are interactive, deal
with large data sets, and so on in a
performant manner, achieving great RAIL metrics. There will be a lot more
talk about Polymer later on. And so engagement is the last
area of focus that we’ve had. And I want to call
attention to what I really mean by engagement, which
is re-engagement– helping users get back to your site. So it’s one thing that they
have an easy time finding in the first place,
but how can you help them reengage
with your website? And the two main
areas of focus here are really helping you
get onto the home screen, and helping you reengage
through push notifications. These have been features that
we’ve deployed, launched, and I want to talk
more about them. So the one stat about
home screen that I just want to call attention
to is that we’ve seen a real rise in the
efficacy of home screen icons. So in other words, we see a
lot more traffic, 79% increase in launches coming from home
screen icons to websites. And this all makes sense,
it’s what you expect. You expect it to be an
effective access point, and indeed that’s true. So one thing that
Chrome does is, if a user engages
with a website a lot, we’ll actually
promote to the user that they might want to add
that site to their home screen. Now this is a caveat that the
site has a Service Worker, has a manifest, and so on. But here’s an example of
such a site– Sumo.jp. It’s a real estate
site in Japan. They have a native app, they
have a website– about 70% of their traffic
is on the website. They integrate it with
ad to home screen, and they get this
kind of experience. And a user who’s using the
site has an easy time putting the site onto the home
screen, and it just works great for
users of the site. Push notifications, this has
been a big focus of ours. I think everybody
understands what it is, but it’s about allowing
you, sites, web developers to push notifications
to Chrome that will then be represented to the
user on behalf of your site. So on the left here
you see Facebook, who rolled out push
notifications to everyone, asking the user to accept push
notifications from Facebook. And then on the
right there, you see on the home screen of
Android a notification from Facebook, and below that
you see an Ebay notification. Ebay is also working on
integrating with push notifications in Chrome. This is very exciting. And, in particular, Facebook,
a couple months back, had their @Scale
conference where they had this presentation. They were talking about
the mobile web and so on, and the work that they’ve done
to improve the Facebook.com on the mobile web. And they had this slide up that
I just want to read to you. It says, Mobile Web Matters. Mobile First cannot
mean Native Only. And we totally agree. This resonates absolutely. That’s great to see this. And another great
example of how effective push notifications can
be– Beyond The Rack. So this e-commerce site
deployed push notifications and saw some really great stats. Of the users who
reengage with their site through the push
notifications, they spend, on average, 72%
more time on the site. And they spend 26% percent
more money on the site. This is pretty great stats,
and it’s not surprising, because you can
imagine that they’re able to deploy very targeted
and timely notifications to the users. And we’re seeing quite a large
volume of notifications flowing through Chrome–
up to 350 million push notifications
every single day. Just a month ago
this was 250 million, so it’s growing rapidly. And across the world we’re
seeing about 2,300 sites using push notifications, and
this is also growing rapidly. Which is great to see. So I feel like all of these
technologies put together can really transform
the mobile web and transform people’s
expectations of the mobile web. The idea that mobile web
experiences can be reliable, can be resilient to
poor network conditions. The idea that they can be fast,
fluid, interactive, responsive. The idea that engagement
can be strong. The idea that you can
be on the home screen, that you can have
push notifications. The experiences you can
create on the mobile web are just profoundly better. And I think this is
very exciting to us. We’re really excited about
the kinds of experiences people are creating
with these technologies, and it really reminds me back
to well over a decade ago when, at that time,
pages were very static. People tapped on links and
a whole page would reload. Think of MapQuest– you panned
left or right in the map, and it reloads the entire page. And what did people discover? They discovered Ajax, they
discovered XML, HTTP requests, and so on. That they could use
these technologies to incrementally update
pages, and with that ushered in a whole new decade’s
worth of innovation on the web. And I feel like
some of the stuff that we’re talking about here
with Service Worker really has the chance, the
opportunity to really transform people’s expectations
on the mobile web in a similar fashion. And I’m very excited about that. And so as we’ve been
talking a lot about this, we’ve taken to calling these
web experiences that people create progressive web apps. So I just want to
introduce this name because we’re going to
be talking a lot about it throughout the rest of the
conference, and beyond. So Progressive Web Apps. I think this name works
because if you think about progressive
enhancement– these websites you build to take
advantage of Service Worker. Well, , they work better
on browsers that support the Service Worker, obviously,
but the experience still works on an older browser. So your investments are there
and you add the new features, and the application’s
progressively better. Or you think about a user who’s
interacting with that website more and more,
and the experience is progressively
better as the user adds the experience the home
screen, or the user enables push notifications, the
experience that they can get is progressively better. Or you just think about
the fact that developers can create progressively
better experiences overall. So very excited about
progressive web apps, and the kind of
technology– the kind of experiences that people can
create using the technology that we’ve developed. And I just want
to call attention to one such example,
which is flipkart.com. And they are one of the major
e-commerce players in India. One of the things that
folks may be familiar with, is that earlier this
year they famously turned their mobile website into just
an ad for their native app. But shortly after that
I think some developers there got very excited about
rethinking their mobile web experience, and looking at
features like Service Worker, and some of the other work
that has been going on in the web community. And they started rebuilding
their mobile web experience around these technologies. And I’m very excited to
share with you flipkart.com, which just launched last week. So I’d like to roll
the video now, please. So I’d like you to pay
attention carefully as you watch this
video here, and notice some of the animations
and the interactions. And notice how smooth they
are, and how fluid they are, and how quickly the
applications experience. Even when the data’s not
there, it’s changing state, it’s showing progress. Something is happening in
response to your interactions. It’s always very
responsive to you. And now we’re going
to tap on this, and Chrome is prompting
to add to the home screen. And you see the icon
appear on the home screen, and then when we launch
from the home screen what we actually see is
a full screen experience. Gone is the location
bar of the browser. So we can flip
back to the slides. And I just want to call
out some of the tweets that we’re seeing. I mean first off,
this experience is very delightful
to people, and you see some of these tweets. For example, if
you’ve not checked out flipkart.com
in Chrome you’re missing out on the
future of the web. Flipkart Lite is the fastest
web application I’ve ever seen, or flipkart.lite is working as
smooth as butter, even on 2G, awesomeness. Awesomeness, indeed. I really agree, and I encourage
you all to check it out. It’s really impressive. And Flipkart’s actually here. They’re going to give
a talk later today detailing and getting into
some of the details of what they built. It’s very exciting. And so Flipkart’s
a great example of a mobile web
app that has really taken to heart these things. They’ve built a very
reliable experience, a performing experience,
an engaging experience. And in a marketplace like
India, where network conditions are so poor actually, the
fact that it works so great is really impressive. The fact that they’ve built
an experience that not only is resilient to poor network
connections, 2G connections, but they also built an
experience that initially works well even on such networks. It’s very, very cool to see. And so I think the theme here
is that Chrome Team is working really hard to try
to help you all be successful in the
mobile web, and we’re going to get into a lot
of details about what we’re doing along those lines. We have a lot of
different talks lined up to share with you
on how we’re trying to help you be successful. And, in particular,
I want to call out, in addition to libraries
like Polymer and Amp, that I showed before, there’s
also tools like DevTools. There’s a lot of
work going there to try to help expose
RAIL metrics, and so on. But also documentation efforts,
like web fundamentals and MDN. We actually contribute
a lot to MDN to document all the new APIs
that are on the platform. Very excited about
that, and I just I want to emphasize
this education point by giving an example. So right here I have a stat. So we did an experiment, we
studied the effectiveness of Chromes autofill, the
autocomplete feature. So as you’re filling
out forms, Chrome will suggest the contents
of those forms for users, and actually, this feature
increases people’s form submission rate by 25%. It’s pretty darn cool. Turns out, though, that
Chrome isn’t guessing what to put in the fields, right? And sometimes– I think
we all have experienced this– Chrome gets it wrong. Browsers get it wrong. And the user has to
go and frustratingly fix up what Chrome or the
browser put into that field. Turns out there is a feature of
HTML5 which developers can use. They can add an autocomplete
attribute to all the input fields, and they
can tell the browser exactly how to interpret
those input fields. And this makes these
Auto Complete– the Autofill features–
perfect, right? Because the developer knows best
what the intent of those fields was. the The browser
shouldn’t have to guess. And so with education,
we have the ability to get people to realize
that they can make changes to their websites that
would dramatically improve, for example, the chances
of a user completing a form submission, and I think
that’s really interesting. So I want to call attention
to another thing, which is today Google and
Udacity are teaming up to offer a web nanodegree. This is very exciting. So it’s all about helping
developers learn the best practices on how to create. We leverage all the technologies
that we’ve been talking about. The ingredients that
go into creating a great progressive web app. Very excited about this,
please check it out. And so what’s next? Well, as I was saying, we
have a lot of content for you today and tomorrow. Today is going to be
all around detailing how to build
progressive web apps, getting into tips and
techniques on that, as well as detailing
and previewing some of the new features
that are coming. For example, the Bluetooth API. And then tomorrow
is going to be all around performance and tooling. And then looking out
further, it seems like we should do this more often. So we’ve actually decided to
hold this conference twice a year. So we’ll see you again in six
months, next time in Europe. Thank you very much.

12 comments on “Keynote by Darin Fisher, VP of Chrome (Chrome Dev Summit 2015)

  1. About a month ago there was a great deal of chatter in the technology press about the possible convergence of Android and Chrome. This keynote was an opportunity to deny, confirm, or otherwise elaborate on the relationship of those two Google products. Although this talk was informative, this issue was not mentioned.

  2. Darin, how much do you use the actual web experience? you don look too much excited about ir, c'mon man is a new way to see the world for all of us you should look much more exited about it! sell it to me I'm an iphone user and I want chrome! convince me why to!!!

Leave a Reply

Your email address will not be published. Required fields are marked *