 Hello to everyone who's watching us on video from around the world. I'm Tao Tran. I work in product partnerships for Chrome and the web platform team, which means that day-to-day I get to interact with lots of different partners and web developers like yourselves as we try to think about what are the new, latest, and greatest web technologies to bring to market and hopefully motivate some of you to ship them, too. So when Chris and I start talking about what kind of talk we wanted to give, we knew we want to focus on what we see as the new standard for really good web experiences, the modern web. Then Chris talked about the new bar, and well, I only heard the words modern and bar. And I thought about my favorite modern bar in New York City, which is the Hudson Hotel, and what a modern bar experience should be like. I know. So despite our shared love of cocktails, Chris quickly got me grounded and said, this wasn't actually our topic. No, no. So I'm Chris Wilson. I've worked on developing the web platform for nearly 25 years, nearly a quarter century, since NCSA Mosaic. And I am the developer advocate lead for the Progressive Web App team here at Google. And we're here together, actually, because we both really want to get you as excited as we are about the user experiences that are now possible on the web. What we both believe is this inflection point today that we're currently experiencing, the tipping point of the web as a universal platform, this groundswell of the web being used to deliver experiences that aren't just useful and real, but they're beautiful, immersive experiences. So we want to inspire all of you on what's possible today on the web. Share really great partner journeys and success stories to give you ideas. But this isn't just about doing something that's never been done before or couldn't have been done before. No, not at all. So I'm an avid scuba diver, and I live in Seattle. And we have really strong tides. And we need a slide update, I think. That's not supposed to be there. But we get really strong tides in Seattle. And this is the experience of how I used to get tides. Let's switch over to the demo screen. And there we go. So this is what I used to use to check tides, to see when I could dive. And it's really kind of a painful experience, because if I want to flip between days, I actually have to use these dropdowns. I have to remember what day of the month it is, which I can never do without actually looking somewhere else on my phone. So it's kind of a pain. It's not the best. And the team at Dockyard actually has built this application that I, frankly, instantly fell in love with. It's called HiTide. And this is a progressive web app. It's actually starting up cold here. So it figures out, loads up, and it figures out, oh, you're in San Francisco, because it has geolocate access. And but I actually want to see what the tides are like in Seattle. So I'm going to type in Seattle. And go check the station. OK, so I'm flying home on Wednesday. Ooh, actually, it kind of looks like Wednesday afternoon is a perfect time to go diving. So I'll have to get my gear packed up. Now, this isn't a killer app, right? This isn't like, oh, my god, I could never get tides before or something. I've been able to look up tides forever. But this is a much smoother experience. It's really smooth scrolling. It starts up really quickly. And actually, it's still kind of half works offline. It gives me an experience, at least, while I'm offline, even if it can't generate the tide tables. And this is really underscoring the point that it's not just good enough to just provide a service anymore. You actually have to prioritize your user experience. This is what users expect now. So let's flip back to the screen. Here we go. I would radically prefer this experience on the right rather than the experience on the left. And so this is what users expect out of something that they want to use frequently. And so the core concept we want to get across today, and our goal for all of you, is really it's time to raise the bar for what you can deliver for your user experiences. We know we can all do better, and we want you to exceed user expectations for what's possible on the web. We all know that the web is great for user reach. It's the front door for so many of companies and services. And now we want you to believe that the web can be used as a great user experience platform. We've been using this term, Progressive Web App, for about two years, a little over two years now. And we want to be clear, this is really just a placeholder for this new hire bar for delivering web applications. Like when we talk about Service Worker, or Add to Home Screen, or App Manifest, Push Notifications, all these different technologies, this isn't really like we wanted to categorize this as an app. It's really care about your user experience, provide a better user experience. In fact, the Progressive Web App pillars are really just about doing that, providing a great user experience. So we're mostly not even referring to Progressive Web Apps. Certainly in our talk, we'll mention it a few times, just as an easy way to say something, but it's just a shortcut for modern web. In particular, caring about your user experience more than anything else. And what users have grown to expect, not just from the web, but from their computers and their devices, they expect these experiences that are fast, that are integrated with the way the device they're using typically works, and that work reliably. And that's how you build these truly engaging experiences. Why PWAs need a Service Worker is because then they can cache and they can provide a really fast initial load. They're installable not for some other reason, just because that's how the user expects to get to applications. And then the browser fades into the background. The experience just feels like it's part of the device. And yes, these pillars do spell fire. I'm not supposed to yell fire in a crowded theater, so we're not making a big deal of that. But as we explain the details of what your users expect, we're gonna show you some success stories too. So on the first pillar, fast. Users don't expect janky scrolling. They don't expect slow load performance. You saw how efficiently that high-tide app loaded, how smoothly it scrolled. Loading an app has to feel instant. It has to feel invisible. And this is really just about keeping the user's attention. As we said before, user attention is a really precious resource. After three seconds, 53% of users abandon sites. Half your users are gone. Now, this is bad enough on a desktop machine. Certainly I'm guilty of this if something takes more than three seconds to load. I will probably just close the tab and find something else to do. But those are usually connected with this reliable fast network connection. But if half of users abandon a site after three seconds, it is frankly a miracle to me that anyone ever loads pages on mobile networks. The average mobile webpage takes an average of 19 seconds to load on a 3G connection. Now, of course I might think, hey, that's fine, I've got 4G LTE or whatever. And I'm usually on Wi-Fi anyways on my mobile device. That's great. Except remember, worldwide, 60% of mobile connections are still 2G. 2G, like not even 3G, but 2G. So worldwide, this is a much more critical problem than you might understand. And in a nutshell, what we're really saying is you have to focus on making your experience fast. Needs to load instantly. And I'm gonna leave most of this to a session from Addy later this afternoon, but we really wanted to share some successes from being fast. For example, LMA is the biggest food ordering and delivering company in China. They launched the first progressive web app for the domestic Chinese market, and they serve 260 million users. 260 million, to put this in context, because a quarter of a billion doesn't really register to me, this is almost as much as the entire population of the United States. That's their customer base. They actually have 1.3 million restaurants listed in their app, and 99% of their users order food from mobile devices. So it's kind of critical for them to have a good experience, right? And LMA set out to improve their mobile experience focusing on speed and reliability, but particularly in flaky connections. So they use an app shell. They wanna get skeleton screens on screen really quickly. And they wanna ensure that whenever a user taps a button, it gives them something. It shows them this feedback that, hey, something's happening, don't worry, we know what you're doing. And transition to that page, and they get their skeleton paint up in 400 milliseconds on a mobile connection. They actually get fully interactive in two seconds in typical conditions. Like, this is pretty amazing to me, this is awesome. And this critical focus on page load time, by the way, this user interaction, was really the goal of the AMP project. AMP's built on web components and HTML. I think that's great. It's a way to easily build fast and reliable pages on the web. So it's amazing to see all this momentum with AMP. They just had their two-year anniversary last week where they announced that there are now four billion AMP pages out in the wild across 25 million domains. That's an incredible milestone. And AMP is really continuing to evolve to support additional use cases, especially when it comes to e-commerce. You see here a couple of examples of e-commerce sites that have built highly interactive pages. It's possible to build a product page that updates the availability of an item, shows a different thumbnail and price, as well as a way to add a product to a shopping cart. Let's take a look at an example of a merchant building a highly interactive AMP page. Here you have Overstock. It's a US-based home goods provider that's built a fast-loading interactive site using AMP. It's also important to highlight that their AMP pages are actually 100% functional parity with their non-AMP equivalents on their mobile site. They're using AMP to sort and filter. They're using several AMP components, the AMP sidebar for the menu, AMP accordion for content that can expand and collapse based on their user interaction. They're live with AMP for over four million product and category pages. And their early metrics are looking great. Overall, uplift in conversions, as well as increase in revenue using their AMP pages. So think about it, a year ago, Overstock couldn't have built this page, and yet AMP has allowed them to step up their game. And I love to hear stories and feedback from developers, especially as they're going through building these new mobile web experiences. And so I want to highlight here that the AMP pages allow the team to realize just how large their regular mobile web pages were and how slow they load. And so it's awesome to see the Overstock team continue to iterate on their AMP design to improve their metrics and then take those lessons and apply it back to their overall mobile website. They're heavily investing in progressive web apps as well to take AMP to the next level and raise the bar. And so AMP has evolved pretty quickly from static pages to now interactive pages. And more recently, developers have begun exploring how they can use the AMP library to build fast, beautiful websites. It's early days and we're eager to get feedback and hear from sites who are exploring using AMP for their full site experience. Up here on screen is Tasty.co, which is a recipe site from Buzzfeed. They went all in on AMP. For them, raising the bar was building an entire website using the AMP library. It's fast and getting interactive in less than three seconds. And so users are getting this amazing experience coming from Google search, from Facebook links, from Pinterest pins. And AMP was a natural way for the Tasty.co team to make something super performant and optimized for their audience. And what's even more awesome is that the site is responsive. AMP then becomes an efficient way to build a site using a single code base. The Tasty.co site provides this experience not only on mobile, but on desktop. So it's a really great overall developer experience. And this is really the theme of this new bar for web experiences. You should provide a good experience across devices. And on each one of those devices, the experience should really feel integrated with the device capabilities. The way the user typically does things. End-to-end, experiences that are built on the web don't need to feel any different than experiences that are built on native platforms. They should be just as natural for the user to interact with. Now, users expect to interact with all apps pretty much the same, regardless of how they're built. Like, they expect to launch apps from the home screen. They expect that they're visible on the task list. They think that apps should maintain your identity, have access to low-level hardware stuff like camera, audio, or accelerometer. And Owen's gonna talk a bunch more about this in his talk later this morning. But one good example I really wanted to call out is media playback. When you're listening to a music stream offered over the web, you still have the same expectations as one offered from a native application. As a user, if your screen is locked, you wanna be able to see what song's playing. You wanna maybe skip to the next song or skip back, hear that one again. Maybe hear it again. I'm never gonna give up this song. But with the Media Session API, web apps get to hook into this capability too. They get to integrate with how the user expects to do things. And media companies are actually now seeing a ton of success in the web. So GeoCinema is part of Reliance Geo. They're the biggest 4G telco network in India. And they have 100 million paying customers. This is one of the largest mobile video networks in the entire world. And their progressive web app is basically a one-stop shopping destination for Indian movies, TV, music videos, the whole deal. And this was an app-only business. Like they only had native apps. And they went to the web for the first time with this progressive web app that they built. And they only launched this three weeks ago at the beginning of this month. And already they're seeing 10% longer session times on their mobile app, on their mobile web app than on their native app. And better reach for their customers who are in tier two and tier three cities, because in these smaller areas, they may not have the native app. They may not have the storage space to keep it. And so Chris just walked through kind of this really integrated experience for the most personal device for users. And so I want to transition to talk a little bit more about how you can make sure that you're delivering really great personalized experience, whether it's getting users to sign in, sign up, or check out. So let's first talk about push notifications. And here, this is really a great opportunity for you to provide a much more targeted experience for users. So Mercado Lire is Latin America's largest online retailer with over 190 million registered users. Some of their biggest markets include Brazil, Mexico, and Argentina. It's this huge marketplace for buying products. And oftentimes, buyers want to ask a question of a seller before making a purchase. So we want to share this really great use case for push notifications that's highly targeted and personalized. So when a user wants to get in touch with a buyer, they get prompted with a great visual, explaining that they can receive a push notification when the seller responds. So that's the visual you see up here. This is such a great alternative to email, because it's much more real time, again, integrated into the user's personal device. Then when the seller responds, the buyer gets a notification on their device. It contains the title of the product, as well as part of the text of the response in it, so again, users get a bit of a preview when the seller responds. Mercado is seeing a 41% opt-in rate for these web push notifications, again, a whole new channel for being able to re-engage and reach their customer base. So I really love how this type of push notification is specific and shows how Mercado is able to deliver a great user experience, taking advantage of native device capabilities. So let's turn to the sign up use case, which we know is really painful for a lot of you when you're trying to do this on different sites. So Petlove is this innovative Brazilian e-commerce site for pet goods. And we included them because, look, every talk needs a cute picture of a puppy. And so actually, Petlove's offline page is actually a photo of a puppy, in case you want to check it out. Go check it out, the online. So Petlove wanted to avoid the issue of having users go all the way through the checkout flow, only to abandon the cart when they have to go through the painful process of signing in. Reducing sign in friction is a critical step, especially if you require the user to sign in before they're able to check out. So as Ben and Dion mentioned, there's now a new one-tap sign up library that you can integrate. And so for someone like Petlove, this means you can sign up on your mobile device. And then when you go to your desktop device, you're actually automatically signed in. And so there's this great kind of cross-platform story for both sign up and sign in here. And it's pleased to report that there's actually, Petlove is seeing that two X more users are actually able to get to the checkout flow, already signed in, and they're seeing a big bump in overall conversions. We also have the identity demo booth for anybody who wants to learn more about the sign up and sign in process. So in addition to the overall sign up process, Petlove also went ahead and just integrated and upgraded their overall website experience into a progressive web app. And so what we love to see is that sites are actually using multiple features and products. And so it's not just about, yes, you can integrate a particular API, but really the site and the users truly benefit when you're able to do multiple things at once. And so Petlove integrated the sign up, and then they went ahead and just focused on performance and just re-doing and upgrading their experience. They're seeing overall increases in conversion and time spent, as well as it's important to note that their progressive web app is eight times smaller than their native app. This is especially critical for users, where they have a lot of users on 2G and 3G networks. And so this is a big deal, or in this case, a tiny deal, which is actually a better thing. So another great personalized example is Starbucks. And Starbucks, of course, is the largest coffee house company in the world. They're based in my hometown of Seattle. So of course, I had to talk about them. They have 20,000 stores across 62 different countries. And their customers expect a really high quality experience. No matter what device I have, what network conditions there are around, I've got to have my pumpkin spice latte this time of year. And users often end up standing in line at the store rather than ordering ahead. Like a lot of customers use their rewards program. And I personally hate carrying extra cards around in my wallet, so I don't want to do that. And the Starbucks team built this great progressive web app, it's still in beta, with the goal of making it easy for users to come back and sign in and pay with their bar code. And I was actually really surprised to hear, because I thought that it was really just mostly cards that people used, 20% of all their transactions are done using the bar code. And this bar code, their beta progressive web app, actually has a service worker that caches all this stuff. And it enables customers to pay with that bar code, even if they don't have a network connection. Even if they don't have a network connection, they can pull out their phone and pay for their stuff with their Starbucks app. So from sign in to checkout, their beta is a great example of this user experience you can offer from progressive web apps. So speaking of seamless checkout, this is an area where we want sites to think about how they can reduce the number of steps necessary for the checkout process. So this is probably a pretty typical experience if you've gone through the checkout process buying stuff on mobile web, where we see that sites can have seven to eight steps to complete, including reviewing cards, creating the user account, adding the information. So Swim Outlet had a pretty typical new user checkout flow that required login and multiple screens. And even though they were leveraging autocomplete fully, it was still a pretty long process, taking two minutes or more from start to finish. So Swim Outlet, which is actually the largest online specialty SwimShop in the US, did a review of their site and implemented payment requests. So users at Swim Outlet can now go from the cart review page to their order confirmation where they see a payment request sheet, this mobile optimized form that's pre-filled with the user's information, meaning it only takes a few clicks to complete. So similar to the J Crew walkthrough that Ben and Dion did, because the Swim Outlet shoppers are able to skip so many in-between steps, they're able to checkout in 20 to 25 seconds, an 80% reduction in time to checkout, which is huge. And to help with speedier checkout flows, we're now making the Google Payment API available as well. This means you can use credit cards, you've added to your Google account from products like Google Play, YouTube, Chrome, Android Pay, and then the Google can send the merchant the payment and shipping info so that users don't have to type it in. We showed you in the keynote, the merchant fancy implementing pay with Google button. And in this demo, you see on screen that the site calls payment requests similar to Swim Outlet, and that you can see Google as a form of payment enabling a much faster checkout process. And the payment team is also here in the forum in case you wanna check out and have them review your checkout process. So the web, as we all know, has always been this really, really safe place, right? Okay, maybe that's patently untrue. But the expectation has always been at least that websites don't get access to powerful device features, powerful APIs without asking for permission. And as we add more and more powerful APIs to the web, as we enable more and more web capabilities, that permission changes the model of the web and how users have to interact with it. So we're still on this journey of building the best model for this. But when websites need special permissions from the user, they have to show this permission request. Now, the permission requests appear as ignorable banners at the bottom of the screen on Android, top of the screen on desktop, and developers have often shown them frequently. They just pop them up whenever they think, oh, I might need this in the future. Without considering, is this really an appropriate time to ask the user this? And do they have enough context to answer that question? And this results in a really distracting user experience because you have these little dialogues popping up all over the place. And it turns out, this is kind of a bad thing too, because in Chrome for Android alone, we found users either entirely ignore the permission requests or they temporarily dismiss them. More than 90% of the time. So 90% of the time, it's not that the user is saying, yes, you can have that permission, or saying no, you can't. They're just saying, get this dialogue out of my face. So to address this problem, since Chrome 59, we actually started saying if a user dismisses a permission request, doesn't accept or deny it, they just dismiss it, three times in a row, we'll actually just temporarily block that permission request in the future for a week. So it will pop up again, but not for another week, since clearly the user doesn't feel like answering the question. Now as another step though, towards making this even better, beginning in Chrome 63 for Android, we really wanna reduce these continuous distractions for users. So we're going to present permission requests as modal dialogues. Now this sounds backwards, because now we're gonna force the user to answer this question, but this really is gonna encourage users to say, yeah sure, that's a good request, or deny a request that they're not interested in, rather than just kind of ignoring that they're being asked. And this is going to drastically reduce the number of permission requests that users actually see, because they'll make a decision up front, and the best part about this is this is going to encourage applications to not only ask for permission in the context of why that permission will be useful to make the user's experience better, but only ask it when it's actually a good idea and they need that capability. And this is really important, because we found that sites that ask for permissions across all APIs without context, on average, they actually only get granted permission 40% as much, as sites that actually ask for something and give you the context. So if you're given the context of, hey I want access to your location because it will help me tell you which restaurant is closest to you, you'll actually grant that so much more often, like 150% as much often as you will if you don't get any context at all, like 40% of the time they would get that accepted. So since a block decision, by the way, is permanent, unless the user manually overrides it, we hope this is going to encourage people to ask for permission and give context. Okay, so let's talk about reliability for web applications. When you click on an app icon on your home screen, you expect it to just work, you expect it to just load and do something. And this frankly has always been something holding the web back as an application platform, because as users we've become conditioned to think that web app equals something that only works when I have a network connection. And native mobile apps never show us this cute little guy. Nothing on my home screen shows this, except for Chrome. And in order for web apps to earn a place on the home screen, we need to make them reliable even when the network isn't. And the worst part is mobile phones actually aren't always online or offline. They're in like this Schrodinger's cat state where they might have a network connection, they show four bars, but it might not actually do anything, or it might not only have one bar, but it actually can get data through. And this is actually even worse, like this breaks the user experience just as much as saying, hey, I'm disconnected completely. So let's talk about a service that I'm sure you've probably heard of, and you might even rely on and need to be reliable, ride sharing. So everyone's heard of Uber, like they're a ride service with a global focus. They actually build products that work all over the world. And earlier this summer, they announced their progressive web app. M.Uber, called Moober. No, really, it's called Moober. They said so in their blog post, so I'm gonna say that the rest of the time. So Moober is this investment in delivering really great global access for Uber everywhere, especially for those users with really low connectivity, or low storage space on their devices, or even devices where their native app wasn't actually supported. And users need to really be able to quickly and reliably request a ride, no matter where they are, or what their network speed is, what their device is. And Moober provides that experience using the web. In fact, they're actually designed to work really well on 2G. They're interactive in three seconds on 2G. Their core ride sharing app is really just 50 kilobytes. Like that's incredibly tiny. I mean, I haven't seen a JavaScript library that small in, I can't even remember when, but it's really designed to work well because they cash these requests and they actually let them serve the content locally, even when they have an intermittent network and they detect this really well. Instagram is another example. You're gonna hear more about this later in the creating media without an app talk. But they do this great job of unlocking the ability for users on unreliable connections to share experiences even when they don't have a connection through offline support. So you can take a photo even when you're not connected to the internet and using Background Sync in the Service Worker API, it gets posted automatically as soon as you're back online. So they'll talk more about that later. And continuing with this theme, eBay is actually currently looking at service workers to see how they can make their experience better for their users. And they're not quite ready to refactor their entire core experience, but they came up with this great standalone use case to try out service worker deployment. So they started caching the users eBay browsing history, like what items you've looked at already. They cashed those using Service Worker. And then the user can actually look at those, like they can flip back through items even while they're offline. And this way they can learn how to use service workers for a really strong offline experience and then use that to integrate back into their main experience. So all these pillars, fast, integrated and reliable, they really just lead to engaging. And an engaging app really goes beyond just being functional. And it ensures your whole experience is really delightful. It makes it easy for users to do what they need to do. And using features like Web Push, it can always be up to date with notifications. You can keep users informed. And it uses the right capabilities, the right time in a really beautiful way. And to talk through an engaging experience, we're gonna take a look at Travago. Great, thanks Chris. So go to demo screen. So in the keynote, we highlighted Travago as this really great progressive web app. And so I wanted to go ahead and give a demo. Although all of you who I know, I think you're really paying attention to us, you're probably looking at your phones already. So if you wanted to go to travago.com, you can do that as well and follow along. So I'm gonna click on Travago, this beautiful splash screen that again, gives you some time to warm up the browser. And I'm gonna go ahead and search here. So for those who are unfamiliar with Travago, they're actually one of the largest hotel search engines for travel and they operate in 55 countries. So I'm gonna go ahead and search for San Francisco. Let's take a look at the dates. Let's see, maybe I'll be in the city for my anniversary next weekend. And then if you actually scroll through, it's really, really fast and smooth. And if I actually try to go into the various different hotel product detail pages, you see a nav here where each of the pieces of information is available really, really quickly. You see some of the skeleton screens that Chris talked about earlier. And so it's just a wonderful, kind of immersive user experience. And then one of the things that the Travago team really focused on was the ability to be extremely resilient and still perform it even on a flaky connection. And so I'm gonna go ahead and go to airplane mode. And as you can see here, there's the UI that tells the user you're offline, so then we'll reconnect when we are back with network. And even while being offline, you don't hit a white screen. You actually are still able to consume some content. Again, if I'm going into a listing that isn't already cached, there's really nice UI for you for to communicate to the user when they're offline. And I think what's terrific about this is that even when the user kind of navigates through Travago and goes back to a screen or they actually have a maze. So I guess it's their version of the offline dinosaur. But you're actually able to play a game while you're waiting to come back online, which is really cool. But please still pay attention to the rest of this talk. Don't just play the little game. And so what I love about Travago is that it's great to ship really amazing experiences for users, but then a day it's still a pretty large business. And so I wanna highlight a couple of stats here. So again, as I mentioned, they focus a lot on providing a really resilient experience. And a stat that I wanna highlight is that 67% of users who are interrupted by a period of a flaky connection or offline actually come back to continue to browse. Think about that. Think about how often you hit a flaky network and then you actually just leave the site. In this situation, you're actually Travago is still maintaining some sort of content for you to interact with until that network connection comes back. And so that continuity is really proving well in their business results. So they're seeing users continue to stay with them and continue to browse. Another stat which Ben highlighted earlier in the keynote, and I wanna really emphasize here that 97%, they're seeing a 97% increase in overall conversions. And conversions here is defined by a user browsing through lots of different hotel listings and then clicking on the view deal button. And so that means that users are able to find what they want really quickly and are clicking out. So that's a really, really great experience. And again, I wanna share, one of the highlights here is that Travago actually published a blog post with Think With Google where one of the developers said that mobile users come to expect sites to just work regardless of flaky wifi or poor mobile reception. And so this is really the new bar. It's the standard bar, I hope, for what users expect and for what all of you developers should be able to deliver for all of your users. And another example of an engaging experience I wanna walk through is West Elm's approach. For those who are here at Chrome Dev Summit last year, I actually demoed at the West Elm beta site and I wanna touch upon the journey that they went through over the last year. And I think that's gonna be very relatable because sometimes here at Google, we have a lot of, we move at a fast pace. But when I talk to partners, I have to remind folks that it takes time. It takes a lot of planning, a lot of internal stakeholder management. I see a lot of nodding because people understand what it takes to kind of reinvest or invest in new experiences. So I wanna walk through kind of what West Elm did. And so for those of you who don't know West Elm, it's a major retail furnishings company. It's part of the William Sonoma Group that has eight brands, including Pottery Barn and Williamsonoma.com as well. And so I'm gonna go ahead and walk through the timeline. So this time last year, that just launched the West Elm beta and they kept it as a separate experience and they started to redirect some limited traffic there. But they knew that they had something good and so they actually went through rigorous usability testing and they got positive feedback. And so that gave them the confidence to continue to roll out to more of their traffic. So they were seeing 10% of traffic, constantly, constantly checking what the data was telling them. Again, continuing to see positive metrics. And then at the point where they were rolling out 10% traffic and seeing positive metrics, they said, wow, we're onto something good here. It's actually, let's take this opportunity to re-architect their platform so that they can use web components across all of the company's sites. Ben highlighted West Elm, Pottery Barn and Williamsonoma going through this process already. And so this really means that not only were they building a high bar for one site, but they were taking that learnings and able to expand it across so many other company sites. And when they rolled out to 25% traffic across iOS and Android, and it's important to note that West Elm's traffic is actually over 80% of it is actually on iOS. I want to pause for a moment to kind of share a couple of stats that they saw for 25% traffic. They saw an increase in average time spent as well as an overall lift in revenue per visit. Now, if any of you have actually been on the West Elm site and 9% revenue increase, it's actually a lot if you've seen their furniture. So I think this is, it was a huge testament to the work that the team did in terms of testing and continuing to look at their data. And then that data that I just shared with you was so positive that it actually accelerated kind of folks internally to think about multiple sites upgrading onto this new platform. And so over the next few weeks, potterybarn.com, williamsonoma.com and westelm.com will be getting this new experience through probably most of it coming right after the holidays, but you'll be seeing all these new upgraded experiences. So it's a great example of testing, iterating, retooling and then launching for what makes sense in terms of raising the bar for all of your users. And I hope you're getting the idea as we go through all these examples. We're hopefully showing you, there's a ton of different features here. There's a ton of different ingredients to help you mix and match the recipes to formulate your perfect cocktail or web experience, whatever. Speaking of cocktails, I hear there's some good nitro cocktails at the bar tonight here in SF. For those of you who are here with us, and yes, there are mocktails for those who don't drink alcohol as well, but. So just two years ago, we had this major e-com company in India ship a beautiful new web experience. And so I really want to emphasize that we think about the web as this global, having global reach. And so it's just this one company, and I always like to take a look at kind of where we are like year over year. So two years ago we had one company and today there are so many sites adopting all of these modern web features from AMP to service worker to push notifications, better sign in, better checkout, because these sites want to deliver a better user experience. There's just a small sampling of brands, but it just gives you a sense of kind of the momentum that we're seeing throughout the world. And it's just not about sites. It's about making sure that platforms are able to invest in the modern web. And so we understand that it's also important that we are able to turn on many of these features at scale. And so we're excited to see that automatic and WordPress are continuing to invest here. So most folks have probably heard of WordPress.org. Automatic is actually the creators of WordPress.com, WordPress VIP, the Jetpack plugin for WordPress, as well as WooCommerce. And so with automatic, we've been able to collaborate on a couple of fronts. First on AMP, we're creating the official Google AMP plugin for WordPress and making it instantly available on millions of sites across WordPress.com and the VIP sites. And with ServiceWorker, we're doing some experimental work with the Jetpack plugin to bring the generic ServiceWorker framework to the theme authors. So this means that you can progressively enhance your theme with more progressive web app functionality. And hopefully there'll be more to announce on this front soon. The automatic team is actually here with us at Chrome Dev Summit and they'll be giving a talk about how WordPress is continuing to invest in the web. So WordPress and automatic is just one example. Magento is a major e-commerce platform. They're serving tons and tons of sites, actually over $124 billion in gross merchandise volume goes through the Magento platform on an annual basis. They have lots of huge developer community, tons of technology partners and recently Magento announced their commitment to integrating progressive web app technologies. And it'll be part of the upgrade into the next version of their platform. So we're excited that they are continuing to invest so that users are gonna get modern shopping experiences. And hopefully this shows how you can reach the bar. You can have some support to help reach the bar. You can get some assistance. That's actually what our team is here for. That's why we hold these conferences. This is what we wanna do is help figure out how to help you to reach that bar. So with that, we hope that you take some of these stories, get motivated and inspired to go back to your teams and build something great, actually build really great modern web experiences. We're around the next couple of days. Feel free to come up to us. We're excited to engage with all of you and have a good rest of the next two days. Absolutely, thanks.