 OK, let's take this bag 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. Map point 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, thoughts say, 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. Re-engagement 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 spent 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 the 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 squitcher. 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 website, 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 workers 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. AMP 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. News 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 Dev Tools. 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 supported by a site and phone, that 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 logging. Here's kayak.com using Credential Management, synced via Smart Lock with a single tap. On sites that support it, 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, 1 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 comm-scored data compares reach of the top 1,000 sites and apps. Here, you'll see that mobile web reach is 2 and 1 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'll 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, you know, just getting users to your site, and that sometimes means paying for users. Here's an example. Celio 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 costs 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. AliExpress, 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. AliExpress 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, AliExpress saw an 82% increase in their conversion rate on iOS. The progressive in-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. AliExpress already had a mobile website and they decided to supercharge it with PWA features and they got terrific results. Here's a quote from the director of mobile at AliExpress, 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, yeah, think about the big pie of potential users. You want to increase potential reach, reduce acquisition costs, and improve conversion rates. Yeah, 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 Konga Easy, you know, 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, the 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 scratches, 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 Air Berlin, 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 slash PWA. Newsroom staff and executives at the Washington Post were really excited to see this new experience, and as a result, they've 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, where they 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. You know, 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.