 This place is amazing. This venue is incredible. I'm so excited to be here this morning with you to talk about progressive web apps, but I'm an American, and so I would be excited about something, I guess. But I think it's legitimate to be excited about this, because we've got two incredible days of talks. We've got code labs. We've got experts here, not just Chromeys, my fellow engineers from Chrome, but also folks from other browser vendors and engineers who are making progressive web apps in the world. Some of the world's best experts who are engineers just like you making this stuff are going to be here to share their expertise and what they've learned over the past year. It's going to be great. So at Chrome Dev Summit last fall, we promised that we would have a Chrome Dev Summit in Europe and this summer, and we're breaking that promise, because we thought better of it. We thought that instead of a Chrome Dev Summit, we should have something that was more inclusive. The web is bigger than Google, it's bigger than Chrome, it's bigger than any single platform or browser vendor, and so that's why we've done the progressive web app summit instead. We renamed it, and we're incredibly glad that, as Paul mentioned, our partners from Mozilla, Opera, Samsung, Microsoft, basically everybody is here, and it's great. And as I mentioned, I'm an engineer on the Chrome team. I lead both the engineering side of the team that's building the progressive web app stuff, but also the standard side. And as somebody's been on the Chrome team for a long time, let me assure you that building and distributing native software is a real pain. I've been on the Chrome team since before there were 1% of people in the world using Chrome. We had to fight really hard to get Chrome into people's hands. You have to convince them to go download it, and then once they've downloaded, they have to click on the thing and run the installer, and once they've run the installer, they have to then choose to use your application. The same thing is true in native application platforms of any time. You still have to convince users to go find your thing, download it, install it, and then choose to run it. That's a massive challenge for any company that's trying to make forward progress. Although it used to be a lot harder. This is how when I was a kid, my family acquired most of its software. We used a Ford tourist station wagon like this to go to a place like this to buy disks like these that you had to physically put into the computer before you could do any of those other steps. So it used to be a much longer journey to get software. So when I went to college, it was a revolution that we were able to use CDs for almost everything. Many fewer disks to swap. And when I got there, at one point, I got for $5 from the bookstore, the college bookstore, I got a copy of Microsoft MapPoint. Now, if you hadn't used MapPoint, it's okay, not many people had, but MapPoint was a bit of consumer GIS software. You could have a map on your computer that you could pan and zoom around. It only took 30 minutes to install, but it was an enormously transformative experience. You could just zoom around the entire world if you needed to. Yes, the data got out of date, but it transformed the way I planned trips. Especially road trips, kind of an American thing, but very timely for me in college. And at the time, web-based experiences just couldn't compete. If you clicked on the link to go to a bit to the left, you then sort of waited and then, oh, there it was. Even though the network was pretty fast, you still sort of did this stuttering back and forth. It just couldn't compete. It was this big cliff between what you could do in native and what you could do on the web. Then Google Maps happened. We eventually got pan and zoom on the web. It worked on any computer, not just the ones I had spent time installing the software on, and the data was never out of date. Maybe it wasn't entirely complete, but it kept continuously getting better. And I didn't have to go get another CD or download a big patch. It just was always fresh. So when the web is capable of delivering a particular experience, it can compete. Our distribution model is actually better. Links are the web's superpower. So, okay, quick, I can see everyone. So a quick, raise your hand if you use the web to get to maps on your desktop or laptop computer, yeah? Okay, now keep your hand out. That's almost everyone. Keep your hand up if you use the web to get to maps on your phone. Okay, so less, okay, yeah, okay, 10%. Sure. That's about what I thought. So we don't really use the web on mobile the way we used it on desktop. But remember that we started with native apps on desktop too. So what we needed to break the log jam between native and the web on desktop was some enabling technology. And Ajax was that enabling technology. It allowed us to move data in as you panned and zoomed around the experience. We did the exact same thing for email. I don't know about you, but I moved almost all of my mail consumption to a web browser on the desktop, but I'm using a native app on my phone. So why haven't we made the same transition on mobile? You know, I think just to reinforce how big the size of this cliff is, today, users are spending almost 90% of their time on mobile devices in native applications. Why is that? Well, one theory is that maybe the re-engagement features that native apps have had keep users in those experiences or draw them back into it, things like being on the home screen or notifications that can be persistently in your notification tray. But it's a huge amount of time and it's hugely concentrated. If you haven't won the lottery for native applications, you're probably not going to because users are spending 80% of their time in the top three apps. That's 80% of that 87%. This is a huge winner take all dynamic, which we didn't necessarily see on the web. If only native apps can be engaging and only a few can make it on native, why hasn't the web disrupted this? It often takes more money to distribute a native app to a user on native platforms, then you'll get back from that user. Like native app developers are suffering. Why hasn't the web disrupted this? So I think it's worth the thinking back again, you know, a decade or so to think about how we used to get web experiences. I don't know about you, but this is how I got web pages. You dial one of these up. You go to the bit of your house that had the computer in it and you'd put the computer into online mode and you'd eventually wind up yelling up or down the stairs to your friends and family, like don't pick up the phone, you're going to interrupt my download. This was tough, but we knew we were in online mode and the web grew up in an online mode. We could always assume that that next navigation, that next transition, no matter how slow it was the first time, was going to be the same speed the next time. But that's not how phones work. Phones, even when they look like they're online, they often aren't. Radios transition wildly underneath us. The network isn't reliable. We can't assume that it is. HX got us to good enough because we were always connected, but what about now when we're not always connected? When I'm on a mobile phone and I tap something from my home screen, I never see one of these. Apps always load. Maybe they tell me that they don't have the data that I wanted or they can't get the new stuff, but so they'll show me the old stuff, but they'll never give me this cute little offline dinosaur. They have this UX contract that they'll never fail to load if they're on my home screen. The web hasn't been able to do this. We've also made the keyboard and mouse to tap and swipe transition, but I think one of the biggest issues here is that we haven't really earned our place in the home screen. Because web technology can't be reliable and can't be reliably fast, it's reasonable for users not to include us in their daily experience. So one way to think about this is there's an access here of capability. Now, native apps have the ability to start up reliably. They can be fast all the time. They can do offline. They can handle push messages. They can synchronize in the background. They've got access to all the sensors. While the web is safer and more respectful of your privacy, but it doesn't have some of those capabilities. It isn't on your home screen. It isn't in your notification tray. But what if we had another access? We'll add reach. The web succeeds wildly here, even in the situation where users are spending only 13 to 14 percent of their time on their phones, on the web. They're visiting more than 100 sites a month. Meanwhile, ComScore says that the average user is downloading zero apps a month in the U.S. This is the power of URLs. We can absolutely meet those one-off needs. And we do. We are always in the user's experience, even if they don't realize it. So what we want is a way to go from incredible reach to be more engaging, to have those capabilities. So what is that thing? I think we can meet those user expectations today on the web. And that's what progressive web apps represent. They're finally the ability for us to earn our place in the home screen and in the notification tray. First, by providing reliable experiences that are consistently fast. And we don't have to give up the reach to get it. That's the promise of the web. And that's why I'm excited about progressive web apps. So what do these experiences look like? So here's the washingtonpost.com slash PWA. You can go do it on your phone right now, wapo.com slash PWA. And it loads in a tab like any other site. And if you go to it enough, if you engage with it, you'll eventually get this add to home screen prompt in Chrome for Android. So if you tap on that link, the browser will confirm to you that you've done it. And if you go back to your home screen, you'll see that there's now a home screen icon. When you tap on that icon, it's beautifully fast. And it'll launch with a splash screen. That splash screen is a full screen immersive experience. And the whole app runs that way. And if you go into the task switcher, what you'll see is that it's first class there too. There's no URL bar getting in the way. It's exactly like a native app in that sense. So what was missing to be able to deliver this experience? Because we finally earned it. Well, first we need reliability and reliable performance. And next, we need to be in the notification tray. And lastly, once we're trustworthy and have reliable performance, we need to be able to have enough metadata about the site to be able to generate that add to home screen prompt to put it on the home screen. Okay. So there's talk today and tomorrow covering all of the required technologies to get to that point. TLS, which is imperative and HTTPS, manifests, service workers, push notifications, smooth UIs, and much, much more. And I'm excited that we've been able to work with other browser vendors over the past three years to deliver these technologies to you. They're already shipping in Chrome, Opera, Firefox. It's amazing stuff, and they're going to be an edge soon. So the web is bigger than any vendor or single platform. It gives you that incredible reach, and we're bringing this stuff to every browser. So, but I just want to focus for a second on reliable performance. We all know the faster is better. And if we have to traverse the network, we can almost never be fast, specifically a mobile network, where getting the radio initialized can take two seconds. The data from SOASTA that you just saw really confirms that correlation between speed and bounce rate. But we see that a three-second delay can bounce 40% of users. It's really tough out there if you're trying to deliver great experiences on the mobile web. So what if we weren't necessarily going to have our connection eaten by the offline dinosaur? What if, if a user goes to the site, it could be reliable after that? That's exactly what service workers are. They provide an in-browser, programmable network proxy, so that users can always get to something on your site, the second, third, and fourth times they visit. If they are willing to reengage with you, they can always get to your experience. And you can use your own cache to do it. You can always boot up without ever hitting the network. You can provide an experience from local data. This is exactly what native apps do, and this is transformative for the way we deliver reliably performant experiences. So what about that first visit? Well, the search team has been thinking about this because there's a epidemic of obesity on the web. And they came up with AMP. AMP is a format that uses custom elements, HTML custom elements, web components, to keep you from doing most of the things that really hurt the user experience. And it delivers incredibly fast initial loads. They're seeing median one less than one second load times from the AMP documents on their CDN, which is generally four times faster than the same document hosted in a different format, and it's often 10 times less data. That's pretty great. So what if there was a way to go from that fast first load using AMP to that reliable performance, that immersive experience with progressive web apps? So here's an example of the Washington Post. Today, if you go to Google News and you see that AMP carousel and you go to an article, you'll be reading it inside the CDN hosted version. So it's not on the Washington Post servers, but while you're reading it, the AMP install service worker element will go and install the progressive web app bootstrapped service worker from the Washington Post. So now, if I click a link from this article out to someplace at the Washington Post, instead of the offline dinosaur, I'll get a reliable service handled by the service worker, and it'll load instantly. This is pretty great. So this is also leading edge stuff, and it's been hard to do until recently. DevTools are evolving very fast, and this is the new application tab in Canary and Chrome Dev, which helps verify some of this stuff, but as good as this is, wouldn't it be great if there was a way to do this at the command line or in your CI? That's what Lighthouse is for. Lighthouse is an exciting new tool that gives you a Chrome extension if you want it, that can help verify that you've met all the requirements to get to that add to home screen prompt, and it's also available in a command line form so you can run it as part of your continuous integration. So there's a ton of new capabilities that are coming to the web that unlock other sorts of applications once we've earned that right to be on the home screen. There's too many to talk about. I'm incredibly excited about WebAssembly and what WebGL are two are going to do this year for games and what media capture and streams are going to do for social use cases, but there's two specific capabilities I want to talk to you about that you'll hear more about later today from Chris Wilson that I think are going to really, really make it so that the web is a first class citizen. The first is the web payments API and the credentials API follows that. So web payments, what's that? So web payments is a way for you to not have to fill out forms with the worst keyboards in the world when you want to check out on the web. It lets you do one tap checkout using cache data that the browser already has. So here, for instance, is a Shopify checkout flow. I can tap the checkout button and then I'll get a pre-populated list without ever having to fill that stuff in. And if it looks good, I can tap it and then I'll be getting a confirmation screen. It all worked. I didn't have to enter any new data. That's pretty great. In fact, if Android Pay or some other system provided payment instrument is available and the site supports it, this can go as simple as a single tap or a confirmation. I think this as a standards-based way to get this capability available pervasively. Shipping this year is so exciting. Similarly, the credentials API is going to also remove a bunch of typing and tapping and autofill corrections and all that stuff that isn't great to do on phones. Like native apps, we'll be able to do one tap sign-in. If the site knows who the user is, it'll be able to request using existing system credentials that the user log in. And that can be a single tap. In fact, if the user has already been there, this can be automatically done. This is going to accelerate how we deliver first-class experiences on the web, in addition to all the progressive web app technology that browsers are already shipping. Now, you might ask, how is that stuff doing? And I'd say well, but I think I'm incredibly biased. But you don't take my word for it. To tell you more about how it's actually going, I'd like to invite my colleague, Tao Tran, from the partnerships team to take a look at how progressive web apps are performing in the real world. Thanks. So as Alex mentioned, I work in global product partnerships for the Chrome and web platform team. So that means I get a chance to talk with lots of different companies and sites and to tell them about all the new web capabilities today, building progressive web apps that are going to be reliable, fast, and engaging experiences. And I often spend a lot of time with partners thinking about helping them think through how do you develop a mobile-first strategy for the web. So Alex really walked through a ton of new capabilities that are available today and you'll hear a lot more over the next couple of days. So the whole point of coming to these conferences is that we want you to get excited and motivated to really want to build new things, to start digging into these APIs, tinkering with all this new stuff. And so it's kind of like a kid kind of playing around with a new toy. And so this is my three-year-old the first time we introduced Plato to him and he thought the possibilities were endless in terms of all the things that he could make. So I had to choose between a kitten or my son, so I decided to go with my son. So, you know, he's like being extremely creative. He even was trying to convince me that green Plato pizza was going to be so good. And so this is the type of energy and creativity that we want you to bring back to your teams and to your company. But I also realize is that the reality is that when you get back to your companies, you're probably going to have to pitch and talk about how you want to start a web project. I know many of you have probably already started looking at these technologies and you may be getting questions from different people inside your org, like how much time is this going to take? How many resources it's going to take? What's the ROI? You know, all those like annoying business and resource type questions. And I hear it a lot from our partners. And so what I want to do is actually give you a framework for how you can think about you know, building the case for investing in the web. And so oftentimes, I think the dreaded question that every developer, you know, gets is, okay, build me a business case for why you want to do this project. And as a developer, that's kind of code for actually don't try anything new. So you start feeling like this. So for those of you who have kids, I think this is a very familiar, this is when he's in a tantrum mode, when I ask him to do something and he doesn't want to do it. But in all seriousness, we want to help you build a case for the web. And the goal is to walk away from the next couple of days where you can actually talk about new capabilities and make the case for why it's critical to invest in the web platform. So I thought about all the learnings I've gotten and all the feedback I've gotten from, you know, all the different partners across the world. And when people say, hey, I have to prioritize this, I need to figure out how this fits into my roadmap, it basically boils down to two critical questions. Why is this important? And how do we get started? And a lot of times, partners just want to have an understanding of, you know, what are some numbers that you can share and what are different approaches so that this feels accessible and feels like I can scope this for my team. And so to talk about what's important or why is this going to be important, I'll just give kind of a brief overview of some key metrics that folks on the business side often like to think about, reach, acquisition and conversion. So the first one is reach. And here we'll just take a look at the overall mobile web market and see if it's growing. Alex talked about how people are spending so much time in apps. And so what we want to take a look is just to see what the mobile web audience looks like. So we'll take a look at some of the Chrome numbers that we announced last month. So Chrome announced that we now have a billion monthly active users on mobile alone. This is incredible for a couple of reasons. One, for those of you who may not know, Chrome on mobile was only came out about four years ago. And this time last year, this number was only 400 million monthly active. And so what you're seeing is that there's tremendous rapid growth on the mobile web. And then we look at reach, drilling down to more site level data. ComScore data, taking a look at the top thousand apps and websites and comparing monthly traffic for apps, native apps versus the web. And not surprising, it's two and a half times that, the reach of the mobile web is two and a half times that of apps. You can probably see it in your own numbers. So it's worth kind of digging in to understand what your overall mobile web, mobile traffic is, and then break it down between your web and app. And anecdotally, I've heard partners say somewhere between 50 to as high as 90 percent of their mobile traffic actually is on the mobile web. So now let's just spend another minute on acquisition. So you have this incredible reach and you still need to bring users to your site. And this often sits with the marketing team, or your growth teams. But when you're trying to make a case for investing in the web, you should understand all the different forces at play here. And so with acquisition, oftentimes you're probably paying to get users to your site. So it was really cool when we saw that Celio, which is a platform for buying and selling goods, it's a startup, actually publishes that about user acquisition costs. They started building a progressive web app and then saw that the engagement numbers between progressive web apps and their native app was comparable. And so then he, the CEO started digging into, well, if it's comparable from an experience standpoint, how much is it costing me to get a user into my native app versus the mobile website? It turns out it was 10 times cheaper to get a user onto their mobile web experience. So for those of you who are familiar with the acquisition costs, this is probably no surprise, but it was really great to see someone dig into the numbers and then share it publicly. And so the next piece after conversion, I mean after acquisition is, are my users converting? So it's awesome, I've reached the coming in and, but am I actually getting them to frequent my site more or conversion could also be defined as completing a transaction when the money really comes in. So AliExpress launched a progressive web app last month during IO and it was incredible to see within days of them rolling out their progressive web app experience. They saw huge increases in engagement numbers, two times more page views, 74% increase in overall time spent across all browsers. And what was telling was, we often get the question about Safari on iOS and is this going to be a good experience across the board, especially if they don't yet support progressive web app features. So we actually asked AliExpress to dig into their conversion numbers which they saw increase across the board but to segment it for iOS specifically or Safari specifically and they also saw an 82% more conversions on iOS and it just shows that AliExpress already had a good mobile experience but they continue to invest in it to make it more engaging and fast and immersive and their iOS users also benefit. So it's just good all around to actually invest in your mobile web experience and to make sure that you know, you actually deliver experience to users on all platforms. And so this really cemented, I love this quote that from the head of mobile at AliExpress where she really just talks about investing in the web experience across all browsers and not only did they see huge benefits on browsers that support progressive web app features, they saw a bump across the board and it's just a sign of a really great investment and they'll know it'll pay off once other browsers continue to evolve and ship these APIs. And so this is a model that I thought was really great. I can't take credit for it, my colleague put this together. So when you think about all your potential reach bringing people in hopefully at lower acquisition costs or likely at lower acquisition costs for the web and then your improving conversion start to take a look at these numbers and they add up to pretty good math, profitable math I assume. And so this is just a way for you to think about why it's so important and why it's great to invest on the web. And so then the next question and this is one of the tougher questions to try to handle is how do we get started? So a lot of people say to us you know these technologies seem really intimidating especially as I'm talking to my management team. So how do I... So do I have to convince my team to do a complete overhaul? And the short answer is no. Alex painted a picture of what's possible. You know giving you a vision of where we want the entire mobile web to go with these amazing experiences but we also recognize that it's complicated to bring in these new technologies especially at larger companies where you have sites with legacy code and architecture and so we want you to think about this as an ongoing journey to invest and build on the web. And so the first step is HTTPS which Alex already alluded to and my colleague Emily Schechter will talk about kind of myth-busting through HTTPS later today but it's critical because all these new features will only be available over HTTPS so it's not already on your roadmap it should be. So now I want to walk you through partner examples and how they've actually approached building and experimenting with all these new web technologies. So the first one is starting from the ground up. So this is, you know, when you're able to just rethink or reimagine what your mobile web experience should be. I know very few sites actually get the opportunity to do this but when you do you really are able to unlock so many of the capabilities of service worker and all these amazing features. And so I want to talk about Conga. Conga is actually one of the largest e-commerce players in Nigeria and they decided to do a rethink of their mobile web experience and just build and basically build a progressive web app that was going to be very comparable to their native experience. And actually the director of engineering Andrew is going to lead a session talking about how Conga is approaching their progressive web app building tomorrow. But what was really great to hear yesterday was that this was a cross-platform effort even though they were building a progressive web app their iOS and Android teams really collaborated to make sure it really truly was an app like experience on the web. And so the Conga experience you know not surprisingly is focused on being fast and performance and reliable and the most critical thing for their users is making sure it doesn't use a lot of data. And so in early testing they saw that for initial load it actually used comparing to their native app experience it used 92% less data for their progressive web app and then that critical moment of converting the user to actually completing a transaction they saw that it actually used 82% less data as compared to their native app. So again seeing terrific stats when you're able to kind of invest end to end and then start from the ground up. But we also know I mean as I mentioned it's really hard to catch a company at a moment when they're actually going to rebuild something or going to change you know architectures or frameworks. And so I want to offer why don't you build a simple version and a couple of examples of how that's being done. So Air Berlin did this demo at IO which I thought was terrific. They knew they couldn't change the entire site experience and so they thought about well is there a segment of my site that I can change or convert into a progressive web app and here they looked at the post booking experience. So imagine like so the pain point I think that we all recognize is that when you're at the airport you're frenzied you want to just easily be able to access your boarding pass your itinerary information maybe your destination information but the connectivity is pretty unreliable and so they wanted to have this customer journey details available offline and so they used they leveraged service worker caching to enable this and what they saw was that the initial loading time was less than a second because they've done a ton of optimizations but even faster with service worker for subsequent loads and so even if you're offline or you land and you're in another country where you don't have Wi-Fi access all your destination and itinerary details are available on your device. So Alex talked a lot about the Washington Post earlier and you know we got a lot of questions about how do they you know why do they build this you know when are they going to transition into a bigger or a more productionized site and so the posts you know what they wanted to do was they wanted to do a public live demo to show what's possible so they took their top stories news feeds and said you know let's go ahead and just build this really fast immersive experience and they wanted to be able to show it off publicly but also internally as you know folks who are in publishing newsrooms different people in advertising their executives and what they saw was that you know everyone is obsessed with speed at the post and in their Progressive Web App they saw article page loads times inside the Progressive Web App hit 80 milliseconds so now that's the bar and that's the use experience they want to deliver and I'm happy to say they're actively exploring a roadmap of how they're going to evolve this to that it's going to be available to a broader set of their mobile web audience but even sometimes building a simple version or getting a site or a section of your site to a Progressive Web App could also be hard and so we've seen people just focus on a feature pick an API or a feature that you believe will have high impact for both users and your business so the weather company folks we know if you're familiar with Weather.com you know they've been looking at Progressive Web Apps for a while and all these technologies and what they wanted but they were asked to prioritize what's the one feature that's really going to be great you know ROI and so they decided to go after web push notifications and what's really great is that they went big on this one feature they launched about a month and a half ago and they actually launched in 30 languages globally with web push notifications and what you see here is actually the how you can decide which type of notifications you want local, national or government issued alerts by the way these are all notifications that are available in their app so they basically made it parity with the web or make the web on par with what app notifications were and then booking.com as you know a major travel player where you know they had been looking at all these technologies and they ideally I guess we could try to build a full Progressive Web App but that doesn't work for their business they're extremely data driven they test everything and so they needed to work in small steps so that they're able to tackle different issues learn things quickly test and optimize and so Jesse Yang who is quoted up here is going to actually lead a session tomorrow talking about bookings approach on their journey to building a Progressive Web App and so I really want to you know emphasize that everyone will take their own path whether it's building from the ground up doing a simple simplified version or using a single feature there's no one size fits all and I want to make sure that you do the path that's right for you and so that it feels accessible so these are just a sample of partners globally who have started shipping or actively looking at these Progressive Web App technologies and again no one partner has done the same approach they've again modified it and really thought about what's important for their users and their business as they're thinking about investing in the web and to help you with this journey of building Progressive Web Apps we're pleased to announce that Udacity now has a nano degree program and it's an extension of the senior web developer nano degree where it's a short series of classes and projects and then you'll complete when you complete the course you'll be able to architect and build app like experiences on the web so in closing I guess I did have to include a cat in here but in the corner so it's amazing to see so many people here I was just commenting to the Chrome team backstage that this time last year we were just talking about service worker and the web push API and Progressive Web App as a term was still being socialized and so it's incredible that I'm standing here today about a year later where we have a dev summit dedicated to Progressive Web Apps so we've got an exciting lineup as Alex walked through so hopefully you'll stay for all the different sessions and at the end of it we want you to leave the Progressive Web App Dev Summit really inspired and confident about building the case for the web and more importantly we want you to go build something great thank you