Good morning.
All right.
I want to spend a moment to help reintroduce the mobile web.
At [? DN, ?] at Google we love the web.
The web is in Google's DNA.
Google, as a company, grew up with the internet
along with everyone else.
We want the web to be first class because there's
a lot of intrinsic values about the web
that we really care about.
The web offers a frictionless experience.
You can just tap a link and you're there.
Experiencing what that link led to.
You don't have to pause and think about,
make decisions, do you trust it, do you want to install it?
You can just move into new experiences effortlessly.
The web is also discoverable.
It's all just built on top of URLs.
A single URL has a lot of power because it
represents its content.
But I can do quite a lot with it.
I can store it so that I can revisit it again, of course,
but more powerful, of course, is sharing.
Links are shared by all sorts of means.
And with those links, a single app or document
can link into the state or another section of any other.
And that link is just a single tap
away from absolutely everyone.
The web is everywhere.
Interoperability is this beautiful thing
that's let the web flourish because it's
a shared, open platform, with multiple implementations.
That's the platform.
That platform is on every device and that single link
can be accessed by everyone.
And yet, you might have heard some less than favorable views
on the mobile web.
Not everyone is convinced.
But respectfully, we disagree.
Its had its rough times, and we may have missed the boat
a few times, but I want to share what we've done about it.
The mobile web is very much alive.
The reality is today, the web, is multi-device.
And the count of users accessing it on devices is growing.
And more than just increasing the number of users,
the web itself is turning to be more mobile.
In just eight months, the number of sites
that are mobile optimized has risen
from 47 percent to 60, 68, even.
Things are improving fast.
But the question is, why isn't this happening even faster?
Why aren't all sites great on mobile?
And what's holding back developers
from delivering fantastic experiences on the web?
So, about a year ago, developers were
asked what stops them from building with HTML 5?
And cited were items like performance, APIs,
difficulty in building rich UIs, and immature frameworks.
And we heard three key pain points come out of this.
Speed, integration, and polish.
At Chrome, we take these challenges seriously
and we've been putting a deep investment
into the mobile web and investments
into addressing these specific pain points.
So I want to share an update of what
we've been doing in the past six months to make the web better.
First thing that we can do is just make the platform faster.
We want to improve the speed of the most common interaction,
the tap.
For a long time there's been this 300 millisecond delay
on all taps.
The browser is waiting for a double tap to happen.
We [INAUDIBLE] remove this delay entirely,
making a dramatic impact on the input latency
that all users have.
Since then, Firefox and Safari have done the same.
Now we focused on other input latency actions
like, flinging the page, and made good improvements
there as well.
The JavaScript engine inside of Chrome, V8,
has long been a leader in performance.
It's speed on mobile is a large focus for the team.
And we're happy to report strong gains in our execution speed,
reduction in GC latency, and a lower memory
footprint on mobile devices.
It's our goal to get the browser out of the way
so that you can have full use of the main thread.
This is a look at the same frame of animation.
The second one is taken six months later.
We've been making core improvements
to the rendering engine, blink, inside of Chrome.
These improvements have spanned across the entire architecture.
From the compositor, to style engine, to layout, to paint.
You can see on there we've moved to this particular frame
of information from 18 milliseconds down
to 10 milliseconds.
Now, 8 milliseconds difference may not sound like a lot,
but we've made this improvement so that all web content doesn't
animate at a steady animation, but we can get 60 FPS.
On the whole, we've improved the speed of animation 75 percent
and scrolling 35 percent.
All this faster than what we had in 2013.
We're committed to helping you get 60 FPS on the mobile web.
So speed was identified as a pain point,
and we've delivered marked improvements in Chrome
on mobile.
Now that we're making experience faster,
we need to give you more control over the platform.
So this means new APIs and features.
One of the most fundamental features is service worker.
You can think of it as a successor to app cache,
and it is, but it's more powerful than just that.
It allows you to build offline first experiences.
Service worker can manage resource,
fetching, and caching on your behalf.
And for users, it's a huge win too.
Because they can get content faster
and they can finally have proper offline
first experiences delivered from the web.
Service worker also unlocks a number of high value futures.
Push notifications is a great example.
Time and again, we heard from.
You want proper push notifications on the web.
So they're on the way and they're
being powered by service worker.
Other capabilities like background sync and geofencing
are also coming, sitting on top of this powerful primitive.
The web platform has long been monetized, right?
E-commerce kind of changed the way that retailer is done.
But in the shift to mobile, things
got a little bit more difficult.
Keywords vanished so input is a bit more difficult.
Requestautocomplete is a new standard.
Let's show quickly what this looks like.
Ah, just kidding.
Requestautocomplete allows you to build off
of the HTML5 standard autocomplete attribute.
And you can dramatically improve the process
of filling out a checkout flow and other forms.
We've seen a great improvement on mobile
where a user can come through checkout flow
far faster than dealing with their thumbs
on text fields all day.
Now WebGL, of course, offers great,
hardware accelerated, 3D content on the web.
And I want to show this demo to you because it's really nice.
If I come over here to my phone.
You can Google this yourself, just
look up Samsung Racer WebGL.
I'm going to click into it.
And this experience, which is built with WebGL and also
Web Audio.
So it loads up.
There we go.
And we have a nice 60 FPS experience of WebGL,
here on my phone, on the web.
And I pan around, too.
The panning is done dynamically with Web Audi API
so I really get into the experience.
And you can see, we're not missing frames,
this is a full slick 60 frames per second.
All right.
So, while the browser needs extra features
so that you can deliver these great experiences,
we also want to help users get closer to your content.
So you saw in yesterday's keynote the redesign recents.
So your web tabs move and merge along with recent apps.
This allows you to move easily between context,
whether it is web or app.
So we heard you when said you needed a more complete feature
set and we've been delivering on that.
Now no matter how web apps are built, appearances matter.
The web deserves to look and feel gorgeous.
In yesterday's keynote, you saw a material design.
A unified vision for visual motion and interaction design
across different devices.
Polymer has an implementation of the this
that you can use no matter what sort
of device it is, laptop, tablet or phone, whether you're user
is using a mouse, track pad, or finger.
The web's got the same great looks
and we're bringing a beauty back to the web with material
design.
I'm going to come over, we're going
to take a look at one of the applications built
with this powerful design promise.
So this is an app, the quiz app, called Topeka.
Its built with Polymer.
So it's built with the next generation of the web.
But beyond that we made sure to deliver a great experience.
So I'm going to come down here.
And as we move around there's a lot of things happening.
We have simultaneous animations and slick 60 FPS animation.
I'll come back and we'll go down to profile.
And as I tap in on the input selection,
you can see a nice effect coming off.
You can see a similar effect, too,
when we come in to science and nature.
And as I'm selecting-- Hm, what is
the only bird that can fly backwards?
Albatross?
Pelican?
I'm not sure.
What is the answer?
Hummingbird, yes.
The nice thing here is that we have a paper ripple
effect coming off from the placement of where
I put my finger.
Yes!
Thank you.
Thank you very much.
All right.
One last stop over in TV and movies.
Select the actors who played James Bond.
I know this one, that's good.
Dalton?
Yes.
Niven?
All right, yeah, that's good.
Yeah, I think that's it, right?
But we have this nice check box effective coming in on the web.
Aw.
All right.
Well that was great.
I'll come back to my slides.
Zero points, all right.
We're excited to have strong UI components and UX
paradigms for you to build experiences with.
Now we know that implementing all the most awesomest
features in the world doesn't matter
if the platform is hard to write code for.
So we've been investing in develop ergonomics
and tooling to make it easier for you to build.
Polymer is a framework for building the next generation
of web and it builds on the power of web components.
Now we've been working on this for a few years.
And the engineers who work on Polymer
work in conjunction with those that work on the web platform.
And this collaboration has worked out really well
and has benefited everyone.
It's great because the web platform
gets to benefit from these great web developer centric use
cases.
And meanwhile, we can make sure that the implementation
of Polymer can stand the fast path of performance.
This here's a look at Polymer designer.
This is a drag and drop UI for constructing
fast prototypes and other things.
Not only can I drag and up all these components together,
but I can instantly dive into the code beneath them.
Now we care a lot about making sure
that the ergonomics of building with Polymer is smooth.
Using web components is just HTML.
So take this a Google map element.
Once I important it, I can use it
very naturally just with attributes.
Meanwhile, the element itself encapsulates and hides
its implementation so I can just reuse it easily.
But as you're developing you need
tools to give you strong insight into the performance
of your app and a great expectation of what it's
going to look like your mobile users.
So we've been working hard to bring you
a great mobile development and debugging experience
with the Chrome Developer Tools.
Including rich device simulation features,
powerful remote debugging, and rich instrumentation
to understand how to improve performance.
So whether you're working with Shadow DOM,
ES6 promises, we want to make sure
that the Chrome DevTools are behind you
helping you could iterate quickly.
And you can move fast, focus on delivering a great experience,
rather than focusing on the technology.
Beyond the DevTools, there's two more sites
that are critical in helping you deliver on the web.
PageSpeed Insights will run your site
against a battery of tests.
Help you identify not only how to improve your page load time,
but also UX concerns.
Like sizing your tap targets to be appropriate size
and also improving text readability on small screens.
This is web page test.
It recently added great mobile device support.
So which is an invaluable tool in helping
you optimize for the critical path.
So take something as fuzzy as slow page loading.
Web page test helps you zero on in exactly what's holding you
back.
Here we're looking at the film strip few.
The film strip view is a great look
at correlating the network waterfall,
along with the visual load of the page,
so you can identify what's blocking
and how to make things faster.
And so, there's a lot going on in web development
and we know that keeping up with all the best practices of web
development is a full time job.
So how do we address responsive design, responsive
layout, images, navigation, hamburger menus, rich input,
rich media.
At web fundamentals we've documented
some of these answers into living gods.
We're hopefully making the job of building for the modern web
a little bit more sane.
And taking the right first step is key.
So we've shipped web starter kit just last week.
It is a boilerplate for building multi-device sites.
It sets you on the right path with smart defaults.
Some of the things inside web starter kit,
it has a complete set of styles and components and layouts.
It's style guide is driven by components.
So you can help craft your visual identity
with your designers.
And tooling for build process and smart developer workflow
ergonomics, like device synchronization and LiveReload.
So to recap, developers assets for an even faster runtime,
even better ergonomics and tools, and more beauty.
We've had our heads down to make big strides
and we hope over these two days of I/O
you've seen some of this.
But we can't do it without you.
The web is open, the web is a conversation,
and it's a collaboration, and we need your help too.
Actually, let me take a moment and tell you
about a guy named Dominic.
Dominic is just like a JavaScript developer,
just like you and me.
Dominic, a while ago, was taking a look
at handling asynchronous operations.
He ended up writing a blog post.
This blog posts he was saying there's
a lot of people doing work inside JavaScript libraries,
but he made the case for saying, the way that we're handling
asynchronous events should be standard.
We should be able to have all these of libraries interop
with each other.
This blog post begat a test suite.
The tests suite begat 30 compatible interoperable
implementations.
One of which ended up in the Dom sped.
Soon enough, with Dominic's help,
the promises has landed in ECMAScript, the language.
So going from a blog post to landing a major feature
that a number of web APIs are built is a big feat.
And not everyone is Dominic.
I'm certainly not.
So what can we do?
First, we just want to hear from you.
Anything that you can tell us on why
it's difficult to build for mobile, what we can do for you,
what features you need, what's slow.
Let us know.
File bugs, be active on mailing lists,
just give us the feedback so that we can serve you well.
And this also goes almost without saying,
but build responsibly.
It's our awesome opportunity to build
these frictionless experiences on the web
to all users regardless, regardless
of what screen they're looking at.
The number one thing you can do to make your site better
for mobile users is just to make it faster.
With DevTools, Polymer, and the other resources
I shared, you have a whole host of tools
not only to keep you on the fast path of performance,
but help diagnose and address when you fall off that.
And, for a lot of users, their first experience
with your brand is your mobile website.
So they'll tap on a link that was shared with them maybe
via Facebook, or email to them, and they got it
over IM, found on a pin board, or maybe
they just tapped on a search results.
But they arrive via the mobile web.
Now once they're in, they might eventually
find their way to a naively installed app, and that's fine,
but they came through the mobile web.
And it's your responsibility to deliver success on that place.
So this morning I shared with you
how we're making Chrome faster from input latency
to JavaScript to massive improvements
in the core rendering speed.
We've looked at powerful capabilities
like Service Worker, push notifications,
requestAutocomplete, and integrated web and App Recents.
We're making the web beautiful and enjoyable touch.
And we want to make sure that it's also a joy to build.
So we've invested in Polymer, the DevTools, and other tools
to keep you on the right path.
We've done a lot of work, but we're just getting started.
Chrome is committed to the mobile web.
Chrome and Google are committed to improve the web
for developers and for your users.
We're not done yet, but you can get started today.
Join us.
Let's help deliver on the promise
and the power of the mobile web.
Thanks.