 Hi everyone, I'm Anshil 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 serve. I'm a millennial. Happy being friends with my phone, my laptop, my noise cancellation headphones, Fitbit, Kinzel, 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 Landor. 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, poor network connections. So quick show of hands, how many of you have experienced coffee shop Wi-Fi? Expected, I for one, 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? Seems like the entire population of Landor 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'd offline a few articles on the best bakeries in Landor, how to find more food in Landor, 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, you know, some parts where it's like dark green is really good, but think about the last time you were on your commute in the barge 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, you know, 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 a four-times increase in job applications by just building a progressive web app 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 of 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. 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 artists, album, and playlist links on the web and were 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 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 increased 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 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. Good luck, man. Thank you. Good morning. My name is David Brunel and my team builds the digital products used by Starbucks customers in the U.S. and 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 believe 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 address 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 index DB. 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 Ancel. Some strategies that helped us make the PWA fast. Webpack helps us keep our JavaScript bundles 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 ServiceWorker API and Workbox pre-cached to download additional JavaScript and 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 in. 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. 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 on a wide variety of devices that might not be supported by our native apps. Like this commenter from Hacker News, who is 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 for me at Starbucks that the results are real. Now I'd like to introduce you to Zach from Pinterest to tell you about how their team keeps their PWA fast. Hi, my name is 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's mobile web from scratch. But why? Well, for one, our users did not like the current offering. 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 six 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 gives 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 can 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 time to interactive was not enough. So we created a custom metric specific to our service and user expectations. We also track 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, many other fields that are helpful for segmenting usage. Again, we set up dashboards with alerting enabled to make sure that all these core landing 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 that 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 signups, 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, build a 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's engineering blog. And with that, I'm happy to bring Anshil back on stage to share a quick recap for you all. So it's day one. It's just the first hour of Chrome Dev Summit. Can you please join me in giving a thunderous round of applause to David, Zach, and Rizzo for summing up months and months of hard work 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 talk 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 work box caching strategies. And my favorite thing about their Progressive ABAP 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're 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.