Harry 
title
[MUSIC PLAYING] SPEAKER: OK. Let's take this back– right back– to the 1820s. This is Babbage's
difference engine. It was designed to tabulate
polynomial functions, such as logarithms. And there was one machine, one
app, hand-built, hard coded. Now to get a new
app, you had to get Babbage to design a new
machine and, in fact, wait nearly 200 years for
someone else to build it. So move forward 150 years or so,
and software looked like this. Big programs needed
10 disks or more. CDs and then DVDs were actually
a revolution at that point. MapPoint could be
bought from a store. And this had pan and zoom. And it completely
changed trip planning. Web-based maps at that time
couldn't do anything like that. So let's move
forward a few years. Google Maps happened. Hey, pan and zoom on the web. And it worked on any
computer, not just one that you spent 30
minutes installing on. When capable, the web's
distribution model really wins. Now raise your hand
if you use Google Maps on the web on desktop. Yeah, thought so. What about mobile? Well, that's
different, isn't it? Who goes to a browser to
get to Maps on the phone? The hardest problem with
software is distribution.
Anyone who's ever worked
in IT will understand this. So how does this
play out on mobile? It's true that users
are spending most of their time in native apps. Reengagement features
keep users in native apps. Push brings users back,
even when the app is closed. And home screen icons
maintain visibility. But usage is highly
concentrated. It's a winner-take-all
situation. App developers often spend
more for distribution than they earn back. So if the native ecosystem isn't
going so well, well, why hasn't the web been more disruptive? Here's one way to think of
the differences between web and native– the capability access.
Native apps have the ability
to start up fast and reliably. They can work offline and
use push, sync, and sensors. Now the web, in some ways,
is safer, more respectful of privacy, but doesn't
have those native features. If we add another
access, reach, you can see where the web succeeds. According to a recent
comScore study, the average user installs
zero apps per month. Well, Google data shows
that mobile users visit around 100 sites per month.
This is the power of URLs. They meet one-off needs. Now what if a web could
meet those UX expectations? This is what Progressive
Web Apps represent– PWA, for short. Web apps are finally
able to earn their place on the home screen and
in the notification tray. And they don't have
to give up reach. What do those PWA
experiences look like? Well, here's "Washington Post." Their Progressive Web App loads
in a tab like any other site. If you use it a few times,
the Add to Home Screen prompt is shown. If you tap it, well, the browser
lets you know it's added. The icon is now available
from the home screen. And if you tap it, the app
starts with a splash screen and runs full-screen like this.
Tap to get to the task
switcher, and there's the Progressive Web App,
alongside other native apps. What they've done is to make
it incredibly easy for users to get at what they want. So what was missing
from the web? First, we needed reliability
and performance on par with native apps. And next, we needed to be
in the notification tray. Lastly, once
trustworthy, we needed to be on the home screen. So let's talk about performance. We all know that time is money. And this data shows just how
badly bounce rate increases with load time. Other studies show that
after just three seconds, 40% of users will
abandon a web site– 40%. But what if you didn't need to
traverse the network every time for every asset? What if you could
intelligently cache assets locally and reliably? That's what service workers do.
Service worker enable
you to implement caching with the cache
API, not just by hoping to rely on browser caching. This means that after
the first visit, sites and apps can
be reliably fast. OK, that's huge. But what about the first visit? The AMP project from
the Google Search Team aims to address the
web obesity epidemic and provides reliably fast
web components for first load. These AMP components
are much faster to load and less data
hungry than non-AMP content.
But what if you could
combine the two– fast first load with reliable
performance subsequently? We can do that by combining
AMP and service worker. This is where AMP meets PWA. Here's an example. New stories on the
"Washington Post" are super fast to load,
because they use AMP. Once a story page is loaded, the
site installs a service worker, and assets are
cached intelligently.
Now that provides reliable
speed that native can't touch. Want to try out
Progressive Web Apps? Well, there are great tools
built into the Chrome DevTools. For Progressive
Web App developers, Google engineers have
also created Lighthouse. This gives you an
extension that reports on how your PWA is
doing, as well as command line tools you can
build into your workflow and production processes. There are loads of
other new capabilities coming to the web– too
many to talk about here. WebAssembly and WebGL
to unlock games, media capture and stream
encoding for user-generated content, and many more– but two particular APIs
that are shipping this year will change many kinds of apps– Web Payments and
Credential Management. Now the first is Web Payments. This is a standards-based
way to enable easy checkout on the web. Web checkout using
fiddly forms is a pain. Mobile makes this even harder. Entering data via
on-screen keyboards is difficult and insecure. The Web Payments
API reduces this to a prompt, a
confirmation, and done.
If Android Pay is supported
by a site and phone, it can be even easier. Another transformative API is
the Credential Management API. This simplifies
the whole process of managing identity on the web
and enables one-touch login. Here is kayak.com using
Credential Management, synced vice Smart Lock
with a single tap. On sites that support the
Credential Management API also allows automatic sign in for
users that previously visited. To sum up, PWAs are
reliable, fast, and engaging. The feedback we get from
talking to many developers in many regions boils
down to two key questions. Why is this important,
and how do we get started? For why it's important, let's
look at the overall market. Here, we'll focus on
some high level metrics– reach, acquisition,
and conversion. Let's talk about reach and how
we're seeing overall mobile web audience growth.
Now we have data for Chrome– one billion monthly
users on mobile, and this was just 400 million a year ago. And Chrome is only
four years old. On average, Chrome
on Android users visit 100 sites per month. Let's drill down
to site level data. Now this comScore data compares
reach of the top 1,000 sites and apps. Here, you'll see that mobile web
reach is two and a half times that of apps. So when you're able to deliver
a better experience to a wider audience, this makes
a compelling case.
And you're likely see similar
numbers on your own site. It's worth gut checking your
own site traffic numbers and understanding
the traffic breakdown between app and mobile web. Anecdotally, we've
heard that sites say that mobile web
traffic ranges from 50% to as high as 90% of
mobile traffic in total. So this data is great. We're seeing growth
in mobile web. And that reach is more
than double of app traffic. The next question– are there
real businesses at scale seeing success with
these investments? Well, we've been working hard
to provide real life examples so that you have proof points.
Removing barriers to
entry means that users are much more likely
to try out a mobile web property than an app. The mobile web sees
many more unique users. However, as you can see, native
apps capture users' attention. Native apps currently get
a lot more user engagement. Can we have both? Another data point to
look at is how easily users are able to discover
and experience your service. Acquisition is
about more than just getting users to your site. And that sometimes
means paying for users. Here's an example. Selio is a local
marketplace site for buying and selling goods. They built a Progressive Web
App and saw similar engagement numbers as their app. However, they found that
user acquisition cost could be up to 10 times
cheaper for their web app compared to their native app. The web has incredibly
low friction. And as a result, it's also less
expensive to acquire users.
Now I know you must
be thinking, well, that's what the marketing
team worries about. But hey, if you're trying
to build a business case, you have to think about these
multiple forces at play. Conversion is about
getting a visitor to become a more frequent
user of your site and, in some cases, getting a
user to complete a transaction. Ali Express, based in
China, is one of the largest e-commerce players globally. With their PWA, they saw
massive uplift within days. They saw a 74% increase in time
spent on the site and two times more pages visited. For them, the number
that really matters is whether users actually
convert, complete transactions. Ali Express saw conversions
go up across the board. You might think that
many Progressive Web App features don't work on
Safari and that this wouldn't help with users on iOS. Well, it turned out that
that wasn't the case at all. Using the PWA approach
to building for the web, Ali Express saw an 82% increase
in their conversion rate on iOS. And Progressive Web
App does make sense.
And focusing on the
end-to-end user experience will still have a dramatic
impact on your business, even with users who can't
experience the full power of Progressive Web Apps. Ali Express already
has a mobile web site, and they decided to supercharge
it with PWA features. And they got terrific results. Here's a quote from the director
of mobile at Ali Express, which emphasizes that investing in
a great mobile web experience benefits all users, no matter
what platform they're on. To understand why
this is important, think about the big
pie of potential users. You want to increase
potential reach, reduce acquisition costs,
and improve conversion rates.
Once you put the
figures together, the web starts to
look pretty good. So how can you get started
with Progressive Web Apps? The technologies
can be intimidating. Do you have to convince your
team to do a complete overhaul? Well, the short answer
is, definitely no. It can be complex to
introduce new technologies, especially at larger
companies with complex organizational
structures and sites with legacy
code and architecture. Think about this as
an ongoing journey to invest and build on the web. Sometimes a site is about
to go through a redesign, so starting from
scratch makes sense. This enables you
much more easily to build in Progressive
Web App design patterns– in particular, to take
advantage of all the power of service workers. Now Konga is a major
e-commerce player in Nigeria. And they decided to
start from scratch, calling their site KongaEZ
pronouncing it "easy." They had to deliver a full
end-to-end web experience that was as fast and reliable as
their native apps for iOS and Android. They need their web experience
to work offline for catalog and for checkout functionality. And they focused a
lot on minimizing data consumption, which is
critical for their users.
Comparing data usage
to their native app, initial load took
up to 92% less data. And data usage to first
transaction was 82% less. Now of course, not everyone
can take the Konga approach. Starting from scratch is
oftentimes not realistic. Another approach is to build
a simple version of a site– for example, to improve on
a specific section or user journey. For AirBerlin, it wasn't
possible to do a site-wide PWA, so they focused on the
post-booking experience. They needed to deliver a fast,
engaging, reliable experience. And their users at the
airport require quick access to itinerary details,
boarding pass, and destination information. They leveraged caching to
solve this problem giving them load times of under a second. After a passenger
has checked in, they can access
their journey details and boarding pass, even
without internet connectivity.
The "Washington Post" built a
simple version of their site. They put together a simple
Progressive Web App demo using their top stories feed. The goal was to show what type
of user experience is possible. And they focused on speed– 80 millisecond page load
times with their PWA. You can see their live
public demo at WAPO.com/PWA. Newsroom staff and executives
at the "Washington Post" were really excited to
see this new experience.
And as a result, they're
now actively evolving their demo PWA to make it the
core mobile web experience. Another strategy is to define
a specific feature to test. Pick one thing that you
can have high impact with. Now this is likely to be the
case at really large companies. The Weather Channel
team has been interested in Progressive
Web App technologies for quite some time. They needed to prioritize
based on what they believed would be the highest
impact for both their users and their business. They decided to focus on a
single feature with Web Push first. Weather went big with
a single feature, rolling out globally
in over 30 languages. Users on their
mobile web app can subscribe to multiple
types of notifications, just like their native app. That's how they got started on
the journey to building a PWA. Booking.com is a
large travel company. And it's hard for them to
make a lot of big changes. However, they understood
the importance of Progressive Web Apps. They're data-driven, so
it was critical for them to work in small steps to
try new features one by one, test them, and learn. So when you think
about proposing a path to integrate these
technologies, it's helpful to think about these
alternative approaches.
Build from the ground up,
start with a simple version, or just focus on
a single feature. Different paths can make sense
for your users and your site. We've been really excited
to see incredible momentum across the globe. Here's a sample of folks
shipping or actively working on PWAs and the new web APIs. With these early
adopters, we've seen that every site has their own
way of investing in mobile web and starting down the path
towards Progressive Web Apps.
So now it's your turn. [MUSIC PLAYING].
