Get Down to Business: Why the Web Matters (Chrome Dev Summit 2018)


[MUSIC PLAYING] AANCHAL BAHADUR: Hi,
everyone, I’m Aanchal. And I work on product
partnerships for Chrome. My job is to evangelize
the web to all of you and be an advocate
for your feedback as Chrome continues to build
exciting new things that you just heard about from
Ben and [? Dion. ?] Sure, I play that role. But if you look harder, I really
am the unicorn that all tech companies are looking to solve. I’m a millennial. Happy being friends with
my phone, my laptop, my noise cancellation
headphones, Fitbit, Kindle– you name it. So in this particular
instance, I went on a vacation, unlike millennials, with my mom. I grew up in India, and I
go back three times a year to visit my dog, Rafiki. And my family is
usually there too. And he usually needs to be
held that way 24 hours a day. And so someone needs to stay
back– had to be my father. And so my mother and I drove
up to the hills of Landour. I know it sounds like a location
from the “Lord of the Rings,” but it actually is a
town in Northern India. And it’s famous for great
weather, good desserts, and after this talk,
for network connections. So quick show of
hands, how many of you have experienced
coffee shop Wi-Fi? Expected. I, for on– always looking
for that perfect spot on a couch in a coffee shop
solving the world’s problems on my laptop. How about airplane Wi-Fi? Wow, quite a few of you. But yeah, definitely more
frustrating than coffee shop or conference Wi-Fi. What about instances when
you’ve paid for Wi-Fi, and you’ve got no Wi-Fi? Seemed like the entire
population of Landour was either on 2G
or largely offline or, like me, pointing
my phone at network towers demanding the internet
like it’s my human right. Even in an offline situation,
the web came to my rescue. I had offlined a few articles
on the best bakeries in Landour, how to find more
food in Landour, and the web came
to my rescue there. So this map from the Chrome
User Experience Report shows you 4G densities
across the world. And it looks like in
the US and some parts where it’s dark
green is really good. But think about the last time
you were on your commute, in the BART, or anywhere, on
the train, reliable, fast 4G is still a privilege. And this isn’t really a US
or an emerging-market story. The web needs to work
for everyone at any time everywhere. These instant-loading
experiences for everyone make the web like
that crucial friend who’s actually there for you
when you need them the most. But historically,
despite its reach, the web has not met
user expectations when it comes to mobile. A lot of you are
changing that narrative, are shaping it real-time–
adoption of new web technologies like Service
Worker are playing a role in changing this. Investment in web performance
literally pays off. These companies
across the world have been investing in
web performance and have actually
seen business impact. LinkedIn Lite saw four times
increase in job applications by just building
a progressive web map using caching strategies. Wayfair, like you just recently
heard from Ben and Dion, have also seen 10%
conversion increase. And ClickBus in Brazil is
also seeing sales go up. So it literally pays off. So I looked for that exact point
of intersection that lights up a millennial’s brain and
makes them really happy. And I realized that it
pretty much comes down to music, coffee, and photos. Music on Spotify,
coffee from Starbucks, and photos of the latest fashion
trends or whatever– dogs, if you’re me– on Pinterest. I still remember my
first few conversations with these companies. And the people that
I actually spoke to are here today to tell you
the valuable lessons they learned building on the web. It hasn’t been easy. It’s taken months and
months of testing– some failures, some learnings,
but ultimately, they’ve all seen business impact. And we’re glad they’re
here to share it with you. So without further
ado, please join me in welcoming Rizzo from Spotify. [APPLAUSE] MATT RIZZO: Thanks, Aanchal. [MUSIC PLAYING] Last year, Spotify had
a burning question. Would having a mobile web music
player allow us to grow faster? Today I have the answer, and
I’m here to share it with you. I’m Matt Rizzo, and
I’m a product manager at the growth team at Spotify. As a growth team, our goal
is to drive sustained growth of users around the world. Within this greater growth
team, my team’s specific focus is on using the web to
capture and validate growth opportunities. Over the next few minutes,
I’ll share with you how we decided if we should
invest in the mobile web and where we are today. So let me take you back to 2017. At this time, there was no
way to listen to Spotify on mobile web. We already had a robust
web experience on desktop that was working on Windows,
Chrome OS, and Mac OS. But on mobile, we
had no such option. And frankly, we were
unsure if we should. Things seemed
pretty good for us. We had been growing fast. And our native apps had
impressive retention figures. But every day,
millions of people visited our artist, album,
and playlist links on the web. And we’re hit with a wall. Each one of those users
had to download the Spotify app to listen to music. Our hunch was that this
hard-download wall was hurting our ability to grow. In fact, it was turning
users away from Spotify. So to explore this
question in more depth, we headed to Brazil. Why Brazil? Well, we saw two things
that were important to us. One, we had a ton of
web traffic from Brazil. It was a growth market for us. And– [TELEPHONE RINGING] Hey. And a significant amount
of our users in Brazil had less than a gigabyte of
storage space on their phone. This left these users
in a constant state of prioritization. Should I keep this
app on my phone? Or should I delete
it to make way for this app I really
need right now? So after talking to
more users in Brazil, we realized this was
a real challenge, and it was affecting us. This challenge caused people
to either delete Spotify or to not download it
in the first place, effectively, making
it impossible for them to use
Spotify on their phone. We also learned that there
was another type of user that could benefit from Spotify– those who were
unfamiliar with Spotify. Imagine you’ve never
heard of Spotify, and you get a link sent to
you from one of your friends. You click that link
to listen to a song. And you end up on a page. This page prompts you
to download an app. Downloading an app is
a tall order for you if you’ve never even
heard of Spotify. Why should I download this? I just want to
hear this one song. So because of these insights,
we had a strong perspective that we should have a
mobile web experience. And there were two users that
we thought we needed it for. The first is people
with low storage space who can’t download our app. And the second is people
who don’t know Spotify and are not familiar
enough to actually decide to download Spotify. So we started experimenting. We started experimenting to test
our belief that the mobile web would unlock growth. We started really small. Our first tests were
fast and simple. What if we gave our existing
traffic, a limited player from which they could play just
one song, before downloading the app? Guess what happened when
we launched this test. We saw first-day
plays increase by 25%. This was huge. That was the number of
users who play within 24 hours of visiting our site. After seeing this, we knew
there was enormous demand for a mobile web player. So we took the next step. Now that we had strong data
to back up our intuition, we went a step further. We wanted to test two
universes against each other, one universe in which we had a
mobile web player and then one in which we didn’t. We wanted to do this
because we wanted to understand if there would
be an incremental benefit to us going in and
investing in the web. So we built a full experience. And this full experience
would allow for more immersive sessions on the web. And then we exposed it
to 50% of our visitors. This experience included
three key Chrome features. First, the media session
API, and this allowed users to control playback from
the notification tray; second, PWA install for Quick
Access from the home screen; and finally, we had
protected content support to ensure artists were
guarded from piracy. Guess what we saw
from this test. We saw a 54% increase
in day-one plays, and even a sustained 14%
increase in active users all the way through to day 60– so real retention. We also learned about
the power of the web as a reactivation driver. So 30% of the logins
we were seeing were coming from users
who had not been active in the past 28 days. Our mobile web player was
bringing churned users back onto the platform. We had one concern though. And our concern was that
launching a mobile web experience would actually
cannibalize our app downloads and hurt those impressive
retention figures I referenced. But we’ve seen the opposite. When people have access to
a robust web experience, they’re actually more likely
to download the Spotify app. So to summarize, we had a hunch
that the app download barrier was turning users
away from Spotify and hurting our
growth potential. By building a web
experience, we made Spotify accessible to more users
and have seen sustained growth on both the web and
in our native apps. If you are on the fence
about investing in web, I would start by understanding
what barriers are keeping you from reaching your customers. After you’ve done
that, then start understanding how the web
can remove those barriers. And finally, start
with small tests to validate your hypothesis
that the web can unlock growth. Just like Spotify,
you might find that the web is a powerful
way to reach your goals. Now, I’m going to
turn it over to David to talk about how Starbucks
meets their customers where they are– on the web. [APPLAUSE] Good luck, man. DAVID BRUNELLE: Thank you. [MUSIC PLAYING] Good morning. My name is David Bernelle. And my team builds
the digital product used by Starbucks
customers in the US in a number of
international markets. And our job is to extend
the Starbucks experience beyond the four walls of
our stores to the devices that our customers
have in their hands. In early 2017, we
asked ourselves, how can we use the web to
give our customers the best experience possible? That question led us to
launch a PWA later that year. And I’m excited to share some
more of that story with you– the why, the how, and some
of what we’ve learned so far. Before we started,
we knew a few things. First, millions of customers
were using our native apps every day to order ahead
and pay in our stores. Second, the
Starbucks native apps had a higher number of daily
active users than our website. But third, the
Starbucks website had significantly more
monthly active users than our native apps. In fact, our website
was reaching 6 million more people every
month than our IOS app. The opportunity for us was huge. If we could provide
a better experience to these 6 million
users, we believed they’d have a more meaningful
interaction with Starbucks and that that would be
great for our business. It was important for
us to build a web app that was as full-featured
and pleasant to use as our native apps. That meant that it had to be
reliable, fast, and engaging. Our customers tend to
use higher-end devices, but they experience a wide
variety of network conditions. We have stores all over– suburban shopping
centers, basements, and office buildings, and
airports, for some examples. Customers at these
stores might experience 3G, unpredictable Wi-Fi
like captive Wi-Fi portals, or have no connection at all. When a customer walks into
any of these locations, they need to be able
to open their app, scan their barcode to pay,
and be on their way quickly. We addressed this by using
some of the web platform’s capabilities– JavaScript, HTML, CSS,
and other static assets are cached locally. Don’t pay too much attention to
the code you see up on screen. It’s there to illustrate just
how little code is actually required to implement runtime
caching and precaching thanks to Workbox. User-specific data is then
encrypted and stored locally with IndexedDB. This means that, when a
customer opens up the PWA, she can expect it to work. Customers need our
PWA to be fast. No one wants to be standing in
front of the barista waiting for their app to load
while a line develops behind them,
especially if you’re a millennial like Aanchal. Some strategies that helped
us make the PWA fast– webpack helps us keep our
JavaScript bundle small. This means that devices only
need to download and parse the code needed to
power the experience they’re trying to access. We use the Service Worker
API and Workbox precache to download additional
JavaScript in CSS before the user needs it. Our CDN dynamically
optimizes images, serving the right size and the
right format at the right time. These and other techniques mean
that our PWA’s initial time to interactive is two times
faster than the web experiences it replaced. And subsequent page
loads are lightning fast. Starbucks customers trust us to
keep their personal information and payment data
safe and secure. The Credential Management
API gives us the ability to provide customers
the opportunity to sign in using
saved credentials, eliminating a lot of
the friction associated with signing it. Today, 28% of
customers using Chrome across mobile and desktop use
the Credential Management API to authenticate. Using Add to Home
screen, customers can quickly install the
Starbucks PWA to their phone. Once on their home screen,
it’s indistinguishable from native apps. And paying for your order
by scanning your barcode is only two taps away. And it’s really a joy to use. Throughout the experience, we’ve
added thoughtful animations and meaningful user feedback. The experience is compliant
with web content accessibility guidelines. We use a pattern library
to ensure consistency throughout the PWA and other
web experiences at Starbucks. The pattern library
is a collection of React UI components,
shared styles, and commonly used utilities. Developers consume the
pattern library via NPM. And we also expose
it as a web app so developers can
access documentation and so that folks from our
design and product teams can access components
and interact with them to see exactly how they’ll
behave in a browser. The great thing
about building a PWA is that it runs in a
wide variety of devices that might not be supported
by our native apps like this commenter
from Hacker News who was excited to discover that
they had a Starbucks app that worked on their BlackBerry. We built our PWA
to be mobile first. But because we built
it to be responsive, it provides a great
experience on desktop too. And we’ve discovered that
customers love to order coffee from the desktop. In fact, 25% of our orders
through the Starbucks PWA come from desktop browsers. In short, we’ve learned that
customers love the Starbucks PWA, and it’s been
great for business. Since we launched
app.starbucks.com and created an experience that’s on par
with that of our native apps, the number of customers joining
Starbucks rewards via the web has increased by 65%. So should you invest in the web? Yeah, absolutely. The web’s reach is
massive, and the barriers to create a high-performing
PWA are quite low. You’ve heard it from
Rizzo at Spotify, now from me at Starbucks,
that the results are real. Now I’d like to introduce
you to Zack from Pinterest to tell you about how their
team keeps their PWA fast. [APPLAUSE] ZACK ARGYLE: Hi. My name’s Zach Argyle. And I lead the web
platform team at Pinterest. About a year ago, we teamed
up with the growth team to rebuild Pinterest mobile
web from scratch, but why? Well, for one, our users did
not like the current offering. [LAUGHTER] It hurts because it’s so real. So Stephanie, if
you’re watching, my sincerest apologies. At the time, our mobile website
was essentially just an upsell for our native app. However, we noticed
that the number of users who actually
downloaded the app compared to the number that actually
came to the mobile website was very low. And we knew we could do better. So last year, we shipped
a from-scratch rewrite of the mobile website in
just under three months. It was four times faster to
load for initial page loads and almost six times faster
on subsequent visits. The initial
JavaScript bundle size decreased from 650
kilobytes to less than 200. And our CSS payload
decreased from 160 kilobytes to 6 inlined into the app shell. But what about now? It’s done. We shipped. It’s over. We can all go home. We did our job. Unfortunately,
entropy is very real. At Pinterest, we have
over 100 engineers committing to the web code base. So we had to ask
ourselves, what could we do to make sure that this
fast experience stayed fast as time went by? The answer was
performance budgets. At Pinterest, this breaks
down into three sections– logging, alerting,
and prevention. There’s two main
metrics that we look at to ensure that the
PWA stays fast. And the first is
JavaScript bundle size. For logging, we wrote
a webpack plugin that reports development
and production bundle sizes to our internal logging system. This gave us the ability to
track bundle size changes over time for all of
our web applications. And then, using those
real-time metrics, we built out dashboards
with alerting enabled to make sure that all
of our core bundles stay small. We know painfully,
from experience, that one of the main
offenders of JavaScript bloat is importing something with
a large dependency tree. A single line of code could add
tens or hundreds of kilobytes to your bundle. So to help prevent this from
happening in our monorepo, we wrote an ESLint Plugin
to disallow imports from certain paths. For example, our mobile web-only
code base cannot import from our desktop-only code base. The other metric we care about
is a composite performance metric called Pinner
Wait Time, or PWT. It’s a combination of
time-to-interactive and image load times. When deciding what
to measure, look to what your users care about. For us, that’s images. Until the above-the-fold images
are loaded, to our users, page load is not complete. So that time-to-interactive
was not enough. So we created a
custom metric specific to our service and
user expectations. We also tracked more
granular performance metrics, like time-to-first-paint
and time-to-interactive, which are really helpful
for debugging performance regressions. We also have client-side logging
that includes browser, country, user state, and
many other fields that are helpful for
segmenting usage. Again, we set up
dashboards with alerting enabled to make sure that all
these [INAUDIBLE] pages stayed fast. We did notice that one of the
main offenders of page load regression was the
hundreds of experiments that we had running
at any given time. So we added performance
regression information, front and center in our
experiment dashboard, so the engineers could be
aware of any performance impact caused by their experiments. This also means that you
can see the performance improvements of your experiment
as well, which was really cool. These are just a few examples
of how we incorporated logging, alerting, and prevention
into our workflows to ensure that progressive
web apps stayed fast. And we saw incredible
results from building out the experience. Year over year on
the mobile web, we saw a 103% increase in
weekly users, nearly 300% increase in session length,
and our mobile website has since been our
number one platform for new user sign-ups surpassing
Android, IOS, and desktop web. You’ve seen it from
David and Rizzo. The future is truly
in the browser. And performance is the
foundation of it all. With these budgeting
strategies in place, we’ve continued to see
incredible growth, especially in emerging markets where
bandwidth is limited and low-end devices are common. In some countries, a year after
shipping our new experience, weekly users had
increased by over 300%. And the number of pins seen
had increased by over 600%. For Pinterest, the
number of pins seen is directly correlated
with our overall revenue. Investing in improving and
maintaining performance has directly impacted the
company’s bottom line. So if you, like Pinterest,
care about an exceptional user experience, regardless of
device, network, or conditions, build a progressive web app
with performance as a priority. If you’d like to read more about
our one-year PWA retrospective, use the short link
on the slide to visit “Pinterest Engineering” blog. And with that, I’m happy
to bring Aanchal back on stage to share a
quick recap for you all. [APPLAUSE] AANCHAL BAHADUR: All
right, so it’s day one. It’s just the first start
of Chrome Dev Summit. Can you please join me in giving
a thunderous round of applause to David, Zack, and Rizzo
for summing up months and months of hard work– [APPLAUSE] into just five minutes? All right. So if you remember what
I said at the beginning, you also know I have a
very short attention span. So I was backstage making notes. I have three things
to share with you. This is the part
of the job where you remember to
keep your phones out to take photographs and
screenshots if you’re watching us on video. Very quickly– three business
wins from Pinterest, Starbucks, and Spotify. So if, like Spotify, you
want to get more users, remove friction. It seems pretty obvious,
but the results are real. Run multiple tests. Be convinced, just
like they were. Rizzo told me it took eight or
nine tests for them to do this. And the results– an
increase in activation, 54%, and retention, 14%
increase in day-60 active users. If, like Starbucks you
want to meet your users where they are– airports, hostel rooms,
tanking up on caffeine, wherever they might be, be sure
to be using Workbox caching strategies. And my favorite thing about
their progressive web app is the thoughtful
animations that pop up to make sure that my
100 different customizations of my coffee are
actually accurate. It’s fantastic. 65% increase in number of
customers joining the Starbucks Rewards program– direct business impact. And finally, if you want to set
a standard for web performance, be like Pinterest. Focus on performance, focus on
setting a performance budget– 600% increase in
number of pins seen. When Zack told me this number,
I was, like, are you sure? 600%? But it’s real. This has positively impacted
Pinterest’s overall revenue. So now you’re wondering. This is all great. How am I going to get there? We’ve given you the tools. We are here to support you. And this talk is going
to be up on YouTube right after I say thank you. So please go and build
top-notch web experiences. Do it. Do it for the millennials. Thank you. [MUSIC PLAYING]

2 thoughts on “Get Down to Business: Why the Web Matters (Chrome Dev Summit 2018)

  1. At 13:30 the Starbucks spokesperson mentioned that user data is encrypted and stored locally with indexedDB. Anyone know how they are encrypting the data or where I can read more about it? It seems like there is no standard way to do it yet.

Leave a Reply

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