[MUSIC PLAYING] SAM DUTTON: Hello,
and welcome to Krakow. And for those of
you from Krakow, thank you for welcoming
us to your beautiful city. Here is actually a
photograph from the last time I was in Krakow, when
the temperature was like minus 20 degrees Celsius. So I've been really happy to
see some sunshine in Krakow. Anyway, my name is Sam Dutton. I'm a Developer
Advocate for the Web. Worked for Google
based in London. I'm here today and tomorrow
with a bunch of other Googlers, like people working on Chrome
and some really brilliant web developers. So please, if you have
questions, come and chat to us in the web area. Come and check out Lighthouse
and all the other stuff that we've got. I wanted to cover
some of the stuff from the keynote in
a little more detail and really give an
overview of the web today. I want to give a high-level
overview, but also some of the business reasons
why I think it makes sense to build progressive web apps. So we're going to
go into that now. And there will be sessions
later with more technical detail about building for the web. So like you heard earlier,
in a word, the web is big. There are now over 5
billion devices out there that can access web content. That is incredible, I think. You get this instant
broad reach with the web. And this didn't happen
because of luck. Yeah, the web is this open,
decentralized platform. There are no gatekeepers. Websites get massive reach. Users get low friction,
which is great. And I think we've all
seen charts like this. Mobile computing is at the
heart of this revolution. There's been this explosion
of computing on mobile. And you know, we now
use more mobile devices than desktop
computers, and so on. And this is a really interesting
challenge for developers. We've also reached
this point now-- I've particularly noticed
this in some regions-- where a lot of
users coming online are actually mobile-only. They never use a desktop
or a laptop device. And again, this is a really
interesting challenge for the web. Of course, on mobile,
most users spend most of their time in native
apps rather than the web. Apps seem to be
more predictable. They have great
re-engagement features. All this good stuff
in native apps. You think, well, I could cut
my presentation short right now and say, well, go
and build native. We could all go home. There is a flip side
to this, though. And I'm sure you understand
this, particularly app developers in
the audience here. App usage is highly
concentrated. Users tend to only
use a few apps. They see native apps as a big
commitment to device space and time and cost. Native apps are
engaging, but only a few are worth installing. Now, based on a recent study,
something like the average user is installing like
zero apps per month. This certainly does not
mean that users are not using native apps. But by contrast
from our own data, something like the
average mobile user visits around 100
sites per month. This is the power of URLs and
the ephemerality of the web, particularly to
meet one-off needs. I think one way to think of
the difference between native and web apps is on
the capability access. Native apps start up quickly and
reliably when you tap the icon. They tend to work offline. When do you ever
open a web browser when you know you're offline? That's just not what people do. Native apps can use
push notifications, sync in the background, and so on. And they've had access for
some time to device sensors, like microphones,
cameras, and so on. By contrast, the web
has been seen to be-- I don't know, like safer, more
respectful of privacy, maybe, but it hasn't had
those capabilities. I think, what if we could
add those capabilities so the web could
get that engagement and meet those UX expectations? We could have the
best of both worlds. And this is what progressive
web apps represent. A user experience that's good
enough, like integrated enough, so it can actually earn a
place on the Home screen and the notification tray
without having to give up that reach to get that. This is really the core point. Progressive web apps is really
just a term for radically improving the quality of the
end-to-end user experience. We want to learn
from native apps. We want to take what's
best from native apps and bring that to the web. And this requires being
really honest about what matters to users. So in order to do
that, I think we need to focus on four things. We need to make the web fast. We need to make web
experiences better integrated with device hardware
platforms and other apps. And we need to make sure that
web experiences are reliable. And we need to
keep users engaged. So I want to look at each of
those properties in a little more detail. Now, from a really
good native app, users do not expect janky
scrolling or slow load performance. And you know, the web has had a
bad name for slow performance, I think. Particularly on mobile. And by performance, I
mean in-page performance scrolling and so on, as
well as load performance. And in a sense, an app has
to be kind of invisible. Users should not be aware
that they're actually loading an app. It should just work. And we want to see
that on the web. And this isn't just a
kind of abstract goal. We all know that time
is money on the web. This data from SOASTA shows
just how much that is true. After only like a little
more than 3 seconds, something like 20% of your users
will abandon the experience. And you know, there's evidence
that users are getting shorter attention spans. That this is getting
tighter every year. So a couple of other numbers. It takes the average web
page on mobile 19 seconds to load on a 3G connection. You know, that's really
bad for everyone. For every 1-second
delay the page loads, we calculate that
sites lose something like 7% of conversions. That's really bad for business. You know, we really
need to fix this. I think one of the
side effects, thinking about this on the web
of the reach of the web, is that you do not have
control where users start in your experience, like
which page they hit first on your site. You can't dictate like
you can with a native app where users start. So we've been
working to make sure that wherever someone
starts, they start fast. Pages need to be reliable
and fast from the first time that users load them. And to fix this, last year we
started working on a project Accelerated Mobile
Pages, known as AMP. This is an open source project
to create super-fast web pages. We all know that accessing
pages on the mobile web can be painful. And AMP is a framework to ensure
that content loads reliably. We've been able to prove
this over the last year. AMP pages load, on average,
in less than a second. On average, they use less-- like 10% less data than
compared to non-AMP pages. This is particularly
important for users where data is expensive, where
people are really constrained by their use of data. A good example of this. Doing great work, actually,
the Weather Channel. They've seen like a four times
increase in click-through rates-- it's fantastic-- on
their AMP articles and into their main site. That's up from something like
21% to 90% click-through rates, which is great since launching
the beginning of this year. So instant access to
information is really valuable, like this example of
these giant hailstones. Weather.com, they get that. And I think AMP is really
paying off for them. Now, AMP was originally
focused on publishers and static content. The format has been
constantly evolving to support really
critical new features and verticals like e-commerce. Merchants can now use
AMP to build really interactive and engaging pages. And a lot of e-commerce partners
have really started to do that. Last summer, eBay
launched all their product listing pages on AMP. Over 15 million pages reliably
load in less than a second. And now, they're launching
product pages worldwide on AMP. And that means that users
can go from searching on Google to actually
buying something on eBay in milliseconds. So in total for
AMP since launch, there have been over 2 billion
AMP pages, 900,000 domains. And yeah, every
second, 58 AMP pages are released into the wild. That's incredible. If you want to learn
more about AMP, check out Ben Morris'
presentation after lunch today. We have an AMP training session
tomorrow afternoon as well. As you'll find out, AMP
and progressive web apps, they work really well. The two attitudes to
building for the web work really well together. To build sites that,
as the slogan goes, to start fast and stay fast. So as well as
speed, users expect this app-like integration
with their device hardware, the operating system,
and other apps. You know that feeling when you
use a really great native app? You get that tight connection
right from the start. You can focus on what
you want to achieve. And you kind of forget
that you're using an app. I think that users,
they shouldn't have to feel like they're
reaching through a browser tab in order to access your app. In fact, the users
shouldn't have to think about the fact
they're on the web. They're just using their
phone, or their tablet, or desktop to complete
whatever is their task. So just one example of this. This is like dear to
my heart because I've worked on this stuff, is media. In the past, it's been
really difficult to get media working well on the web. People have felt like they had
to consume media in an app. This just isn't
the case anymore. We worked really
hard across platforms to make media more effective. And also, just to ensure
that video and audio content can be included in the
page and it just works. We've got great
new APIs to build robust, secure, and
efficient media experiences that can even work offline. This is a particularly
important problem to solve. Over 70% of internet traffic
now is actually video. That number is increasing. It's incredible. All the browsers need
to ensure that we can get this really
complete solution across different browsers
for the mobile web for media. So we have these new APIs
that are improving capability for media on the web. I would really
recommend checking out-- this is Paul Lewis's
fantastic progressive web app for media publishing. It's at bit.ly/pwa-media. And it gives you
adaptive streaming, pre-caching for faster loads. Orientation change gives
you instant full-screen. You get custom controls,
thumbnails, and so on. And for me, I mean,
this is amazing. This is amazing to see
this happening on the web. It's a beautiful app. I really recommend that. So the technology is
opening up the web to even more platforms,
even more experiences. With the web VR API, we get
this incredible expressive power on the web. This is enabling
companies like Within to bring this really incredible
experiences from VR creators. Creators from around the
world directly to the browser. Companies like SketchFab
bringing these amazing VR scenes. I believe they have
like 1.5 million of these that you can explore. This would look really
wonderful if everyone here had a VR headset. It would also look a
bit weird, I guess. But anyway, you get a
sense of what is possible. And looking forward
to the advent of augmented reality, this idea
of connecting information data with the physical world. We think the web is going to
play a pivotal role there as well. Think about integration. I just wanted to touch
on new capabilities also for e-commerce. Mobile commerce is a huge deal. Last year, mobile
commerce was worth-- just in the US, was worth
something like $123 billion. You can imagine what the
figure is for Europe. This is, actually, a fundamental
challenge for the web. So the web has gone mobile,
but conversions are, we calculate, something like
one third lower on mobile than desktop. And this makes sense. It's hard to enter
data on a phone. And we need better integration. Because e-commerce is really
all about removing friction. Browsers have worked to
improve this with Autofill. And that's great. Today on Chrome, we have
something like 9 billion forms and passwords, which are
auto-filled each month. This is good, but
it's not enough. The Payment Request API goes
a step further than this. This is a W3C
standard for browsers to present a standardized
interface for users to enter payment
and shipping data. So the users get a
consistent, secure experience and developers don't have to
reinvent the wheel every time. And this works from
like a tiny boutique right up to some
e-commerce giant. Sites can call the
Payment Request API, like in the screencast here. The browser then securely can
store emails, shipping, credit card data on file for the user. So the browser can provide
a merchant with all this in one form pre-populated,
again, to reduce friction. So you can see that
the web has become this highly-capable platform. It's tightly integrated with
underlying operating system, hardware capabilities. Users need better
reliability as well. At present, users have
not come to expect the web to work without a
network connection. And most of us don't even
bother to try when connectivity is slow or intermittent. We really need to
change that perception. Web apps must be reliable. When a user taps on
a Home screen icon they expect it to load
instantly and reliably. Launched from the Home screen,
apps should never, ever show the downasaur. Thinking back to the '90s,
when the web was growing up. Does anyone know what
this actually is? Maybe not. Maybe a few people. For those who have
never seen it, this was like how we
got online, probably from some monolithic desktop
machine somewhere in the house. In the basement or
something, with this modem. You had to put the whole
house into online mode. I remember like back
in the day, 56K to me would have been really
exciting because we'd grown up on like 14K. And you know, what
you had to do was like yell to the whole house,
like don't pick up the phone, or that would kill the
connection in the middle of a download, or whatever. And of course, in
those days, we knew that we were online because
nothing else was happening. Now, we think of the
internet connectivity kind of more like a utility,
like gas or electricity. Almost like oxygen, you know? Users are coming to
expect connectivity to be available all the time. And we've become used to this. And this means that
seeing this downasaur is just not an option. You imagine if you
went to a native app and you got some kind of
system-generated error message when the device was offline? You'd just think, what? This is crazy. But we've become used
to this on the web. We have to deal with this. We have to solve this. The other problem is that, as
we know, mobile phones, they're not just online or offline. It's not a binary state. The existence is kind of
Schrodinger's cat state. Is it on? Is it off? We get these problems
with cell connectivity, like you've got four bars
here, but it turns out you do not have a
working connection. So it's not just no connection
that breaks our experience. It's slow or intermittent
connections that can really be worse for users. And like I say,
mobile apps should-- as much as I love the
cute, little downasaur, it should never show him. No other app will show this. And so in order for web apps
to really earn their place on the Home screen, we
need to make them reliable, even when the network
is not reliable. And this is where
service workers come in. I just wanted to ask, who
has heard of service workers and feels like they have a
pretty good idea of why they're game-changing for the web? Oh, that's great, actually. That's really good to see. For those of you who don't
know about service worker, the traditional web model has
been like you type in a URL, or you click on a link, or
a bookmark, or whatever. And the browser
goes to the network, looks up the web server,
and retrieves the resources required for a page. Now, the browser, of
course, has an HTTP cache. But if the network is
down, you get a visit from our friend the downasaur. And the user
experience, obviously, can be even worse with
flaky connectivity. So a service worker is
a client-side proxy. Acts as an intermediary between
your app and the outside world. You write a service worker in
JavaScript in a separate file, kind of like a web worker. And after the first visit, the
service worker is installed. And after that, it can
intercept and respond to events, like network requests. And the service worker
then can use the cache API to cache resources and
work with storage features, like IndexedDB for
data, and so on. And that enables you, the
developer, the site owner, to decide when to use the cache
and when to go to the network. This is extremely powerful. Like I said, service
workers are acting like a proxy between your
app and the outside world. Now, this means that they can
also handle incoming events as well as outgoing requests. Push notifications are
a great example of this. Push messages are received
by the operating system via whatever push service
it uses, and then passed on to the browser. The push event from the
browser then wakes up the relevant service worker
that subscribed to it, and then that can
call a push handler. The really nice thing is here
that the browser does not even need to be open. This is fantastic for
reducing usage of memory, CPU, battery, and so on. I think this kind of capability
for engagement/re-engagement is where progressive web apps
are really coming alive. So of course, a
truly engaging app needs to kind of go beyond being
just functional and reliable. And ensure that the whole
experience is delightful and it makes it
easier for the user to do what they need to do. Really good
experiences on the web need to have the
right capabilities, use them at the right
time in a beautiful way. Twitter is a great
example of this. They launched a progressive
web app in spring this year. They had noticed their
web traffic was growing. And yet, the experience
wasn't great. So they set out to
redesign their mobile web experiences of PWA. And this is a great
place to look to see what can be done on the web. They had three goals in mind. They needed to cope with
slow, or flaky, networks. And they had to
consume less data. This is critically important
for a global service for all their users. And Twitter needs to work
well for a huge variety of smartphones, from
high-end to low-end. Some of which have tiny levels
of storage and limited CPU, and so on. For those of you who have
got a phone in your hand, you can check this out right
now, mobile.twitter.com. You'll see how fast and
smooth the scrolling is. Now, performance is a
huge priority for Twitter. They can access photos
and videos for uploading. You can see a tweet
going on here. And of course, the web can
now send push notifications. On Android, these appear
alongside native web app notifications. And this is a fantastic
re-engagement tool. I believe Twitter are
now sending out something like 10 million push
notifications per day, which is incredible. What I really love,
though, is that Twitter can deliver this experience
at a fraction of the size compared to native. You can see here the difference
that a progressive web app can make. So how can a PWA be so small? Well, when you
download an app, you download everything that
the app needs, which is why you get those data sizes. But the PWA can leverage the
resources of the browser, and then progressively
install more assets and data as required. And again, this is
a huge deal for we need to remember that for a
lot of users in many regions, their constraint is actually
from data costs as well as connectivity. Need to remember that
and bear that in mind. So as you might expect, Twitter
is getting great metrics for their PWA compared to their
previous mobile experience. And they're getting something
like a million daily visits users coming from the Home
screen icon, which is great. We're seeing the same
from a company called Ola. This is like India's largest
ride-hailing service. It's interesting. Their mission was to build
mobility for a billion Indians. An incredible scale. They started, just
like six years ago. The co-founders, they would
actually drive customers if a cab didn't show up. Now, they're up to like
a million rides a day, something like that. But that was not enough
when their target was like billions of users. What they needed to do
was to target tier 2 and tier 3 cities. These are like smaller cities,
20 to maybe 100K in size. A lot of users in those
cities get flaky connectivity and are using
cheaper smartphones. And it makes sense
for those people not to actually install apps
because of limited storage and the cost of data. So with Ola, their
progressive web app, you get smooth navigation,
which is great. You get this
fantastic, robust UX. And you know, great
functionality, even on low bandwidth. So since launch,
what they've seen is that things are going well
for them in the tier 2 cities. But what's really
nice is that they're seeing great conversions up in
the tier 3 cities, up like 30%. This is a fundamental point
that progressive web apps are allowing them to address
new audiences and new market. One stat I really like
from them actually is that like 20% of
their progressive web app bookings are actually
from users who had previously uninstalled the app. This is fantastic. It's worth remembering that
a lot of users, because of device, memory
constraints, or whatever, are regularly uninstalling apps. And you don't get
that on the web. If you want to find out more
about what Ola and Twitter have done, check out their case
studies on Web Fundamentals. I'll be sharing a link with that
at the end of the presentation. Just briefly, getting back
to the topic of engagement. When a user visits
your site, you can now prompt them to add
the site to their Home screen. Great example of
doing this really well is Trivago,
the travel site. They have like progressive
web app for something like 55 domains globally. Incredible. And as you can see,
the Add to Home Screen process here works
really, really well. And then, this app is now
like tightly integrated with the Android device. It's displayed in the app
launcher, just like other apps. And it's part of Android
Settings, which is great. But given this focus
on Android, you might be wondering, well,
is this progressive web app thing-- is this a Google thing? And the answer is no. A big part of what
makes progressive web apps so successful is
that multiple browsers are committed to them. Developer adoption is
obviously growing, but so is browser support. Opera, Samsung,
Microsoft, Mozilla are on board with the
features I've discussed. And of course, you
might have also heard that service workers are in
development for Safari, which is great. But progressive
web apps are really about the attitude to building
web experiences that work well for all your users. So you can count
on reaching users that are important to you. The word "progressive" is-- it's in progressive web apps. It's not there by accident. We need to focus on this
end-to-end user experience. And that can give a
really dramatic impact to your business. Even with users who
can't experience the full power of
progressive web apps because they're using a
device that does not support some particular feature. A great example of this,
the luxury cosmetics brand, like Lancome, they
built this great PWA. But I want to call this
out, because something like 65% of their users
are actually on iOS. What they found
was that when they built their progressive web app
and used the kind of techniques that we're advocating and you
can learn more about today, that they were getting
much higher engagement. And this is fantastic. It just means that this is
a good investment for you, no matter what the browser
mix is that you're targeting. Gartner has recently
published a report advocating that PWAs should be
part of a mobile development strategy. And this idea that
progressive web apps will begin to replace
general-purpose apps. So I know this sounds
great, but I also know that reality sinks in. You go back to your
day job and you think about building
a progressive web app. It could seem like
this huge undertaking. But implementing
these techniques need not be this monolithic
refactoring task. I want to talk about
some ways to get started. First and foremost,
you need security. HTTPS is table stakes
for progressive web apps, to keep your users and
your business safe. This is not just for sites
that work with sensitive data. You Any site can be a target
that's vulnerable for attack. And the green lock indicates
that that site is secure, is a secure connection between
your users and your site. And this means three things. The user must be able to trust
that the site is actually you, not a scammer or a phisher. They must be assured that no
one can tamper with the content. And then, they
need to be assured that no one is listening to
the interaction between them and your site. The web has this tremendous
reach and lack of friction. But you know, keeping users
safe is absolutely paramount. And for this reason, HTTPS is
mandatory for many of the APIs now on the web, including
service worker, geolocation, camera access, web
RTC APIs, and so on. So once you've moved
to a secure domain, three approaches to moving
to a progressive web app. You can build from
the ground up, you can start with
a simple version, or you could focus
on a single feature. Just want to have a
quick look at these. So starting from
the ground up makes sense when you're going
through a redesign. If you're starting
from scratch, well, you can build that appness right
in from the start using service workers and so on. OLX is a great example of this. They launched their
site for classified ads in India, providing communities
with its great markets. And they've seen fantastic
improvement in time to interactive, drops in
bounce rates, and so on. And they wanted to
reengage with their users, including their
mobile app users. And they've had fantastic
results with that. And again, they built
this right from scratch. But of course, not
everyone can do this. Starting from scratch
is not realistic. An example of a different
approach is Air Berlin. They built this
post check-in app where you can get all the
details for your flight. They weren't able to just
start everything from scratch. Check out their stuff. They've done a
beautiful job of this. And you can get your boarding
pass, all those details, even when the app is then offline. Now, the final strategy
is just to define-- is to pick on one
particular strategy. Weather.com have
done a great job with this with notifications. I would really, really
recommend-- they've rolled this out in like 60 languages. If you're looking at
UX for notifications, I would really recommend you
look at what they've done. They've done a beautiful job of
this within a PWA experience. And they've seen great
results from this. A million opt-ins within
a month, and so on. So check out their work. I'd thoroughly recommend that. So I would look at these
different approaches if you're thinking of building
a progressive web app. Come along to Ava's
talk about how to get started with moving
from website to PWA later. It's an excellent talk. And she'll talk more
about how you can get started with that stuff. So we're seeing great
momentum, different verticals with travel
companies on the web. We've seen publishers,
partners like Forbes. Forbes has seen like
double in user engagement since the launch of their
PWA, which is fantastic. And e-commerce sites as well. Fandango, Alibaba,
Rakuten, and so on. They've all invested really
successfully in progressive web apps. And also, like newer services,
like ride-sharing companies. This was just a sample
of some of the people who are actively working
with PWAs and new web APIs. Check out their work. They've done beautiful work
on building great sites. And they're just finding
ways to start down this path, investing in the mobile
web and getting down this path of building
progressive web apps. So I think progressive web
apps for these companies, it's giving them
reach and capability. The ability to target new
audiences and new markets, which is incredibly
exciting on the web. If you want to learn
more about this, we have some great
sessions coming up. Some good presentations
today and tomorrow. We'll have, like I say, a lot
of expert web Googlers on hand to answer your questions,
solve your problems. I'd also strongly recommend
the training sessions from Sarah Clark and her team. These are really, really good. And really good people
running those sessions. And if you want
to find out more, please check out
web fundamentals, like case studies, resources,
at developers.google.com/web. Most of all, please feel
free to come and talk to us. Any of the Googlers-- there's
a bunch of web Googlers here. We're here to learn what
you're doing on the web, what we can do to make
the web better, and to help you build better
experiences for all your users. Thank you very much, and
we'll see you around. Thank you. [APPLAUSE] [MUSIC PLAYING]
