Tell me again why we're wearing the suits. Oh, because they said, make it jazzy. And we decided that that meant suits. If you got some mistake. I feel like an enterprise Java developer or something. Well, then we don't have time for this, mate. We'll be fine, we'll be fine, we'll be fine. Whoa, Jake, you need those. Sorry about that. I just, I feel so much more comfortable now. Hey, you've got 10 seconds. Get ready. Oh, uh. We're not jazzy enough. I don't know what we can do about it now. Crump Dev Summit 2016. How is everybody doing in the room? You can do better than that. Right. Up at the top. How are you doing? The front. Yeah. The front gets it. The left. Yeah. The right. And the live stream. Wait, that's not going to work. Yeah, that's not going to work. Actually speaking of the live stream, if you are joining us on the live stream, thank you so much. There'll be viewing parties around the world, people in their offices in their homes. Thank you for joining us. It's lovely to have all of you here. We know it's very busy, and that's awesome that you've made the journey to come and see us today. Absolutely. We have some, you know, matters to deal with before we get on with the show. Absolutely. One of those things is the code of conduct. You know, we have a code of conduct that has all good conferences, all conferences should have. It goes something like this. You know, we encourage you to be excellent to each other by saying hi to new faces and building on one another's ideas and reporting any uncomfortable experiences, of course. We have a zero tolerance policy for harassment of any kind. And please do share your experiences, like the positive or negative with speakers and the staff. The code of conduct is posted around the building and on the website. Apologies for reading that from my phone. It's the official statement. I wanted to get it right. But from a personal perspective, like, we've been in the industry now, like, over 10 years. Yes. We're kind of part of the old crowd now. And I don't know if it's too optimistic to say that in that time things have started to get better, a little bit slowly, but surely. But it feels like now, more than ever, like, we need to double down. You know, we need to be kind to everyone, welcoming to everyone. And we need to be heroes to those who are having a great experience. Like, no matter what's happening out there, we need to make it right in here, in this industry. So we've got two days worth of talks, breakout sessions, code labs, panels. And, I mean, as the talks are done, the videos will start to go up onto the website as well. So keep an eye out for those. And you can also set notifications for any sessions you're actually interested in on the website. You're shilling for some work that you did. You did the notifications, didn't you? Don't know what you're talking about. Right. You've heard enough from us. We should get things started. And no finer way than to do that with the keynote with the VP of Chrome's engineering, Darren Fisher. Please give it up for Darren Fisher. You guys are awesome. Welcome, everyone. Welcome to the Chrome Dev Summit. I'm so excited to be here. Very happy to be able to share our enthusiasm, all the excitement about the web ecosystem with you, and talk across these two days about all the things we're doing to help you be successful building for the web, about all the things we're doing in Chrome. Very excited. So let's get into it. So our mission on Chrome, our mission is to move the web platform forward. This is as true today as it was when we first got started with Chrome nearly 10 years ago. So we're very excited about that. Like I said, over the next two days, we're going to have a lot of content for you, a lot of great stuff talking about how we're working to try to make the web better and work with you to create great experiences on the web. Now, ordinarily, at the beginning of these talks, we usually update you on the number of Chrome users. In fact, last time at Google I.O., we mentioned that there was over a million Chrome mobile users, which is awesome. There's been tremendous growth. But this year, I want to present a slightly different number. This year, I want to share, or sorry, not this year. It was the same year. But at this moment, I want to share that we have over 2 billion active Chrome browsers. This is across mobile and desktop. So rather than focused on one platform, I wanted to make this point that there are just a lot of Chrome browsers out there. And well, that's great for us and everything. And I don't mean for you to be excited about that. I think what's exciting about this to you all is that when you're thinking about building for the web, this means there's a lot of browsers out there that implement the latest web standards and implement all the latest and greatest features that when we're talking about how to build for the web, how to take advantage of these new things, that's reality. You can actually take advantage of that. There's a lot of users out there with modern browsers. And it's not just Chrome. There's lots of other browsers that are implementing the latest standards too. There's a lot of energy and excitement in this whole space, which is really, really great to see. I think it's fantastic. And so it all gets to the point that the web has tremendous reach. We know this. This is why it's such an attractive platform.  And that low-friction is all made possible because of links, URLs. That's the super power of the web, right? We're very used to that. And the links are getting even more exciting. So I wanted to invite you to pull out your phone. If you have an Android phone or if you have Chrome on your iPhone, there's beacons in this room, Bluetooth beacons. So make sure you have Bluetooth turned on. And if you're on an iPhone, you don't have Chrome set up, right? You can check this URL here. It'll give you instructions. But the point is the physical web made possible because of Bluetooth beacons and your Android device, observing those beacons and sending URLs out into this room, URLs that are contextually interesting to you. So in this case, there's a beacon broadcasting the URL for the Chrome Dev Summit web app. So it makes it very convenient. This is sort of leaning on the power of URLs. As a user, you can just quickly go under the notification shade on Android, click on the physical web entries there, find yourself on an experience. There's not much hassle to that. It's really great. Now there's another beacon in the room for an app called Polymon, a web app called Polymon. This was created by the Polymer project, Polymer team. So Polymon is a free-to-play, location-based, augmented reality game. It uses your mobile device's GPS capability to locate, capture, battle, and train virtual creatures called Polymon. That sounds kind of familiar, right? Anyways, so you collect Polymon by locating members of the Polymer team in the real world in this conference venue. So check it out, it's really cool, it's a lot of fun. So like I said, contrast that seamlessness, that ease of finding yourself on experiences thanks to the web with the cost of installing software. That fiction really matters. So by some estimates, every interaction step that you expect a user to take in order to get to your experience can cost you up to 20% of your potential users. Think about that for a moment. Compare one tap to, say, three taps. That means you're potentially losing about a third of your users. Or imagine four taps versus one tap. Now you're potentially losing half your users, roughly. And so that's a big deal, right? We all know this, that's why we're all here. We're excited about the web. We know this potential, it's real, it's awesome. And so the web, the web is really great on mobile. We've been very focused on the mobile web for some time. And of course the web didn't grow up with mobile being a reality, but the web has been awesome for, the mobile has been awesome for the web. And it has really helped expand the whole market for the web, making it so much more easy to reach users. Think about it, you have a mobile phone in your pocket. The fact that you can sit on your couch and not have to get up off the couch to grab the laptop, but you can just pull out the phone, browse the web, access all this wealth of information, shop for things, et cetera. It's so convenient. Just recently I pulled out my phone, my Nexus phone, and I bought a Pixel phone. It was so easy. Of course now there's a delay, probably, by the way. Anyhow, of course we know that the web has lots of challenges. It wasn't, again, built with all of that in mind, with a mobile in mind, and all these challenges, these constraints have led to innovation, really. And we've all, as a community, had to figure out mobile, and we've done, made a lot of progress. So there's gonna be a lot talking about that. And of course the mobile web has evolved a lot from the early days. And this chart is just a reminder, I think most folks are familiar with this, that mobile web usage has, what is that? Anyways, mobile web usage has far eclipsed desktop web usage. This is, you know, going back a couple years. And so I'm sure many web developers are familiar with this, and it means building for mobile web is a priority. And mobile web brings with it so many challenges, of course, mobile devices are vast and very different screen sizes, CPU constraints, memory constraints, power constraints, all manner of constraints, and of course connectivity constraints. We're all familiar with the good old offline dinosaur, right? And of course, connectivity constraints are not just about reliability, they're also about bandwidth and latency. And some of these challenges are extremely acute for a lot of your users.  And if you look at developing markets, it's even more of an issue. Nearly two thirds of users in developing markets are stuck behind 2G connections. That's a big deal. Infrastructure's improving, but we don't expect this 2G to go away anytime soon. It'll still be with us. So there's a lot of challenges there to address 2G. And the web itself, the whole point here is that the web is a very big thing. It's worldwide. It's in the name, it's everywhere. It's a wonderful tool for so many users. There's easily over three billion users across the whole world using the internet. That's like 10 times the size of the US. So if you think about it, there's just a large addressable population. And nearly 2 billion of those are in developing countries. So we look at current estimates of internet users. We see that, well, there's roughly about 280 million in the US, about double that in India, about 460. And in China, upwards of 720 million. So the web is truly global. There's a lot of users all over the place. And if you look at just the growth last year, a lot of it's concentrated in places like India, where India saw about 30% growth, over 100 million new users coming online. That's really remarkable. That's 10x the growth of China, 100 times the growth in the rest of the world. And emerging markets is where a lot of the new growth is gonna come from as well. Just focusing on India, for example, 65% of that population of that country is not yet online. That's 860 million potential new users. 20 times the number of users not yet online in the US. And so I think, actually, the reason why I make a focal point of India is not just that there's a lot of users there, but actually that we're seeing some of the most interesting and remarkable web development happening in India. And the reason for that is because a lot of these users who are connecting to the internet for the first time are doing so, you know, not from a laptop, they're doing it from a phone, a phone that is very underwhelming by what many of us are used to. These are phones with 512 megabytes RAM at most. Very limited screen sizes, very underwhelming CPUs, limited, I already mentioned memory, limited storage, right? A lot of these users, they don't have a PC where they're going and backing up their data, that phone, that phone, there's the computing device, that's where they're storing information that they care about. It's not easy for them to install another app. In fact, it's very common, you talk to people, they say, I went and installed the app, use it for a little bit and then uninstalled it so I could have that precious, precious storage space for something else. So we're seeing a lot of innovation in this area because it turns out the web is actually a fantastic tool. Think about it, the web is designed, it's a streaming platform, you can bring part of your experience down incrementally, it's designed for constrained storage, it's great for constrained networks, actually. And thanks to a lot of the new APIs that have been going into the platform, we're enabling developers to have a lot more control over how their web experience works, how they can deliver the experience and how they can create a good experience for users. And we're gonna talk a lot more about that. So there's just a lot of innovation happening here out of the need to address those constraints. And it's really that necessity that is leading to so much innovation. And I think it's really exciting. And so my point really is that web apps work really well in emerging markets. They also work really well here and all the approaches, techniques and technologies that have been developed that work, they're working for folks in India, they work really well here too. I think we all know what it's like to have poor connectivity, but we also know what it's like to have LTE. So this is the point. Web works really well in emerging markets. A year or so ago, we had early pioneers in this space like Flipkart showing the way, developing lightweight web experiences that could incrementally come down onto the device, be cached and deliver delightful experiences to users behind 2G connections. Other companies have been embracing this approach as well. One that I wanna highlight is Vute Media, a Vute streaming, video streaming service. This comes from Viacom 18, which is a joint venture between Viacom and Network 18. So they just set up, this is a new service and they got online very recently. They built a web experience. In fact, 40% of their traffic goes through the web. And by building for the web, they were able to really reach a lot more users more easily. And in fact, just getting started here, it took them only a matter of like three weeks to prototype an experience that they were happy with and that convinced them that they should continue to invest. And they are investing further. The next version will feature offline caching of snippets of videos so that users can preview movies and TV shows and other Vute originals easily. So that's very exciting. So this is all about building progressive web apps. I think many of you have all heard this term before. We've been talking about it for a while. We introduced it last year. And progressive web apps are not just about any one technology or any set of technologies. It's not even about anything like that. It's more about a new way of thinking about building web experiences. Web experiences that are radically improving the user experience. And we're gonna be talking a lot about this. But these experiences that you can create, the thing that I wanna show you and have you leave with is knowing that you can create experiences that are just as immersive, just as engaging, just as native feeling. Is any experience you expect to find on your phone? I think that's really exciting. Combining the power of the web with sort of the form factor of mobile and creating experiences that really delight users. And that you get a lot of value out of. And so there's a lot of different companies joining in and seeing success. And we're gonna be talking about a variety of these over the course of these two days. But I'd like to just zero in on one and take a moment to show you a demo. So this is about CNET. CNET has built an experience at CNET.com slash tech-today. It's a progressive web app. And so let me demo that for you. So I'm gonna switch over to the overhead here. So I have my snazzy new Pixel phone and I have CNET tech today added to my home screen. So I'm gonna launch it and it comes up smoothly. Nice little transition there. So we'll be scrolling of course. This is a little carousel if I can browse different articles. Oh, trying not to read the news too much. So anyways, you saw that was all very smooth, fluid, fast as what you'd expect on a mobile device. You might have, might notice that I'm on airplane mode. That's pretty cool, right? Maybe you thought I already had Chrome running or something like that. So I'm gonna just, let's get rid of that. And let's do it again. Same thing you saw before. It's pretty cool, right? Oh, just in case you didn't have any doubts, that was just a website. I added it to my home screen. Anyways, thank you. Let's go back to the slides. So really great to see the work that folks like CNET are doing, but they're definitely not alone. Excuse me. Another partner we're gonna talk about is Alibaba. And Alibaba is one of the, is the world's largest business to business platform in over 200 countries. So they built a progressive web app over the summer and they're seeing 76% increase in conversions. And this is about users interacting with support when they're interested in a product. So it's very exciting. That's a huge key metric for them and seeing that kind of increase is significant. And I wanna just make the point real for you. So like Singles Day is an event that Alibaba sees is an event in China a day where lots of, lots of shopping happens. This is an event where people feel encouraged to buy something for themselves. And the Singles Day happens on November 11th, 1111, which if you adjust for time zones is right now. And this is the biggest shopping event on the internet. And they expect to see nearly 20 billion in revenue, which is three times more than Black Friday and Cyber Monday combined. So investing the progressive web app was a big deal for them, a significant thing. And seeing these kind of conversion rates is a big deal. So I think it's great to see folks having this kind of success building for the web, building for the mobile web. And Taltran will be up shortly after me to share more partner stories with you. So progressive web apps, I talked about this before, like I said, and we've been defining them as reliable, fast and engaging. The point is progressive web apps are about creating a much better user experience, like what I showed you with the CNET Tech Today example. And by reliable, I mean things like, well, you saw how I was offline and I tapped a home screen icon, the experience should work, right? That's what a user expects. That's the point. And when it talks about, when you think about fast, this is a great stat, it comes from a double click study where they found that users abandoned, 53% of users abandoned sites that take longer than three seconds to load. Interesting thing about this is that a year ago, that number would have been 40%. So users obviously don't have the patience that you might wish they had. And so it's really important to pay attention to that initial loading experience. And you saw with the CNET example that it was very nice. And so all this is made possible thanks to the Service Worker API. But it's not just a Service Worker API, it's about using it properly and we're gonna talk a lot about that. But the Service Worker API, just to refresh you, is an API that lets you have control over your caching strategy and offline approach to building your experience so you can manage how the network is used by your web app. And that is really a huge enabler for the web platform. And we estimate about 3% to 4% of all page loads in Chrome are now going through Service Workers, which is really cool. So focusing in on performance. This is another way of looking at it and I really like this quote, it comes from a member of our team. If you wouldn't make eye contact with the stranger for the time it takes you, it takes your web app to first paint, it's too slow. So this is getting at that sort of awkwardness of like, well, I'm waiting, I'm waiting, what's happening? And first paint, that's about getting some pixels on the screen, drawing something, right? There's no reason why that can't be done quickly. There's lots of challenges, of course, but we wanna show you how to be successful at that. And it's not just about getting some pixels on the screen, it's also about making that experience interactive shortly thereafter. And so with that in mind, you're gonna hear us talk a lot about this metric, getting your site interacted within five seconds over a 3G connection. Again, not everyone is lucky enough to have an LTE connection. So focusing on 3G seems to make sense. And if you have an LTE connection, you should be able to do a lot better than this. But five seconds is a great metric that we're gonna talk a lot about. And this is made possible thanks to things like Service Worker, but that sort of leads to designing your web application better, chunking it up better. But there's other technologies like HTTP 2.0, which are a big enabler here. And oh, by the way, Service Worker API requires TLS and HTTP 2.0 brings TLS. So these things all work together very nicely. We're very excited about these technologies and helping you achieve these kinds of goals and build fast experiences for the web. So when it comes to engaging, you saw how I had a website on my home screen. It was an engaging experience. Normally what you expect from the mobile web, well, you expect that it's easy for users to land on your site. It's so easy thanks to the Power of URLs for users to discover content. But what about getting back to that content that they liked? Well, oftentimes that means the user might have to remember to think to bookmark your site or remember the origin or remember all the steps that got them there. Of course, when it comes to mobile, that's nowhere near as effective as just getting your icon on the home screen. So a year ago, we focused on this problem and we introduced app manifests and an ability for the website to indicate that it would be great to prompt the user to get them to add the site to the home screen. And this has been a great feature. You think about add to home screen as sort of like a lightweight install. That's kind of the experience that I showed you there. And on Chrome, or sorry, we've seen from partners a lot of great success from add to home screen. This stat comes from Alibaba, which I was talking about earlier. They've seen four times more engagement with Alibaba thanks to add to home screen for users who have added Alibaba to their home screen. So that makes sense. It's not actually surprising. It's good to see it borne out like this. So add to home screen is an important thing. We know that intuitively. And indeed it is based on the data we're seeing. We've also been tuning add to home screen. So we've been playing with the heuristics. One of the things we didn't want to do was just spam these prompts in front of any user any time. I want to be thoughtful about it. So we've been tuning them and seeing, by tuning them, by reducing the amount of engagement required on the site before we show the prompt, actually getting 48% more conversions or installs or users adding these sites to their home screen, which is a really great stat. And then all without actually increasing the number of users who ignore the prompt or dismiss the prompt. So we feel like there's a lot of opportunity here to continue refining. And so I just want you to know from the Chrome team perspective, we're working to tune this and make it work even better. We're also playing around with different formats. Why not call it install, actually? And so we're definitely experimenting with that. I think there's some interesting questions here, but it's exciting to try. And I'm really excited to share that we're also looking at experimenting with deeper integration into the Android OS. And this is really cool. So today, the way add to home screen works is it's putting a widget on your Android device. And what that means is the user, if they remove that, they're not gonna find the app, the icon in the all apps. And that can be confusing. So we're working to improve that so that when you go through the add to home screen flow, what it actually will mean is that your website will actually be available in all apps. It'll be in places where you expect to find app icons on the device. This has been a big effort. There's a lot of work still to do. We're experimenting with this. It's gonna be in preview shortly on the Chrome Dev channel for very, very excited about this change. And some of the other things that go along with it are things like giving you the ability to update the icon and change the name of the thing that's been pinned to the home screen, which is a really obvious thing that you should be able to do. And then also we're experimenting with granting notification permission when the user goes through the add to home screen flow. That's something that a user actually is used to when they think about the way Android permissions work. So we're just looking to smooth out the rough edges here, make the experience work a lot better. I'm very excited to share that. And Paul Kenland will be up here a little bit later talking more about this change. So the other big way that the developers like to reengage with users on phones is with push notifications. This is something that we've been working on for a while, been seeing a lot of adoption. It's a really key feature, think about it. Users who are interested in getting notifications, it's a great way to remind them that there's interesting content on your site. And there's been a lot of adoption. So 18 billion push notifications sent daily, which is a big number. Things is exciting, but even more exciting. So we've seen over 50,000 domains using push notifications. This is really, really interesting because it sort of speaks to the long-tail aspects of the web. The web is really great at enabling the long-tailed developers. And just to give one example, this comes from Carnival Cruises. So on Carnival Cruises site, you can book a trip. You can put it on hold. Maybe you're not sure yet if you wanna buy it. And then they'll offer a feature to notify you when your hold's about to expire. And they get about a 24% opt-in rate for this, and when the notification appears in front of users, 42% of them actually click on the notification and land back on the Carnival Cruises site. That's a big deal. These are users that they might not have had coming back otherwise. And so a different topic, seamless sign-in. This is something you're gonna hear more about later today. This is about the credential manager API that we introduced back around Google I.O. But now we have some early partner results and I wanna share those with you. In the case of AliExpress, they're seeing an 85% reduction in sign-in failures, which is really cool. And Pinterest seeing about a 10% increase in desktop logins. So these numbers are all about, these are early data, but people are seeing success. And the nice thing about the credential manager API, if you're not familiar with it, is that it's all about avoiding situations where users have to re-enter their username and password because the browser already has that information and we can negotiate a seamless way for it to allow you to log in. And getting logged in and signed in is really important, especially for your engaged users. And we're also gonna talk a lot about payments because we know this is really important part of the web ecosystem. A lot of work's gone into improving payments on the web. We've of course put a lot of effort into autofill, improvements in Chrome, but there's also the payment request API, which is all about bringing one tap payment to the web. Very excited about this. Zach will be up later talking about this. So I think it's clear that building progressive web apps makes a lot of sense. There's a ton of value here. It's a lot of work going into improve the platform and make it so that you can be really successful building progressive web apps. And we also wanna take a moment to talk about some of the tools that we're building to help you be successful. And these are just some of the tools that I wanna highlight. We're gonna be talking about these throughout the conference and these tools and others. First is Lighthouse. This is a Chrome extension that we built that helps you zero in on some of the things you could do to improve your progressive web app. It's sort of an analysis tool. It helps you optimize your progressive web app. You'll hear more about this from Paul Irish a little bit later. And the second one is real world condition testing or simulating network and CPU conditions that you might find in the real world. This is a new feature of the DevTools in Chrome. It's very handy, very useful. Of course, there's no real substitute for real actual device testing. A lot of your users do not have fancy new pixel phones and so on. And so it's important to test with a diversity of phones to make sure you're building an experience that works for everybody. And Alex will be up later talking about how to do that with, again, with DevTools. There's also a new security and application panel in DevTools, which are really handy. You're gonna hear more about these, but they're really helpful to help to enable you to explore what's going on with your progressive web app. And being able to explore the cache is really a nice feature. And so the other tool I wanna take a moment to talk about is Polymer. And we've been working on Polymer for a while now. This comes from the Chrome team. We built Polymer in the beginning because we wanted to do it in conjunction, in concert with the improvements to the web platform. And Polymer is all about web components and web components are a new feature of the web platform. We wanted to develop web components the right way. And building Polymer was a way to sort of guide that process from our perspective. And Polymer's great library makes it really easy to build for the mobile web. And that's important. Again, we wanna make it easy for everyone. But web components, of course, there's been quite an arc in the development of web components. The initial versions that we launched in Chrome, they didn't see a lot of adoption from other browser vendors, that's unfortunate. But we went back to the drawing board, worked with them in the standards bodies. And today I just pleased to announce that we're seeing a lot of shared enthusiasm for these APIs. In fact, Apple has started shipping some of them. Like Shadow DOM V1, this is a big deal. If you're familiar with Polymer, Shadow DOM is the most complicated piece of the whole web components set of technologies. And getting this implemented natively means using web components can be done in a much more lightweight fashion. So it's great to see. And even on the tip of tree of web kit now, custom elements V1 landed. And it's not behind a flag or anything. So it's fantastic to see all this progress. HTML imports, we'll figure it out. And there's a lot of partners adopting Polymer, using it at scale, including many products from Google today, such as YouTube. Really, really excited to see all of these folks seeing success with Polymer. And at the Polymer Summit just a couple of weeks back, we announced Polymer version two, which in addition to being based on these new V1 specs of web components, also is a much lighter weight, faster take on Polymer. We're really excited about it. You're gonna hear a lot more about it later. In addition to Polymer being a library that helps you build web components, we've also fleshed out the whole Polymer a bit more with the Polymer app toolbox to make it easy for you to build applications. A lot of times, this is where folks are struggling. This makes it a lot easier to prototype and build experiences. And really happy to announce that there's been a lot of interest in the community around web components. We have this new site beta.webcomponents.org, which folks are just pouring in different elements that they've built. So it's a great community site, great opportunity to kind of see what other folks are building and take advantage of these components. Again, the whole point with web components is these are reusable chunks of code. And technology that you can use. So speaking of web components, I also wanna talk about AMP. And AMP is another great tool for helping you get on the web and be more successful in the web. And AMP is actually based on web components. It's got a custom markup, which are just web components. There's over 700,000 domains now publishing AMP. So it's seeing a lot of adoption. And this is web components being used at scale. And AMP is, like I said, a great way to get content in front of users. And it can also be a great way to get content in users that leads them into your PWA, leads them into your progressive web app. And we'll talk a lot more about using AMP and PWAs together tomorrow. So those are some of the tools. Also wanna just make a few notes here about predictability. And what I mean by this is, we wanna make the web easier.  So this is a big focus for us. And our goal really is, like I said at the beginning, to move the whole web forward. And that includes making it one platform as much as we can. And so like I said, the web should just work should just work for you. So we're focused on web standards. We're focusing on working with other browser vendors. This collaborations that we've had are really important. It leads to things like I said, with web components and service worker API and so on and so forth. And we're also working to sort of get better doing new feature incubation and figuring out how to work with the standards community to bring features to market in a better way. So a lot of progress here. Our focus is like I said, just on making things easier for you. And on that note, I just wanna share a tool that we put together, which is this browser bug searcher. Just a convenient tool lets you search bugs across all the different browser engines. I think it can be very handy. So check it out. And so also on the education front, I wanna mention that there's been a lot of, so in addition to the Chrome Dev Summit, which your head, and that we had a year ago, we also had the Progressive Web App Summit in the summer. And we've been having these Progressive Web App roadshows, which is taking content, talking about progressive web apps and helping developers be successful. So in fact, we just had one yesterday in San Francisco. Maybe some of you attended it. But this is content and code labs and scripts that you can take and use yourself to put on a Progressive Web App event in case there's not, in case the road show isn't coming to your community. We're also working on longer instructor-led education programs on Progressive Web Apps. So look for more of that to come. So looking ahead, I just wanna wrap up a little bit by saying that, obviously the web is a big deal. You're all here for a reason. We love the web, right? There's so much energy, so much innovation, so much enthusiasm. A lot of excitement. You can see how this path of figuring out the mobile has gone and how we're accelerating towards, figuring out these wonderful Progressive Web App experiences that can make the experiences so much more delightful for users and help the developers be successful reaching those users. There's a lot of other new technologies that I didn't mention that are coming to the web and enabling other really exciting opportunities. Think of features like WebAssembly. There was just a cross-browser developer preview announced recently on this. WebAssembly is an evolution of Asm.js, which was informed by some of the early work that we did on Native Client. WebAssembly combined with WebGL and now WebGL 2.0 bringing OpenGL ES3 to the web. Imagine the kinds of experiences that this can enable, this technology can enable. Obviously things like more immersive games, but a lot of other really cool stuff. I'm very excited about that. And then you combine some of those technologies and the things we're doing with new platforms like VR. Think about WebVR and actually the kind of convenience that the web adds and the kind of capabilities it adds to the VR. You have your headset, you wanna be able to like dig in on something and explore things. And if you have to stop to install apps, it's not gonna work great. And so the web is actually a wonderful fit for such an environment. Think about AR, augmented reality. Here you're looking out onto the real world and this is future stuff. Imagine something tagging real objects in real space with not just names and descriptions, but like URLs that you can go and find out more about that object. URL is such a powerful tool in that kind of world. And the web is such a great fit. And I think it's on us to kind of explore and develop and all of us, I mean, to figure out this kind of, figure out how the web can be leveraged in these kinds of environments. Very excited about the possibilities there. And then think about Internet of Things, IOT. You saw earlier the example of physical web to get access to URLs that are contextually relevant to you. But imagine you're walking up to some kind of device and it's broadcasting a URL to you and that URL is the application that you use to control that device. Thanks to APIs like web Bluetooth, you can imagine how that would work, right? You walk up to some kind of a device and it broadcasts a URL. Now you've got the control website and it's talking web Bluetooth to that device and interacting with it. That seamlessness, that low frictionness of the web, it's such a great superpower. You can imagine it in so many other applications. So anyways, these are just some thoughts on that. And I'm excited to see what you all will build and what we'll build together. I'm excited to be part of this ecosystem. I think it's really exciting. Like I said, we have a lot of awesome content for you today and tomorrow. So thank you for being here. And with that, I think we have a little video. Thank you all. Thank you very much. Thank you very much, Darren. Now for us, Chrome Dev Summit, it's an important point in our year because not only do we get to sort of share with you what's been happening for us, but also sort of what we think is coming up as Darren just did. But then we got to talking about this and we sort of thought, oh dear. You know, it's a two-way street this. It's a conversation. And what if the audience doesn't know web? Well, how could we find out such a thing? Well, indeed. And so we realized there is only one way to find out. Which would involve someone changing the screen over behind us. Hint to someone at the back. Oh, there we go. Hit it. Welcome to the big web quiz. Yeah, so this is a little progressive web app. Interactive game thing. That depends on Wi-Fi working, R code working. There's no finer way to make friends with production staff at a conference than telling them you're going to stress it by putting everybody on the quiz. So if you want to go to that URL, you're all up there, bigwebquiz.com. That domain was available. That's so good. Couldn't believe our look. And login using your Google account. Yeah, now when you sign in at the bottom you will see a checkbox. If you're happy to be on the leaderboard, check the box that says appear on leaderboard. And that's actually quite good if you do because it qualifies you for potentially, I don't know how to over-egg this, but it is possibly one of the best prizes of all time. We took a cue from quiz shows all around the world, particularly America. We thought, that's a bit grandiose. Yeah, but too much. We're going to do this British style. And this is what you could possibly win if you come. So that's up for grabs. If you are in pole position by the end of the day, you are in top spot, you could win. And I do believe that's something to really root out. So I hope you're all signed in. I hope you're happy to play along. Should we try and do a question? We'll do a practice one at first, shall we? Yeah, we thought. And see if the server works. I mean, the main question I want to ask is, is the server going to stay up? Is it going to crash? Because was it a good idea to do quite a bit of the code? Did someone say no? Don't say that. All failed. Rate limit exceeded. That is good, isn't it? Yeah, so I mean, we did test this. We did. With four concurrent users and we felt. We thought, what could possibly go wrong? What could possibly go wrong? We could, you know, 400, 4,000, it's all just numbers. So what we're going to do is we'll go and fix that, right? We'll go and figure out what we do to make that not limited. And shall we maybe after the next talk, we'll actually come and give this another go? A proper go. Yeah, let's do that. Okay. And we thought it was risky doing commits to the site this morning as we came in, but we're now going to actually do some at the back. Okay. That's even better. In the back. Excellent, okay. So our next speaker. Yes, but is Tower Tran. And before she comes and talks to us, well, she wasn't convinced, I think, that we would do a fair intro on progressive web apps. Never heard of them. So she had a video made. Video pre-prepared. So we're going to show you that. On that bombshell, let's roll the video. The only thing that evolves faster than technology is our expectations. We want everything better, easier, now. Suddenly downloading an app feels like it takes forever. And in many parts of the world, data is still at a premium with one megabyte costing up to 5% of a monthly wage. Let's face it though, until now the alternative to native apps hasn't been great. But that was then. Progressive web apps can now deliver mobile web experiences with a native look and feel, offering features like real-time push notifications. Adding a site to your home screen so you can easily jump back to it with a single tap. Even when you're offline, plus the ability to make quick payments on the go. And all from your browser. This is the next generation of the mobile web. So what are we waiting for? Let's go and build something great. So I want to give a great shout out to Kato Connor and our marketing team who put together that video. So you did a really terrific job, really reflecting kind of the state on what we want everyone to be building today. So I'm Tal Tran. I lead global product partnerships for Chrome and the web platform team. So that's just a fancy way of saying, I basically get to talk to all you guys and talk to a lot of different companies and sites about being early adopters of all these new awesome web technologies. So it's great to hear from Darren and get a state of where Chrome is and the overall web platform. And now I get the opportunity to tell you more about progressive web apps and what's happened over the last year. So I did a lot of reflecting the last couple of days. No, no, no, not about the other stuff. But really about kind of where were we last year at the same event. And so I went back and looked at some of the tweets coming out because the Flipkart team had just launched their progressive web app. We're really like kind of pioneers in this space. There's a lot of buzz and excitement about what's now possible for the web. I really want to echo Darren's sentiments about the emerging markets really leading the way here in terms of constraints leading to a lot of innovation. But I would say I was a bit nervous about the success and I didn't know whether it was going to be specific to Flipkart, the region, will progressive web apps actually extend to other verticals and markets. And I wasn't sure if this was going to be a hot thing for like a minute and then it would just get like shelved away. And so it got me thinking a lot about toys. So this is my son. And so he recently got a gift of refrigerator food and wanted me to build a refrigerator. And so I spent two hours painstakingly going through, building custom shelves so that every single piece actually fits so all the pieces actually fit across all of these shelves. And I think most parents in the audience would know that most toys last about a week because it literally got shelved and empty and he didn't really play with it anymore. And I wondered, would progressive web apps actually have the same fate? So was the Flipkart progressive web app a unicorn? And thankfully, that wasn't the case. And so Flipkart continued to invest in progressive web app technologies. Actually just did a big refresh of their site. They also extended it to their desktop. And they had tons of learning this past year as they battle tested progressive web apps. In fact, they just went through big billion days, which is the biggest shopping event of the year for them in India. And last year, the event was app only because they had shut down their mobile website. And this year, with the Flipkart live experience back and the web experience back, they saw as much traffic on the web on mobile as they did on desktop. So it completely affirmed their commitment to bringing the web back on mobile. And I think beyond Flipkart and the progressive web apps, we wanted to see if we were starting to see momentum in the overall marketplace. We started to see that progressive web apps organically came up as a topic at various conferences. Saw a lot of articles about progressive web apps. I have a Google alert letting me know every time someone mentions progressive web apps, sometimes I get flooded. And I want to point to three articles that really illustrate that progressive web apps is actually broadening across all industries. So Smashing Magazine wrote a beginner's guide to progressive web apps. A few months ago, Business Insider wrote about how PWAs are blurring the lines between mobile and web. And then more recently, Marketing Land, which is targeted at digital marketers, talked about how the progressive web apps could be kind of the next biggest thing. And so it was really terrific to see that both developers and marketers are all interested in these technologies. So Darren talked about the importance of your web audience being a worldwide audience. And we've seen tremendous interest from developers globally. After a progressive web app Dev Summit in Amsterdam this past June, we held viewing parties across the world. And so these are folks who actually came to actually watch together with other Googlers and with other developers in the region. 17,000 developers showed up across 35 countries to showing the enormous momentum and excitement for wanting to build with these new technologies. And my favorite tweet was that there was a viewing party in Bangladesh where there were over 300 attendees. And they were so inspired that they actually formed a human PWA and then tweeted this out. So definitely my favorite tweet of all time. So we're seeing global interest from sites large and small across many industries building progressive web apps. And so I wanted to kind of take a moment here and just kind of talk to you about kind of what exactly is a progressive web app and then really tell you real life partner stories so that you can kind of maybe get inspiration for how you want to go about approaching it at your respective companies. First of all, it's amazing to see the term progressive web app take a life of its own. We really view it as a shared definition across the entire web ecosystem. And it's great to see folks in the community continue to contribute to what is a progressive web app. And so we wanted to offer kind of our definition, but obviously evolve it to what makes sense for your site. And ultimately, it's about radically improving the web user experience. Probably just saw this in Darren's talk, but we wanted to make sure that you understand that your PWAs are first and foremost about improving your user experience, making sure it's fast, reliable, engaging for all users. And a common question I get is, wait, does that mean I have to build a native app, a PWA, and a mobile site? And the answer is no. Your web experience should just become your progressive web app. And so that also means that your progressive web app should be index and crawlable just like any other website. We've also gotten a lot of questions about this as well. And so I wanted to just note that we just posted an updated blog post from Webmaster Central Blog where we talked about updated guidance on building indexable progressive web apps. So definitely check that out. I think it just got posted yesterday. And so we want to let people know that building progressive web apps is a journey. And so we wanted to just maybe offer up some of a framework for how to think about building a progressive web app because people sometimes think, oh, gosh, it feels so inaccessible. There's just like, there's so many things I have to do. And so we wanted to say, you know, think about it as a journey. You can start off with a baseline with things like HTTPS, a web app manifest file, and a few other things. And then continue to add on more and more features over time. And so an exemplary one is about pushing your site to add more features, get even faster loading times, provide a more reliable experience offline, and even on flaky networks. So the good news is that you don't have to track all this stuff because we actually heard your feedback and we're put together a baseline and exemplary checklist of things to test and fix. It's on developers.google.com slash web. You're gonna hear that over and over again because we're really trying to be better about having a central Google resource for building on the web. And Darren already talked about Lighthouse Tool. And so really think about it as your personalized guide for a site to becoming more progressive. We're continuing to invest in Lighthouse and it will get better. So with the checklist, Lighthouse, along with testing on real hardware devices, you should be on your way to shipping a great PWA. So I'm not gonna spend this talk going into detail about Service Worker and like all the various APIs. There are a ton of great advanced sessions about that. But I now wanna dig into the impact of progressive web apps and why it's a big deal for your users and your business. So we've worked, I've had a really fortunate opportunity to work really closely with a number of partners across the globe. It's been awesome to have folks actually share stats because they want to kind of contribute back to the ecosystem and talk about the awesomeness of what they're experiencing after they've shipped a progressive web app. So I wanna run through a few progressive web apps in different stages to really illustrate the diversity of approaches, regions, and industries. So Darren talked about Alibaba, which is the world's largest speed-to-be marketplace. So the scale at which they're operating is huge. And he went over how they saw a 76% increase in conversions. So I wanna add one more detail because conversions is great, but you really want to make sure that users are coming back to your site time and time again. And so I wanna talk about how they saw an increase on iOS of monthly active users as well as a bump of 30% on Android. And so the higher increase on Android could probably be attributed to the fact that their open rate on web push notifications is comparable to their native app. Again, just increasing their overall reach of your user base. And housing.com is this major growing online real estate platform in India. So seeing incredible activity and innovation coming out of India with Flipkart and startups like Housing and Bracing Progressive Web Apps. And like most startups, Housing is obsessed with how to efficiently acquire users to gain market traction. This is probably not something that developers think about, but I bet you your marketing team is thinking about how to bring in new users and how much they cost. And so Housing took a look at how much they were spending to acquire an app download versus getting user to come to their mobile website. So the first data I wanna offer is that it cost them about $3.75 to get users to download an Android app. How much do you guys think it's costing them to get users to their mobile website? 75 cents. 75 cents, 80, 50, seven cents. So I wanna pause and we'll just observe the difference here and how much cheaper it is to get your user to your mobile website. So maybe we're saying, well, app users are usually more loyal, so maybe worth it. But for that single app download, you can reach 53 mobile web users. So that's 53 potential re-engagement opportunities. And Housing is operating with millions of users, so obviously trying to get more users to their website efficiently is a no-brainer. Yeah, people should take pictures of this and send it to your marketing team. But it's not only about getting users to your site experience, you want them to make sure that they're getting a really good user experience once they arrive. So Housing was seeing faster page loads, as well as an increase in conversions. And the housing folks are actually here, they traveled in from India and are giving a talk tomorrow morning. So definitely check it out. I believe it's the second talk of the day. So now I wanna turn to West Elm. We've seen a lot of adoption in other parts of the world, and so we're starting to see more and more here in the US. And so West Elm is this modern furnishings company, and it's on its way to doing about $2 billion in revenue. And a significant portion of that is actually coming from online. They don't have a native app, so they rely on the web to deliver the best user experience possible. And as you can probably see from your own habits, you're seeing a growing number of users shopping on mobile devices. So we're gonna queue, so I'm actually gonna demo an early beta that they just launched yesterday. So I already have it on my home screen, and so one of the key principles or tenets of them launching this was that they wanted it to be a hugely immersive experience. And so here you're dropped right into this West Elm experience. You can scroll, everything's super smooth. You see the navigation on top. They took a lot of cues from social applications, so it's highly visual. So I can tap in here, see how smooth everything looks. And I actually wanna go through an example of when I showed my sister a desk I just bought from West Elm. And so instead of me kind of searching, I just look and say, oh well, I can just go ahead and just tap. I look at furniture, I see home office, desks. And as I'm scrolling through, I see, oh, there it is. There's the desk I had purchased. And this is actually how I showed my sister the desk I bought. Very much like a magazine-like experience. And so this is the type of user experience that we're hoping all of you are inspired to build back to sites. And so this is where focusing, we talk a lot about performance and making sure that your site is super fast. But I think we really think of West Elm as a great example of how to rethink your user interactions for today's audience, which is about casually consuming and being inspired by things. Maybe the user is not gonna purchase every time they come to your site, but maybe they wanna come back and just browse in their few moments where they have some downtime. So you can check out their early beta that you are all there. And I wanna kind of now turn to Latin America. So Infobay is one of Argentina's first major digital-only outlets. It's a top publisher with a strong presence throughout Spanish-speaking Latin. And we're actually starting to see growing interest in Latin America for all these new web technologies. Infobay's primary motivation was speed and delivering news to users as quickly as possible. And it's no surprise. 65% of their traffic is on mobile. And so they took inspiration from the Washington Post progressive web app demo from I.O. And they started working with the post team and leveraging the Washington Post CMS to really roll out their progressive web app. And we're seeing that the Infobay's article pages are loading in less than a second. They're also caching content for offline experience. And so similar to what you saw with the CNET demo from Darren, this is really about a smooth reading experience and really what news should be and be resilient to flaky networks as well. And then I wanna talk to you about Lyft. So we've seen adoption with retail and publishing sites. And it's great to see another use case here. So for those who are familiar, Lyft is an on-demand ride sharing network. It was app-only for a long time. And so they wanted to make sure they could reach users across all platforms. Obviously we've seen that reach and user acquisition are critical. So they rolled out an MSI. I think there was an article about rolling out their MSI for the first time a few weeks ago. It wasn't a PWA yet, but it was just an MSI just to test the waters. And they had some internal metrics that they were looking at. And after a month, they saw five times more rides than expected coming through their mobile web. So it turns out that people were probably wanting to book rides even before they're able to download an app. So here's a gift of their user experience. And so after they saw that initial kind of success with their MSI, they went all in and said, you know, we're gonna invest in mobile web. We're gonna build a progressive web app. And so their goal right now is to achieve feature parity with their native app. So they launched in preview yesterday, ride.lift.com, and the team will continue to iterate and add more and more features over time. And so this is about making sure they can deliver a great experience for all users regardless of what platform you're on. And so, and they didn't want to actually have people download an app if they didn't need to. And here I want to point out that they're trying to achieve feature parity by also dramatically reducing the download size. They were gracious enough to share some of their stats around 17 megabits for Android. You see the bump in iOS there. And their progressive web app is less than one meg. And so the lift team is actually here and we'll kick off tomorrow morning with housing as they deep dive into how they're building a progressive web app and the benefits of being able to deploy updates and experiment quickly for the web. So the kind of the final one where I want to talk about stats a little bit, is make my trip. So we're going back to India. And make our trip is the largest, well, one of the largest travel sites in India. And what's interesting here is to make my trip folks really start digging into kind of differences in user behavior between the native experience and the mobile web experience. And so for those of you unfamiliar with the India market, like up to 90% of users will uninstall the app in six months. And so for an infrequent purchase like travel, it can be hard to remain on the user device. So after being in the market for a few months, so they shared some insights about what they're seeing in terms of their user base. First of all, half of their bookings on their progressive web app are same day reservations. And not only are they same day reservations, but this number is actually 30% higher compared to their app users. Turns out that these are generally last minute users. They just want to book right away and they prefer to do so on their mobile website. You probably are experiencing the same thing. Like when you want to get something done, you just want to get it done. You don't want to have to wait for a download. And the other fascinating stat is that in taking a closer look at first time visitors, it turns out that their progressive web app users were booking three times more on their first visit. And so this really shows the web is great at fulfilling the immediacy of intent, which is in this case resulting in more bookings. And so they're also seeing that the destination cities of progressive web, the destination cities are much more widespread for progressive web app users versus native app users, indicating that people might be booking once they arrive on site and they just want to get a booking done as quickly as possible. So really terrific staff and really kind of giving us insights into the different user behavior. And so they still have a native app experience and that will address and be great for a specific audience, but then they're also building a great progressive web app experience. And so I just want to make sure that, I talked a lot about a bunch of these companies seeing worldwide adoption. And now I wanted to spend it just a couple of minutes talking about how to get started. So have an idea of what you should be building and you can see that it can have high impact on your business. But the toughest part is figuring out how to get started, especially if you're part of a large org or you need to deal with a lot of legacy issues. And so you have to take a look at your different user experience and figure out what you want to tackle first. Sometimes you can tackle the entire site, sometimes you can do a section like CNET Tech Today, they did, they ended up shipping a progressive web app for a section. And if you're a larger brand, sometimes it's easier to start with a smaller site to become familiar with the technologies and then extend out to your flagship. So here I want to walk you through a journey that the Weather Channel has gone through over the last year and I think many of you will relate. So weather.com is a top 20 site here in the US delivering billions of forecasts around the world across many, many platforms. And Weather's really focused on innovation and new technologies and became really interested in seeing how they could build a much better mobile experience. So their journey started about 18 months ago where they had to diligently roadmap what they need to do and knowing that it will take time. They're a major site operating in almost 200 locales. And so they had to prioritize, I think most of you are figuring out how to prioritize transition HTTPS right now or if have not already done it and we have a great session later talking about HTTP too as well. And so it wasn't easy with ads and analytics but notice it was starting to get easier as more third parties were prioritizing HTTPS as well. And then in April, they actually rolled out web push notifications across 30 languages. What's significant here, and it's actually now 62 languages because they've continued to expand, what's significant here is in the first three months of rolling out web push notifications, weather saw a million opt-ins. So they provided the same set of notifications as their app users for the web but now they're reaching a whole new audience with web push notifications. And then more recently, they started looking at integrating service workers and transitioning more of their sites over to progressive web app. Given the US site was more complex and with more legacy, they decided to tackle their international sites first and have now rolled out progressive web apps in 178 countries seeing growing traffic in China, India and Mexico. And the weather team is constantly trying to improve their overall experience. And they've been happy enough with working with these technologies and seeing some gains here that they are planning to expand to a progressive web app for their flagship US site in 2017. And I think I really want to tell the story because I think we hear a lot about, well, I can't do it in the next three months. We can't figure out how to prioritize. But I think given some of you who will have legacy sites, like you need to take a step back and kind of roadmap out how long it's gonna take and what it's going to mean. It's not something that's gonna be done overnight. Think about it as a journey. And so I wanted to kind of make me walk through kind of the approaches to building progressive web apps. And I've offered up a diverse set of sites and how they started building PWAs. And so we started just noticing patterns in how people are approaching it, right? So some folks are lucky enough to just build new from the ground up and transition their experience almost immediately. Some people will want to ship a beta to kind of test and experiment, rolling out to a small percentage of traffic with the intent of transitioning their main site over, over time. And then some people are able to actually build on their existing experience. So integrating APIs indirectly. And so housing and CNET are actually two examples of where they were able to build new experience from the ground up. And I think that was the right approach for them. Housing for the whole site, CNET for a subsection of their site. And for the beta, as I talked about with the demo with West Elm, they couldn't transition a site right away. It was gonna be, and it was tough to describe what this experience could be like. So even before they got to a beta, they actually built a demo and then they showed it to their senior leadership. And so now they are gonna move to a beta, early beta by the end of the year and then a public beta next year, which is a great path. And then they'll start to kind of move their site over, over time. And Lyft again is an early preview this week and they'll continue to iterate and bring more and more features to their PWA. And as far as existing sites, I already talked about the Weather Channel, but Make My Trip actually started first with their hotel section of their site. And then they expanded to flights and now they're going to continue to add other sections to bring into kind of the progressive web app fold. And so there's no right way or wrong way to build a progressive web app. I just wanted to offer kind of a framework as you're kind of going back to your teams and saying, okay, section, whole site, new beta existing, just so you can get the conversation started in terms of how to start building. And so looking ahead, there's gonna be tons of great sessions today. I wanna kind of talk about how progressive web apps really is, we talked a lot about kind of engagement, conversion, we don't need to know like all the marketing terms at the bottom, but kind of think about progressive web apps as kind of this term for just improving your mobile web experience. And then accelerate mobile pages. This is also great if you're having a lot of traffic coming in from search and other platforms, it's a great way to get users quickly to your site from the top of the funnel. And we're gonna have an AMP and PWA session tomorrow morning where we'll talk about AMP installing a service worker to transition to a progressive web app as well as how AMP is being used inside of a progressive web app. We get a lot of questions about that. And if for some of you push notifications, it's like the one thing that you can do over the next few months, that's perfectly fine. You're able to re-engage users so quickly like what Carnival did and what Darren went through. And then two things I did wanna highlight which are actually after my talk this morning, conversion is such a pain point. Typing is so painful on the mobile web and we've done ourselves a disservice by not trying to do more here, but we are now. And so seamless sign in and one tap checkout are gonna be great sessions where you can basically just understand your get users into your experience, build an engaging experience and then make sure they actually convert and close on them. So it's really about radically improving the overall web experience. So over the last year, we've heard from so many of you the excitement for building and innovating on the web. And again, this really is a journey and it requires constant iteration, probably patience as you're trying to figure out how you're gonna construct your back end to like fit in with like the progressive web app architecture. But it's worth it and I hope you see that today by just seeing the enormous momentum and what people are seeing in terms of success with their various business metrics. And so speaking of iteration, I talked in the beginning of building a fridge for my son that didn't really stick. So I did try again. So this is actually a hotel room key because I was traveling a few months ago and he was really upset that he couldn't be in the hotel room with me. And so I built, I took a shoebox and then I put a little hotel, the slit and then he was able to, I bought my hotel key and now he uses it every single day. He literally closes his door, puts in the key card, beeps and then lets himself into his hotel room. And so he does it every night.  And so with that, I think that's your inspiration for building great web experience that people will want to use every single day. Thank you. Right, yes. As you can imagine, our calm demeanor has been slightly less calm backstage. But we think we might know we're starting to get a handle on it. Yeah, we've learned a lot. So we know there's some people still having login problems but we're gonna keep trying. We're gonna give it another go. We are. So if we can get the screen back up for the quiz, imagine that, okay. Now, we're gonna run a test question if you like. It's not scored just so that you can get a feel for how it actually plays out. And if you have, you know, login problems, just keep trying. They are filtering through slowly, which I guess kind of leads on to our first question of the day. Indeed. Rate limits. What is Google sign-ins rate limits for logins per second? Is it 300, 800, 200, or 20? So you should be, you should have the question on your phones now. You should be able to pick an answer. And then- Don't forget to submit. Don't forget to submit. You can submit as many times as you like. Jake, why don't we take a look at how the audience is voting. So this here is the live output of how you're all voting. Now we have randomized the position of all of these dials. Absolutely. But it looks like one is actually in the lead. It's slightly 30 odd percent there. The others are doing pretty well at 20 odd percent. So keep getting your answers in and we are going to close the question shortly. Should we say, this is tense, isn't it? Great agency did the music for us and we asked them like- Make it ridiculous. Yeah, we want music so tense that people will feel that if they're in the bottom 50%, they might be executed for it. Let's close the question. Interesting. Okay. So the most popular answer was 20. But what is the correct answer as far as we can tell? We can tell. It is indeed- It's 20. 20. Oh, we've hit some kind of lever that makes it, that's for some reason. Why do we even have that lever? Oh, out of everything, I really thought it would be my code that made this fail, but it turns out to be someone else's. Oh well. Oh, okay. So we'll be back throughout the day with some questions that actually do have scores attached to them, because that one didn't, so don't worry too much about it. But in the meantime, we're going to go into a break. We are, but before we do so, we are just overwhelmed with how many folks have come today. Overwhelmed with login requests, obviously. We are. We also, yes. So thank you so much for all of you that have come here today. If you are standing at this point in time, we also have opened up the Google Developers Launchpad nearby, and there's going to be food, there's seating, and you're going to be able to watch the conference from there. And we would love it if you're standing, you go find the help desk out in the lobby area, and there's transportation to take you across there so that you can be a lot more comfortable. And as Jake said, for everybody else as well, there is the break now, and we will be back. That's 11.45. Thank you very much. We have some catch-up work to do. Can we get the big web screen up, please? Excellent. Here we go. So if everyone gets ready on their phones, hopefully the Wi-Fi is going to stay up. Don't worry about that. Should we launch straight into? Straight into question number one. This is scored. This matters. Wi-Fi just flipped. Don't do this to me. You got it? Come on. Let's give it another go. Load states. When loading a page, which of the following happens first? The window load event, document.readystate equals equals interactive, or document.contentloaded event. Get your answers in. Should we have a look at some of the live results coming in? It's thrilling. This is a tense moment. No, I mean, it's 40%. I mean, that's a divided audience to my mind. That is true. So it's time between the window load event and DOM content loaded. Well, the correct answer is document.readystate interactive. I know, right? Some people feeling good. Some people feeling less good. So the actual order of things is that it gets to the end of the document. The parsing happens. Document.readystate.change happens. It equals interactive. And then it will execute any scripts which are deferred. And then after that, you get DOM content loaded, and then the rest of everything loads. That is some piece of tearing knowledge you have there. Yes, it is. Should we do another question, then? Let's walk it through them. OK, the next question. Recognize values for the type attributes of the input element. Date type. Now, this is a different question. This is a multi-select. So you can select the ones that apply. And don't forget to submit your answers. And if you've already submitted, you can keep submitting. You can change your mind. Should we have a look at some of the live talks? Let's go. We're very sure about one of them. That's pretty solid. One of them people are pretty convinced is not. Is not. I want to know which one that is. Just a reminder, these dials are randomized, so they do not. Something I should know. So text. People think text is a valid one. That makes sense. You know what? I'm pleased to see that 72% of people went for date time. Yes. The reason being. The reason being. It's not. Date is the correct input type. Date time is not. And obviously, it's a select element. Not a select type. Awkward. Right. And let's do one more. And this might be my favorite question. Yes. Jealous you get to read this one. Are you ready? Are you ready? Which of the following are valid color names? CSS, pale golden rod, papaya whip, light golden rods yellow, blanched almond, scorched meadow, burly wood. And once again, it's select all that apply and then hit submit. Let's go and have a look at some of the results here, shall we? Oh, look, what a divided audience. I'll be honest with you, there are some people who don't color code their UI by these names. I'm going to see what people have picked for this one. Announcing every one of those names as much as you're enjoying selecting them. OK, we're going to close the question. Three, two, one. Close it. Interesting. Right, so let's see what we've got here. So scorched meadow, people don't think that's a real color. Burly wood, strong showing from burly wood. And not entirely convinced about papaya whip. Is pale golden rod actually pale golden rod as a color there? It looks very close. I'm giving the game away. Right, here are the correct answers. Yes. Pretty good. Only scorched meadow, which I thought was a very beautiful name. And I think it should be submitted as a possible option. Yes, pale golden rod is one of my favorite CSS colors. I mean, why not? Burly wood.  I don't know, but I'm going to put it in and see what happens. Well, shall we get on with the show? Yes, it's been emotional. I'm sure we can all agree. And for that, we shall now turn to our next speakers, which is we're going to be opening with Sabine Borsay, who's going to come and have a talk. Big hand for Sabine Borsay. I'm Sabine Borsay. I'm a product manager on the Chrome team working on authentication. As you heard earlier today in Darren's keynote, the purpose of Progressive Web Apps is to improve user flows, to reduce friction, and to create really engaging experiences. And we've already given you tools to solve issues around reliability, or to create app-like experiences by adding PWS to the home screen. And now, we want to focus on two missing flows, sign-in and payments. AG and I are going to start off and spend the next half hour by talking to you about how Chrome is helping to remove friction from your sign-in flows by making signing in easier in a simple and secure way. But the first step, of course, is getting users signed up. And we all know entering all your information in long registration forms can be super frustrating. Like, this is how it looks like each time when I enter my credentials on my phone. And the stats also confirm this. About half of users would rather abandon a service than go through another registration form.  And let Chrome help you do this. Chrome offers autofill functionality that makes it easier for users to fill out these forms faster and easier. But sometimes things are ambiguous, like here. It's unclear which of these fields represents the user name, the identifier. Is it the user name or is it the email address? It's unclear to the user. It's unclear to the browser for sure. But the best thing to do with ambiguity is to be explicit. And an easy way to be explicit here is just to mark up your forms with autocomplete attributes. And then you can make sure that your forms were perfectly with password autofill. And I promise you, it will only take you a few minutes. So now that we got your users signed up, the question is how to keep them signed in. Maybe like this? Probably not, because there are all these buttons on the top. You have to remember which of them you used last time or if you used the username and password. And then you have to remember which password you used. As you'll see, a lot of things to remember. And let me now ask you a quick question here. How many people in this room have run into the experience that they create an account for a site and, bam, get this message that the account already exists? Yeah, quite a few. So as you can see, it's full of friction. And there are so many drop-off points along the way. And also, the stats again show this here. According to a study, 92% of users would rather leave a site than reset their login information if they forgot their passwords. That's 92% of people leaving. Just think about that. And how much is a signed-in user worth to your business? So again, really huge opportunity to get all those users that are abandoning your sign-in screens today to be signed in and become really engaged users if we just made things a bit easier. For instance, like this. So when a user returns to your site, it would be dramatically better if they could just skip this sign-in form and go straight to an engaging personalized experience. And that means knowing who they are. But the question is, why is that so hard? It's because sign-in flows today are limited in ways that the browser is not. So leveraging the position of the browser here is really the key. Because if a user is seemingly new to you, they are not new to the browser. And that's what we are focused on, making signing in easier in a secure way through the browser. And we do that with an API that we are talking about today, the Credential Management API. But before we dive right into that, let's assume for a moment that you have a really dedicated user. And they've found their way through all these possibilities and successfully signed into your site. So are we done now? No, not quite yet. Because users typically don't stay signed in forever, unlike on native apps. So there is a unique challenge that we are facing here on the web, which are the different attack surfaces and threat models. Just think about cross-site scripting, CSRF, or click checking. So session management on the web is really hard. And as a result of that, there are very different requirements for session management on the web and on native. And one interesting thing we can do with service workers is using two tokens, a short-lived and a long-lived token, where we use the service worker to refresh the short-lived token. And if you're interested in learning more about this idea, then just check out that blog post that's linked from here. So as you can see, there are some avenues like this to explore for the long term. But an easy way to handle this is using the credential management API. It basically moves users from a state in which they are frequently, automatically signed out into a state which they can be automatically signed back in. Sounds good. It's a web platform API, standard-based. And it allows the browser to facilitate the sign-in process with information it has stored from the user. And it does that in a frictionless fashion and also works across devices. We shipped this API earlier this year in Chrome 51 and we announced it at Google I.O. And since launch, we have seen a bunch of developers shipping it, like you can see here. And we want to start off now by looking at two common problems that we are trying to solve with this API. So on some sites, like e-commerce, travel, or news sites, sign-in is often not required. It's really helpful, but it's not necessary. So on those sites, the credential management API can automatically sign the user in right on the home page. And that's basically what you see here, indicated with that small blue button on the bottom of the screen, the toast, and the user is being auto-signed in here right on the home page. And as mentioned earlier, we know that on the web, sessions often expire very frequently, sometimes within a day, sometimes even within an hour, 10 minutes. So that means on those sites, basically every time a user returns to the site, they are in a signed-out state. And then it requires quite some dedication from the user to find a user menu, click through a sign-in button, and then be signed back in. We know that most services can provide usually better experiences to users if they are signed in, but that's not always immediately clear to the user. So they might not see the value proposition of signing in right away. Therefore, it's dramatically better if you can just automatically sign them in right on your home page, like I mentioned, by basically on any leaf page that the user might land on through a search. And AliExpress, for example, in e-commerce site, they have seen an 11% increase in conversion rates. That means users who actually made a transaction. And that's for users who signed in through the API in comparison with users who didn't sign in through the API. And they have also seen some really, really good UX improvements, like an 85% drop in sign-in failure rate on the web, or a 60% decrease in time spent signing in. Now, the Guardian has seen a 44% increase in users signed in on two or more devices across Chrome and their Android native app. And another common problem that we are trying to solve with this API is that password managers today are not really equipped to remember your federated sign-ins. That means when you sign in with Facebook or with Google. And that means those users often create duplicate accounts, as you know, because they just forgot that they already had an account. And the Credential Management API can also help here, because it can remember for the user that they signed in with such a federated account. Pinterest is a website that offers federated sign-in options too. And they have seen a 10% increase in desktop web logins for eligible users after they ship the Credential Management API. And they have also seen a 3% increase in user engagement. Now, even if users switch between devices, which is pretty common today, and let's say they download the native app for your service, they can seamlessly continue that signed-in experience. They need to just be signed in with the same Google account. And we call this password sync feature in Chrome, Smart Lock for Passwords. And if you want to enable this cross-platform experience for your users, you can do the mapping between your website and your native app. And then you can also use the Smart Lock for Passwords APIs for your Android native app. And with that, let me hand over to Agie, who is now going to show you the Credential Management API in practice. Thanks, Savin. My name is Agie. What I'm going to show you now is a Credential Management API in a demo with a website called Polymer Shop, which we introduced at Google IO this year. Let me get it. So this is the Polymer Shop website. Imagine that I have just finished shopping experience through a guest checkout experience. And I'm about to create an account. So first thing I should do is to enter my email address. So tap on it. And now I see my email address pop up. The nice thing about using this browser is auto-complete feature suggests me to use one of my email address that I have put into this browser in the past. So I can just tap to enter my email address and enter a random password and sign up. And now you see a pop up at the bottom of the page, asking me if I want to store the credential information. It's nice. So I can just save. So now my browser remembers my ID and password for me. So what I'm going to show you now is an auto-sign in action. But in order to make this demo exciting, what I'm going to do is to swap this device with a new one. Let's see what happens. So as soon as I tap on this icon, I'll be auto-sign in to the same website. OK? One, two, three. Boom, I'm signed in. So what happened here is that the credential information I have stored to the browser to the other device was synchronized across my Google account and propagated to this device. And as soon as I landed on the same website, the credential management API picked up the credential information. And let me authenticate and let me sign in. But sometimes you might want to keep signed out. In that case, you can simply sign out. That way, you won't be signed out for the future. So this is truly a frictionless sign-in experience. But if I talk about frictionless sign-in experience, you might imagine about affiliated logins. Affiliated logins are, as Sabin mentioned, like Google Sign-In or Facebook Logging or some other options. We have Microsoft, Yahoo, Twitter, GitHub, et cetera. Luckily, we have a Google Sign-In option right here. So let me try sign-in. So I sign in with a single tap. What is new here is that if you look at the bottom of the page, I see a similar pop-up show up. So I can store my identity information to the browser, like Sabin mentioned. So I can store federated logging information to the browser. So far, I have two accounts stored to this browser. Then what happens if I try to sign in? Let me sign up again and try to sign in by pressing the button. And now, what you see is a dialogue asking me to sign in with one or two accounts. So I can simply tap one of them to get signed in. So you might notice that I didn't type a single letter using a software keyboard. This is really frictionless sign-in experience. So let's get back to the slide. So the benefit of Credential Management API, let me recap. The first thing is it enables sign-in future across devices. And it also virtually enables a permanent session. And it remembers federated accounts for me. And I could use account chooser to skip forms without typing a single letter using software keyboard. So I should say, Credential Management API eliminated a whole bunch of frictions from the sign-in experience. So how can you, as a developer, bring the similar experience to your own website? So I'm going to dive into that. The first thing you should do is to save Credential Information to the browser. The form, such as sign up, sign in, or change password, is a great chance for users to store their Credential Information to the browser. So there are a few steps. First, interrupt the form submission. Then send a request to the server using Ajax. Then store the Credential Information and finally update the UI using a profile. Before moving forward, just make sure that your form is annotated well using the auto-complete attribute that Sabin mentioned earlier. With that, when the user submits a form, prevent default, interrupt it, and prevent default, and prevent it to proceed to the next page, why is that? If the page transition happens, this will move to the next page, which means that Credential Information user has put into the previous page will be lost in the next page. By making the authentication call using Ajax, you can retain the Credential Information in the same page while verifying the authentication credential. Make sure to create an API on the server side which responds with HTTP code with 200 or 401 so that it can respond correctly to tell the browser that authentication was successful or not. Responding with a profile information would be ideal. So after the authentication, you can store the credential now. Before doing so, make sure that API is available. Always keep in mind about the progressive enhancement. To store the Credential Information, instantiate password credentials object with the form element that you have created as an argument. Then call navigator.credentials.store. If the API is not available, you can just skip this step and forward the profile information to the next step. Once everything goes well, you can update the UI or proceed to the personalized page, and you are done. Then in cases where your website has federated logins, here's what you should do. So federated logins are, as Sabin mentioned, a concept of signing into a website using a third party identity, such as Google, Facebook, Microsoft, et cetera. So federated logins are based on a standard protocol, such as OpenID Connect or OVOS. There are two benefits of using it. One is that users doesn't have to remember extra password to sign into your website. And second is that, in general, users can sign into your website just by one tap. There are a few steps. First, authenticate the user with the identity provider, then store the Credential Information, and update the UI. So obviously, by tapping on the button, kickstart the authentication flow. So in order to authenticate the user using identity provider, you should use libraries provided by many different identity providers. For Google, we provide Google signing, Facebook, provide Facebook logging. Let me skip this step because it's quite complex, and just assume that you get authenticated and got the profile information. So once the user is authenticated, create an instantiate object called Federated Credential. But in this case, you're not storing ID and password. Instead, you're storing identity of the user signed into the identity provider, and also a string that represents the identity provider itself. Name and icon URL are option. Then call navierra.credentials.store. The rest of the steps are similar to what I have mentioned in previous section, so let me skip that. And the most exciting part of using Credential Management API is auto-signing. Auto-signing can happen anywhere on your website as long as you think it is appropriate. For example, top page is, of course, a good place to use auto-signing. But some leaf pages, such as news articles or item pages in the e-commerce website, is also a good place to enable auto-signings. To do so, first you get a credential information, then authenticate the user, and finally, update the UI. Before getting a credential, make sure that the user is not already signed in. Otherwise, it doesn't make much sense, right? So in order to get a credential, call navierra.credentials.get. By giving it a password and federated as option, as parameters, you can get specified the type of the credential information you want to get. And by giving it a metadata true, this will tell the browser that this is an auto-signing call. So it won't show any UI for asking user to choose from. And it will return undefined if the user has no credential information, or there are multiple credentials stored, or the user is signed out. After the function is resolved, you will receive a credential object. But if that is undefined, which means that auto-signing didn't happen, so you can just dismiss the whole process and pretend like nothing happened. And if you did get a credential object, just examine the type and run the authentication flow depending on the type of the credential. So the authentication flow is similar with what I have described in previous sections. And finally, you can update the UI using a profile. One tip I should note here is that if you did get a credential but failed to authenticate, that is going to be a little bit trouble because the user sees the blue bar popping up saying that the user is signing in. But if failed, if there are no sign of the failure, user will be confused. So you should show an error message in this case. And when the user is signed out, you should disable auto-signing. To do so, sign out user first, then call navigator.credentials.requireUserMediation. This will turn off auto-signing feature. And finally, when the user is trying to sign in, you can show account chooser so that user can select one of the accounts to sign in with. This will also turn on auto-signing feature back on. There are a few steps, again. So first, show the account chooser. And once the user selects one of the accounts, you will receive a credential information. Then you can authenticate the user and update the UI finally. So most of the cases, this is quite similar to what I have described for auto-signing. So by user's explicit action, such as typing on a sign-in button, we'll show and let the account chooser to show up by calling navigator.credentials.get. But at this time, with immediate false, this will show an account chooser when the user has multiple accounts stored or user is signed out. The rest of the steps are quite similar to auto-signing, like I said. But except one thing, if the user didn't choose any of the accounts or dismissed account chooser, that means that there is no account that the user intended to sign in with, which means that user wants to sign in with other account. So you should show sign-in form so that user can enter the other credential information and let the user sign in and store another credential. OK, so I described a lot of complex stuff, but we have documents of this. So you can just follow g.co-credential-management-api to learn more about this API. And we are working on a more in-detail document, so hopefully it can be published today or tomorrow. I will tweet about it using the hashtag, so please watch out. With that, let me hand it back to Sabin. Thanks, Eiji. So we talked about session management and how to remove friction in your sign-in flows by using the credential management API that we shipped earlier this year. But there is one thing we haven't talked about yet today, and we'd love to hear your feedback on that. And that's the account verification step during sign-up. You know, when you sign up for an account, you typically have to verify that account by digging up an email, clicking on a verification link, or by copy-pasting an OTP, a one-time password from an SMS, back into the site. And what we've often heard from developers is that about 20% to 30% of their users drop off at this stage step, just because it's another thing that adds friction. And Android offers APIs to help with this for native apps. And those apps that are using these APIs have seen... Oh, I forgot to continue with the slides. Those have seen higher conversion rates. So we are now exploring whether we can bring something similar to Chrome and the web. And again, we'd love to hear your feedback on this problem in general. Either via the feedback form you can see here, or just come and see us in person. Agi and I will be around, looking forward to meeting you. Thanks. Thank you. Thank you, Agi and Sabine. Hearing more about login APIs really hurt there. It sent me into a blind panic again. Perfect. Now, a reminder from earlier, if you are standing up, please do make yourselves known at the desk at the front. And we will help you get across to the Google Developers Launchpad. Apparently, if you go, there's also a gift card in it for you as well, which I was like... I was like, Jake, you're all right to do MCing for the rest of the day. It's odd, isn't it? Like, I think most conferences, you pay to come here, whereas we're paying people to leave. That's not normally how it works. That is normally how it works, and yet, here we are. Shall we get on with the next talk? We absolutely should. Right, here to talk about the world of web payments. A man some people call, Zack Cooke. It's Zack Cooke. There he is. Everyone, I like to make dramatic entrances. I'm Zack. I'm a product manager on the Chrome team. And I spend most of my days thinking about how we can make payments on the web, particularly on the mobile web, easier, less painful, and all-round better experiences for our users. So I'm really excited by the Critical Management API, especially for someone who talks to e-commerce people all day long and people who sell high engagement and easy sign-in is really critical, and it's really great. But if you think registration forms are difficult, we should talk about checkout forms. A lot more form fields, a lot more questions. But I think that you're going to see a consistent theme emerging through our talks here today, which is this one of let the browser help you. There are certain advantages that we have as a browser, especially when it comes to reducing friction and making life easier for users, especially things around repetitive data sets, things that the users can store inside of the browsers. What we're trying to do are expose APIs and give you tools to reduce friction and make things easier for your users. We saw it in credential management, and we'll see a very similar theme with what we're doing in payments. But first, a little user activity just before we go off for lunch, which are some questions. OK, great. So first question, just curious, how many people here actually enjoy the process of buying something on the web using their mobile device? OK, good. Some people, but by large, no. And by the way, we should come talk. I'd love to hear, like, what is that you like about buying things on the mobile web, and what it is that you don't as much. Second question, and I'm going to be really impressed here, how many people can remember all the details of their credit card? I'm talking full 16-digit number. Really, CVC unexpiration? OK, that's more than I expected. I've got to be honest. Like, OK, we're still under 15%, but OK. Because I've been doing payments now for like 18 months, and I think I have yet to remember a credit card number. That's great. And then, OK, final question, how many people enjoy the process of handing over all of their sensitive credit card information to a random third party server? Yeah, I knew it. I got one. It's almost like I'm asking these questions to lead up to a particular point. And there is a point. And the reality is that most users find payment difficult. They find it insecure and scary and frightening. And they find the process of doing it on the mobile web, particularly bad. And so we have this number. We talked about it at I.O. as well. And it hasn't really changed, which is that, on average, we tend to see about 66% fewer conversions on mobile than on desktop. And again, we think there's an answer to that, which is all around, again, high friction, the difficulty, and issues around trustworthiness and security. And so we'll talk about how we're addressing those today and how we're trying to bring fast, simple, and secure payments to the web platform. But I'm a PM, but this is a little bit too PME for me, actually. And so I have a much better mission for us inside of the Chrome team, which is we're trying to save the world from annoying checkout forms. So I'm trying to save the world from virtual keyboards and having to memorize and all of those terrible things. I actually started this joke, the Better Payments Bureau, a couple of months ago. And now it's become like a thing. So anyway, but actually, Chrome has been fighting the good fight against annoying checkout forms for many years, actually. We started with Autofill back in the day. You guys are probably familiar with Autofill. This is my one slide on it. It's not really the topic today. But consider this my 10-second plea to say, if nothing else, leave today and set autocomplete types on your checkout forms. It helps us. It helps the users. It helps the browsers. And it basically ensures 100% accuracy on Autofill. But I'm not here to talk about that today. I'm really here to talk today about payment requests, which is this new API that we're building for the web to really help solve a lot of the problems I've been talking about. But before I talk about what payment request is, I want to talk about what payment request isn't. And that's because payment is complicated. There are a lot of players in this space. And I just want to sort of set up fronts and sort of help alleviate any confusion. So the first thing, payment request is not a new payment method. So we're not trying to create Chrome Pay or browser pay or yet another xPay button on your website. That's not fundamental to our goal. Our goal is to help users pay the way that they want to pay and do it quickly and efficiently. Secondly, we are not trying to become a gateway or a processor or some entity that literally moves money in the ecosystem. So we're not trying to step on any toes here or enter into this ecosystem. We think that the market has actually done an incredible job here already. Players like Stripe and Braintree and others have done a really stellar job over the last couple of years of taking the incredible complexity of accepting online payments and making it really simple. They've removed the burden of things like acquiring banks and even some levels of PCI. And they put it all into an easy to use API. And so our goal is to ensure that whatever we do plays really nicely with all these gateways and processors. But that's not fundamental to our goal to become one. The thing about all these great new services, though, is that they've really focused on developers, which is great. They've made your lives easier. And they made it easier for you to accept payments. But the user experience has largely remained the same. You have to go from the state where nothing to a user to everything. And form fields tend to be the way that we do this. So payment request was fundamentally built for users. I mean, we think it's pretty good for developers, too. And it's pretty easy. And we'll talk about code samples. But fundamentally, like my goal, I think about users and how I can help them and help them get through these burdensome flows on mobile faster and more efficiently. So what exactly is payment request? Well, payment request, like I said, is a new standards-based API. And standards-based, I want to emphasize that. We joined the web payments working group almost a couple of years ago now. And every major browser is a vendor. We have financial institutions from around the globe. And we're trying really hard to build something that everyone can integrate, that all forms of payment can integrate with, and all browsers can do, so that users on a variety of devices and ecosystems can continue to leverage and have the benefit of it. We're just in the early stages of it. And we'll talk about where we're at. But that's sort of fundamentally our goal. And so when we started to think about what design this API looked like, we had two high-level goals in mind. And they sort of referenced back to my original question set. The first one is we wanted to build a seamless, easy-to-use checkout experience on mobile in particular. We wanted to make sure that users could minimize typing and minimize friction as much as possible. And the second thing is we really want to bring more secure payments into the web platform. In many ways, the web is one of the last places where it's very commonplace to exchange over all of your sensitive information to some unknown third party. And even though there's an answer to this from the payments community with regard to tokenization, the web really didn't have a great answer for that, which is why we're really excited that we've brought Android Pay into the web platform. And again, we'll continue to expand that. But this brings tokenized forms of payment. So in the event of data breach or other problems, users are protected. But also it also reduces the burden for you as developers and merchants. And so those are our two high-level goals that we had. And again, the idea here just at a high level is that if you think of your traditional checkout flow, it looks something like this. It's anywhere from like two to five pages, maybe one for single page things. And you have somewhere between 10 and 40 form fields where you're asking a variety of questions, things like, what's your name, what's your shipping address, what's your email, what's your phone number, what's your credit card number, what's your expiration. And then you have users who are trying to do all this on their mobile device. And at some point, they're like, meh. And they kind of give up. Maybe they go to desktop later, or most likely they don't. And Darren talked a lot about the growth of mobile. And so we really think we need to fix this and make this easier. And the way this happens with payment requests is you can imagine that the browser sort of plays this role and helps facilitate checkout across the highest fiction point. So we take that common set of data, those common things that you request, and sort of leverage our strengths to make it easier for users to be successful. So before I show you a demo, I want to talk about what types of data is actually supported by payment requests. So the first one's probably a little bit obvious, but it's a form of payment. So at the end of the day, you need a way to actually request money from the ecosystem. So you need some sort of form of payment. Right now in Chrome, we support two. We support credit cards and Android Pay. I put Etc. on here because the plan is to support more, but we'll talk about that a bit more later. And so you always have to request a form of payment. You can't call payment requests and not want a form of payment. That would just be weird. And they would just be request arbitrary user data API. So the other big thing that we allow you to request is shipping address and shipping options. So for physical good purchases, you can leverage the API to say, hey, give me their shipping address. And then there's a dynamic mechanism for you to take that address and then populate shipping options that have updated pricing, et cetera. You can also request a phone number. You can request an email address, of course, for sending a receipt or even prompting sign up afterwards. And coming soon, actually, but not quite there, but in the next couple of months is pay or name support. And these are all flexible. You can request any of these or none of these if you want. The idea is to support a broad range of use cases out there.  Or if you're a physical good, you may or may not need their payer name because you'll get that from the shipping address. So it's flexible, and you can sort of accommodate experiences as fits your business. But the really important point here is that all of these data points can be stored and returned by the browser. So users, by and large, trust Chrome to store this data. They trust us to store their names, their emails, and even their credit card data. And so the question is, why put users through the burden of a form that they have to fill out manually? And you saw Sabine slide about fat fingering and the difficulty of mobile keyboard typing. And those problems are multiplied across all those form fields. So if you can save them the burden of doing that, we think it's worthwhile. And payment request is really designed to do that. But let's go ahead and just go ahead and sort of see it in action. Switch over to a demo here. Let's see if we can see. All right, excellent. I'm going to open up Chrome on stable. And I'm actually going to use the exact same shop API that's oh, and you see it auto-signed man. You have to love when a good demo goes right. And but otherwise, it's the exact same website, Polymer shop demo, except I'm going to go a little bit further and actually just make a purchase. So I hit the Shop Now button. I definitely don't have enough Google hoodies. So I'll just switch shirts. I'll just buy yet another one. So standard shop, you see that there's like size and quantity. I won't affect those. But you see that there's two buttons at the bottom. There's a typical Add to Cart button. But there's also this Buy Now button. That Buy Now button is based on feature detection. So we're checking to see if payment request exists. And if it's there, great. Let's leverage it. And if not, you would just see an Add to Cart. But I'm going to end use the rapid checkout approach. And so I tap on the Buy Now button. And you see that this payment sheet slides up from the bottom. This is payment request in action. So you're looking at sort of natively drawn UI. It's controlled by us. We can throw it. But it's populated with data from the merchant. So you see that my total amount is there, $22.15. I default to my form of payment that I prefer, which is Android Pay, if it's available, only because it's faster and more secure. You see that they're also requesting my email address for the purpose of sending a receipt. And the only thing I need to do here is select a shipping address. It's very difficult to ship a sweatshirt to someone if you don't know where it goes. So I'll tap on that. You'll see that the payment sheet slides up to full screen. And it has my addresses automatically populated for use. These are our two Google offices here. So I'll go ahead and ship to the one in San Francisco where I work. And you see that when I do that, the shipping options are automatically populated there. And so we have a free shipping in California option or an express shipping. And if I change those, that'll dynamically change the price. So you can see here that express shipping changes. But of course, why would I pay more? I'm gonna go back to zero. That seems to make a whole lot more sense to me. And now I'm ready to pay. So I just have the pay button and then you'll see the Android Pay screen slide directly up. We're running the test app, so it says unrecognized. You guys wouldn't have that. And because I've actually authenticated in the last couple of minutes, I don't even have to do any extra authentication on Android Pay. I'll literally just tap the continue button. Our response comes back and the transaction in order is successful. So pay with Android Pay, no keyboard, no typing. All I had to do was tap and select and confirm my shipping addresses. So really great, really seamless. We're really excited about it. And just to show you that if you don't have Android Pay available, no big deal, we can always change our form of payment. And if I didn't have Android Pay, I would just default back to my credit card, in this case a Visa card that I have. Once again, I'll select my shipping address and options. I hit the pay. And the only thing, the only keyboard we can't get rid of is the CVC input. Everything else we have. So I'm gonna do one, two, three. I used to do like a live credit card on this and I discovered that didn't work well for me. So I've switched to a demo card. But either way, the same concept applies. We'll talk about what's happening behind the scenes, but this is all client side basically. So it's all happening super fast and pretty great. Anyway, we're really excited about that. And now maybe we can switch back to the slides and talk more about what it takes to make this actually happen. So how do you leverage payment requests? Well, it's pretty simple. There are three parts to payment requests, two of which are that are required and one of which is completely optional. And so we'll talk about them in order. The very first one are payment methods. So we need to know basically all the ways that you can get paid. This could be a wide variety of things in the future. So it could be I accept Visa and MasterCard and AMX and Discover, JCB, Union Pay. It could be in the future, I accept Alipay or Ideal or PayPal, et cetera, as long as people are built into the ecosystem. Like I said for now, Chrome, we just launched. So we're starting with credit card support and Android Pay. And so it looks a little bit like this. So we basically pass in this thing called method data. Method data is an array of objects. And those objects each have an array of supported payment methods. So you can see here that the first thing I support are credit cards. I support the standard for Visa, MasterCard, AMX and Discover. That's it, nothing else to do it, just as I accept this. In the future, coming out in a couple of months, we have added support for granularity for things like debit or credit or prepaid. But for right now, essentially when you say Visa, we sort of assume you can accept all Visa and don't make a strong differentiation there. But the second one is a little bit more interesting. And this is Android Pay. This is sort of an abbreviated version of this. But to support Android Pay, you see that there's an additional key inside of that object, which is the data. Data is sort of a generic object. And it's payment method specific. The reality is that different payment methods out there have different dependencies, different things that you're going to pass in when you instantiate it by default. So for Android Pay, for example, you always have to pass in your merchant ID. You have to pass in what kind of token you would like, either network or gateway. We don't have a full example here. And then what happens then is when a user chooses to pay with one of those forms of payment, we basically bundle it all up and pass it on to the payment app. And then the payment app uses that data, plus things like origin and assertions from Chrome to basically verify that the payment app is the right one, and so the payment can continue. So it's pretty simple. The idea here is that you throw everything you can at the browser for ways that you accept payment. So if you can accept 100 different ways of paying around the globe, tell us 100 different ways to pay. Because what the browser does is we find that spot in the middle between the set of ways you can get paid and a way that a user can pay you and give a user an optimized experience about the ones that make the most sense for them. So you saw, for example, in the demo that Android Pay and a Visa card were available. But let's say that we had removed Visa as an option, then Visa just wouldn't show up, because that doesn't make any sense.  But we recommend giving us all to them, and then we'll find the best experience for the user to optimize around their preferences, their defaults, and what is the best thing for them. The second bit of data is also quite important. So now that we know how I can pay you, we need to know how much money you want to get paid. And this is what this looks like. Great. So the first thing, the most important thing that's required is this total attribute. Three parts, basically, or two parts, really. The first one's a label. So we customize this. So if you tell us total, we'll display total. But this could be authorization, donation, whatever you want. And we have to know an amount. An amount is composed of a total amount of money and an underlying currency code. So we know, for example, the underlying payment app that we transferred to knows what currency to charge in. We also support display items. So just like I showed you, when I tapped on the total, those line items came down that basically told you how the total amount was reached, we also support this. It's fully optional. You can pass in if you want or ignore it. We recommend it. It's nice to give a high-level overview to a user about the things that inform the total amount, things like the subtotal, tax, shipping costs, et cetera, less of a full itemized receipt, again, and more of a high-level overview. One important point, payment request does not do math. We're not good at floating point math. So if you pass in, you have two line items that sum to five and your total says four, we're not going to throw anything. So you're totally in control of this thing. So just keep that in mind. And there, by the way, might be some use cases where it makes sense for those not to align. But by and large, I just want to point that out. The other point to note is that transaction details can also contain shipping options. And in this case, if you put them in there by default, we support default shipping options. We only recommend you use this if you're highly confident that your shipping options will not change, as in they're not dynamic. So if you support, for example, worldwide free shipping that never changes, no matter what the address is, feel free to default populate this. But if your shipping is dependent upon a user address, then we recommend waiting until you've gotten a user address event, which we can talk about a little bit. And then you can use that to dynamically query against whatever service you use to calculate prices. And you can repopulate this. And that's an important point that basically the transaction details object can actually be updated and overwritten throughout the lifecycle of payment requests at certain events and points. So if a user changes their shipping option, you saw how in my demo, when I changed my shipping option, the price change and the list items changed. That's because when that event took place, we repopulated those set of transaction details. And so you have that flexibility and control on those events. And so that's how we get that dynamic pricing model that exists out there. And so again, don't do default shipping options unless you're highly confident they aren't going to change. And the final piece is the extra information. The optional set of options. And that's that things I talked about. User address, shipping support, name, email, and phone. All entirely optional, but definitely useful. I think there is sort of this myth out there that the only drop-off point in the funnel is the process of putting in your credit card. But really, the entire checkout funnel is, well, a funnel. And so wherever your users experience friction and there's a step, there's a drop-off. So we highly recommend taking advantage of these different pieces. And so there's a few that we support, like I said.  Do I want shipping? Yes. Do I want email? Yes, et cetera. And you can, again, these can be variables. You can say, I don't want shipping, but I do want a name and phone number. Or you can say, I just want an email address to send a receipt to, for example. It's completely configurable. And again, the idea here is to support a wide variety of use cases. Something funny that is minor that we have coming soon in the next couple of months is we're adding support as well for a shipping type value. It's pretty simple, but the idea here is that let's say you are buying a pizza. One does not ship a pizza. It's just weird. Like, we deliver pizzas. And so it's a very minor feature that allows you to actually specify shipping, delivery, or pickup as the address type. So we still call it shipping address, underlining the system. But this way, in the UI, a user would see, oh, I want my pizza delivered to 345 Spear Street. I don't want it delivered. Or if you're a ride-sharing service, for example, you can say pickup, and it's your pickup address where you're currently at or located. And so that's the value of that particular little thing. Again, pretty minor, but allows us to just have a better user experience underlining the whole system. So now we just put it together, basically. And then we get that whole experience that we talked about, or I just showed you. So the first thing we do is we instantiate payment request. And we pass in our method data, things that we support. We pass in the transaction details. Again, how much money, what currency code, what line items do we want. And then our optional options. So in the case of our demo that I went through, that would be request shipping true and request email true. But again, that one's completely optional. You see here, I've also added an event listener to my shipping address change. And we support two events in the system, shipping address change and shipping option change. This is that dynamic mechanism that allows you to receive the events, parse out the new details. Let's say a user selects a shipping address that event fires. You can actually pull out that full shipping address. We don't do just the zip code because you can't get fully accurate shipping information with just a zip code. So you get a full user address. You can use that at that time to call event.updatewith. This basically says, hey, browser, I'm thinking. I need to calculate this. You can call your back-end APIs. And you can resolve a promise with new transaction details. So again, that updated transaction details object can now contain your updated set of shipping options, including the empty set of options and an error which says, oh, sorry, we don't ship to wherever it is that you're trying to ship to. So that's also supported. And by instantiating payment requests, there's no UI that shows. It's just instantiation. When you want that actual payment sheet to slide up from the bottom, we call .show. .show is actually our signal. And we actually raise that payment sheet and put the user through the process. That returns back a promise. And when that promise resolves, you have a payment response. And that payment response contains the entire set of data. It's just a JSON object that contains the entire set of data that you requested. So for a credit card, for example, you would know what the underlying network was. So Visa, MasterCard, et cetera. And then you would see credit card number, full number, full CVC, expiration, et cetera. Think like the same set of data that a user would have typed out into your form, you're now getting just from the browser as a JSON response. You can then use that to basically send that response directly off to your gateway, your server, or even, let's say, in the case of Striper APIs, directly over to the APIs for tokenization. It's completely up to you because it's all plain text. These responses, it's important to note, are method-specific. So if you selected Android Pay as your form of payment, then when that response comes back, it's going to look like an Android Pay response. You're going to be able to select this, there's a key, and they'll tell you that, oh, the form of payment they chose was Android Pay. And then you'll have to expect that the Android Pay details object looks different than a credit card one, which may look different than some other form of payment like an Alley Pay, et cetera. That's because different payment methods have different requirements and are different systems and call things different things. The final step here is we just need you to tell us to close the UI. Because once you get this payment response back, we actually chose a little loading spinner. And that little loading spinner is sort of waiting for you to come back and let us know the result of the transaction. We highly encourage, but do not require, that at the time that payment response comes back, you try to make the payment. There are legitimate use cases where you can't do this, things like 3D, 3DS flows, et cetera. But by and large, if you can submit, we recommend it. And so you call the complete. You can call it with success or failure. But you can also call it with nothing. This is basically an affordance for the browser to do special UI considerations in the events of success, like a little animated check mark or something. But again, it's totally optional. But the important thing is that when the UI closes, we'll actually resolve that promise. And that promise is your cue that the UI has been completely torn down. So if you have animations or things that you're trying to time with the close of that, wait for that promise to resolve. And then you can be guaranteed that any Chrome UI has now been stripped from the page. And that's it. Armed with that, you basically have the whole experience. So in just a few lines of code, you basically help user alleviate all that friction and difficulty of typing all those annoying form fields. Pretty simple. But also, again, with Android Pay and other future forms of tokenized payment, you're basically getting easy, great tokenized forms of payment that reduce the burden of CVC, memorization, et cetera. So really excited about this. And this is all possible because the browser is sort of sitting as the middleman there, proxying data back and forth between native apps on the device and the underlying website and the developer that's requesting it. So my last few minutes here, I want to talk about just a few UX considerations and forward-looking stuff. So first one is my very bold hyperbolic statement to say, kill the cart, which is maybe a bit strong, but it's sort of my way of saying, if a user is coming to your site, or if a lot of users who come to your site on mobile that only make a single purchase, why put them through the burden of opening the page, adding it to cart, finding the cart page, clicking the cart page, going to the review page, going to the checkout page, and then finally starting the process. They're on mobile. We want to optimize their experiences. Payment request allows you to do that quickly and immediately. So consider adding buy now buttons directly to your product pages, especially on mobile when it makes sense. Again, this moment won't make sense for all businesses, but I would encourage you to go back and check the numbers and see if this might be a powerful tool for you guys to leverage to help your users. Just a few other things really quickly that I've talked about, and you've heard mentioned here today, is think progressive enhancement. This is a new API. It won't always be available, so you can't necessarily completely depend on it, especially in a cross-browser way yet, although hopefully we'll get there. So think what happens if it's not available. You'll still need fallback flows, et cetera. Second one, of course, is we encourage you to keep the set of list items high level. So don't think of it like an itemized receipt. We don't want the user to say this long scrolling list in the UI if possible. Try to keep it high level, subtotal, tax, things like that. If it's a single item, you can put it in there, but by and large, we encourage high-level subtotals and