 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. It's such a cost-effective, low-friction way to get experiences in front of users, again, in front of real people. 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. Because 2G networks are a reality for many people in the world. 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. A lot of times, thanks to quite a lot of legacy, there's a lot of little dark corners and so on and challenges for you as you're thinking about targeting a bunch of different browsers. 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. He's been doing that every night for the last few months. 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 mean, you look at that and you think, what is 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. So we have a huge opportunity here to reduce friction in your sign-up flow and then really drive growth and conversions. 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. So if you're like a right pickup service, you probably don't need everything, but you definitely need, let's say, a location, like an address, and a name, let's say. 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. And so as you go around across the globe, there are a wide variety of ways to pay. 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. And it's as simple as passing in just a bunch of Booleans, basically. 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 things like that. And then last one, something to consider is that if you already have a user's information and you already have a credit card on file or some way to pay, I wouldn't expect you to use, don't think you have to use payment requests. Like, give the user the best experience they can, and that means go ahead and just leveraging what you already have on file. But if you don't have anything and you don't have the credit card or the credit card expired and you need a new one, consider payment requests as a tool to help these users. We talked about sign up first, right? But that might not always make sense for your business. If you think about it, maybe your P0, your most important thing, is getting a user through that checkout flow. Then you can request an email address from payment requests. And now all you need from them at the end of that funnel to optimize the experience for next time is a password. And so consider leveraging this. Again, these are tools to help you be successful. So just a quick status update. So we are live in Chrome as of M53. So we've only been live for about eight weeks now. And it's sort of a quiet launch. We had a great set of early launch partners that we worked very closely with. And they integrated and tested and gave us a lot of great feedback. Again, the API is still early. Chrome is the first browser to implement. And so we're really thankful to all of these players for their great feedback. And from it, we're actually making a lot of changes and improvements and enhancements to the underlying experience. And so I just want to talk a little bit about what you can expect to come soon. So the first one that we're working really hard on is support for third party payment apps. As you go around the world, there are a lot of ways to pay. In India, you have Paytm and Snapdeal and all these other new emerging wallets. If you go to Holland, you have Ideal. If you go into other countries, whole new forms of payment that are not just credit cards and Android pay. And we want to be able to support all of this in a nice open way where we can support users from all over the globe no matter what. And so we're really close to finalizing this. And we hope to have support next year. Secondly, we have a lot of spec and feature enhancements coming. So we have the shipping address types I talked about. You'll be able to call this within an iFrame coming up soon, as well as a bunch of other small enhancements and improvements. And then we also have a bunch of UX improvements. So we added OCR scanning just recently. So you can now just like scan if you don't have a credit card, you can just scan it directly into the UI. So there's things to make it faster, easier, and fundamentally better onboarding flows. And then just quick timelines here just so you're aware. We're sort of targeting M56. That's our January release. It's like our next big major release. It's going to have all these enhancements, all these improvements. And we're really excited about it. You'll continue to get updates along the way. This is all live in Chrome stable. And we'd love to continue to work with you and get your feedback. Everything I talked about today is available online in a lot more detail. We have integration guides, a bunch of examples in sample code. Ooh, the phone's come up. And then we also have a gain start with Android Pay. Android Pay is really simple with payment requests. It's like less than 10 lines. We do almost all the heavy lifting for you. So just a quick shout out there. But I'll be around for the rest of the day. I would love to chat with you, learn about your challenges, things that you think you need from the browser, ways that we can help you be successful, especially in checkout. So thank you so much. Talk more. I love that. That is so exciting. This is a game changer. Brilliant stuff. Now it is time for lunch. It is indeed. Now you've got options. You can either stay here, or if you go around the corner to the Grove and show your badge. You can't have this one. It's mine. But if you show yours, then you get a free lunch. So you've got choices there. And if you want to take the shuttle bus to the other location, the Google Developers Launchpad, you can do that. And there'll be lunch there as well. So you have tons of options. We will be back. Well, if you opted in for particular dietary restrictions like a special meal, that is going to be available downstairs in the corner behind the bar over there as well. We have pushed back this afternoon's session. So we're going to be back here at 2 o'clock for Paul Irish. And more big web quiz. Oh, yes. See you then. Take it out. The last session is the Leadership Panel, where we'll have all people sort of like new various VPs and product managers and engineering managers going to be up here answering your questions. If you want to get any of your questions in early, if you ask them in the Slack channel, which an URL is on your badges. So you can have a look at that. But should we do some big web quizzing? Yes. And I think before we get to it, we should have a look at the leaderboard. We need the screen up first. So that would be, ah, here we go. Let's have a look at the leaderboard. Let's see who's leading the pack. Here we go. OK. Uh-huh. Ooh. Ooh, we're tied in first. Look at that. Would you believe it? Oh, hey. Some people have a bit longer names than you catered for in the layout. Not everyone's called Paul. Yeah, well, they should be. All right. You can see I've poached there. It's a Mozilla DevRel beating any of Chrome DevRel. I really like Mohamed's avatar. That's really cool, because that's like a ho-ho. It's not like a Batman mask, but with even glasses on. Even better Batman. That's amazing. Right. Well, we want to see a, oh. We want to spread that out. I can see 15, 15, 14, and a bunch of 14s. We need to, let's have a question. We should also point out that there's someone, the first place is actually shared with another individual who's not opted into leaderboard, but they should feel very proud of themselves. They should. And don't forget, if you do want to be on the leaderboard, then you do need to check that box at the bottom that says, appear on leaderboard. So shall we do a question? Yes. Right. I think you want to read this one out. I am. Which of the following CSS properties triggers layout or reflow when changed? Backface visibility, outline, opacity, or background image. Select all that apply. Yes. Let's have a look at what chances are coming through. Oh, there's a lot of confidence in one of them there. Yes. 100% of people. That's interesting, isn't it? Look at that. One of them is just fluttering around the 20% mark, the pink one there. Very useful, which one that is. Invinced, apart from that one. Let's close the question in three, two. Confident on width. Not so confident. I'm pretty sure opacity doesn't in decision around outline. Yeah, does it? That's not surprising, is it? Because it's painty, but it doesn't actually change the size of the element itself. Let's have a look at the answers at some point. Here we go. Just width. Just width. Most of them will cause a paint or a re-raster, but it won't actually involve changing the dimensions of an element. Therefore, it doesn't trigger layout or reflow. I guess that's right. All of them will cause a re-raster. Outline during an animation won't. No, I said I meant opacity. I was going to say, I thought you knew something. It begins with an L as well. Yeah, it's fine. It's very confusing. Yes, width is the only one that triggers layout. Right. So this next question I would like to do is about the next speaker. It is, really. So it's not scored. Oh, yes. This is one that's just going to be for fun. Because we don't know how much we expect people to know this one. No. It's very interesting. And I think so. Here it is. It activates. Come on, Wi-Fi. You can do it. Don't film me now. Paul, can you? There we go. Of the many Pauls working on Chrome, which is actually Irish. Is it Paul Kinlan? Paul Lewis? Paul Backhouse? Or Paul Irish? Oh, hopefully us. Here we go. Oh, well, there's a pretty confident one of them. That is interesting. No one's really sure on this one. No, you're looking down that list going, really, they all might be one of my knobby. This is a select multiple one as well. So you are welcome to pick. Constructor Paul Egon. It's fine. Interesting. So what are you saying? Probably a low chance for the German Paul to also be Irish. OK. That seems relatively fair. Paul Kinlan, though, leading the charge there at 57%. Interesting. Shall we show them who it is? The correct answer is, of course. Yes, it's true. I actually am Irish, which means I have the great pleasure of being Irish Paul, introducing the non-Irish Paul Irish. And at this point, I have to confess, we've now had to start calling him Paul Lyrish. Ladies and gentlemen, give him a round of applause. Paul Lyrish. Like a little, not much, more than that. OK. We good? Yeah. So today, I want to talk about debugging the web. And really, this is about I want to share with you some of the work that we've been doing in the Chrome Developer Tools. We've been working hard on a lot of stuff. And I want to share with you today. And just to step back for a moment, I just want to point out that really our goal here with the Chrome DevTools is that we want to maximize your productivity as a developer. We want to make sure that you are as effective at developing experiences for the web as you want to be. And not just that. I think we all enjoy web development because we get to craft the experience that users consume. And we get to bring them joy. And we want, on the DevTools team, to make sure that you have that joy, too. So we want to maximize your delight as a developer. So I'm going to be sharing with you a few things today, some big features that I'm really excited about, also some smaller things that just are smaller, subtle changes, but all targeting your experience and your workflow as a developer. So we're going to go through a few things from debugging and authoring, progressive web apps, and then some auditing stuff. And we've got a lot to get through, so let's get right into it. Debugging. I'm talking about JavaScript debugging. And so JavaScript debugging is how we understand the execution flow of our code. And it's how we remove all the bugs that we added to our code by accident. So it's a really important thing. And we spent a lot of time doing it. So we want to make sure that it's good. Let's start out small. This is the call stack. It's the humble call stack. This is what it looked like about six months ago. And we spent so much time here that we want to make sure that it's as good as possible. So we've done a little bit of UI refresh here. On the right-hand side is new call stack. Some small changes, just a little bit more clean, not as much zebra striping. The asynchronous hops are a little bit more obvious. The where execution sits is very clear. And up at the top, of course, you'll see exactly why you're paused. And this is called out very clearly, because sometimes you're not really sure. Also, sometimes you just pause on a breakpoint. It's kind of clear. But other times, you're paused on an exception. So it tells you exactly what the exception message is right up there at the top so you don't have to go and figure out and open up the console. Or you're in a promise rejection. You're on an XHR breakpoint, a DOM breakpoint. Whatever the reason, we want to make sure it's very clear to you on why you're sitting there paused on execution. So some changes there. But also on the call stack are some other things. Now here, I have the DevTools fairly. Let me bring that back. It's good? It's great. The DevTools, in this case, are pretty big. It's not all the time that we have the DevTools maximized on the screen. And sometimes it's all over there, squished to the window, but we still want to be effective. So this is what the call stack looked like a while ago. As you kind of reduce the size of the call stack, everything gets shrinked down. My function names, I can't even read them anymore. So navigating between the call frames when I'm debugging is kind of rough. We decided we could make this a little bit better. So this is the experience now. So just as you have less screen real estate, we go in. We kind of stack the function name in the location. And when we run out of space, we just elide the location and take the text away from that. So making sure that whatever the screen orientation, and we're always changing it, it's going to be readable and usable for you. So again, these are small changes, but important. Now a lot of us are authoring not just in kind of plain old JavaScript, but we're using JavaScript Next, ES6, ES2016, whatever. And we might be using tools like Babel or TypeScript to transpile them down to code that can be deployed across a variety of runtimes. And I just want to point out that the DevTools works great with all these new language features. In fact, we use them ourselves. This is the DevTools inspecting the DevTools. I'm using the black DevTools to view the other one. And this is just some of our code and some of our layer profiler. We use a lot of these new language features ourselves in our JavaScript. In here is a bunch of stuff. There's promises and error functions, template literals, the new array methods, good stuff. And this allows us to make sure that the experience of working with these new language features, whether it's debugging or in the console, is great for everyone who uses them. So the console itself is actually a really nice thing. So if you're using Babel or something to transpile, you're like, what exactly is happening here? Just come on over to the console and try it out in place here. Works great with all the new features and constant Lent. Here in the screenshot, we can see using the async await. This stuff is great. You can toss in a little debugger statement right there and understand exactly how it's moving. This is a lot of fun. So while we're talking about the console, let's spend a little bit more time here and talk about the console read line. Now the console read line is, how did I do this? Yeah, I don't know. Okay, coming on over here. So opening it up, DevTools on my favorite site, example.com, it's a good one. The console read line is this thing here that we type on. And so usually we type things that are just like fairly, like just one liners, but not all the time. Sometimes you actually want to have a few more than just one line that you want to type out. And this has been kind of a pain before. You have to hold like shift enter to avoid. To write in new lines, it's been kind of tough. So I'm gonna write out just top of a function. And as I hit enter now, we just immediately say, oh, actually, I don't think you're done here. Now, some folks call this smart return. In fact, Safari kind of paved the way on this one. They had this feature and we really like it. It's fantastic. So now let me just finish the rest of this guy. I'm just gonna log out my args. I hit enter again. We still know that we're not done yet. I had a brace and it's like, oh yeah, I'll reinvent that for you back there. And I'll hit enter again. And it's like, yeah, you're done. We'll execute that, cool. So yeah, so as I had that too, you'll see that we are matching the braces too. So very clear brace matching. And in fact, this is now syntax highlighted, whereas that is pretty new. Even things like multiple cursors and select next match, all these features that you and these keyboard shortcuts that you use in sublime text or whatever, they also work here too. So some nice upgrades to the console read line. Now the other thing is that we use the console as a way to inspect objects and kind of understand what's going on with them. So actually having the completions as we type and explore things is really important. So on this site, let's see, document.head, and I'm just gonna look at child nodes real quick. So as I open up the square bracket, I do actually see immediately all the indices that I can use in child nodes. So I know that there's 11 child nodes and that's kind of cool. I'm gonna choose one. And one pain point that's happened in the console before is that any time that you have an array and you grab something from the array and then you hit dot, I might not see any, I can't, what is there? And I want those completions and it didn't work. Anyways, it works now. So we're all happy. So in addition to that, you kind of want a little bit more power and you've only been able to see what starts with what you typed. And so now if I wanna see what the content is of this child node, I might type content and then, oh, text content. Yeah, actually that's the text content. So substring completions work now too. In fact, the substring completions work not just here but also in elements panel. So in case you forget something like border color, you can type color and you'll eventually see where it is. All right, so some nice improvements there on the console. Again, small things, but nice. All right, sometimes you're writing some code and to be honest, like three lines of code isn't cutting it. You want a little bit more room and you could go over to something like JS bin and that's great for sharing but sometimes you just wanna play around. The snippets inside of sources, it's just kind of a place where you can noodle around, try out a few lines of code, put break points, try things out, execute it. These are persisted into your Chrome profile. In this case, I was just playing with the battery API seeing how much battery I was discharging and how much time is left, it's cool stuff. There's a few things like little debug helpers that I keep around and if you Google DevTool snippets you'll actually find a bunch of great like debug helpers and performance monitors that people have written, just take them, save them, throw them into your snippets, it's good stuff. All right, now one more thing to kind of finish up debugging. Yeah, so this line of code that we're looking at here, asynchronous code, we got promises and some thens. This is actually a really tough thing to debug currently. In fact, if I place this break point here on line 16, I pause like before any of this, but there's really no way for me to like pause inside of my error functions and see like what's happening inside of them. And if I try and pause here, because this has changed, it just doesn't work, and that's not great. We wanna make sure that debugging asynchronous code is as easy as debugging synchronous code. So we've been working on this and thinking that there must be kind of a better way. So let's see, I'm gonna open up a snippet that I have here. And yeah, yeah, okay, this is good. So we've been thinking about this and working, let me bring that back, yeah, there we go. Working with the V8 team to see if we can improve this experience. So what I have here is some code and we are going to ask the GitHub API for some data. We're gonna fetch it and then turn it into JSON and then get some stuff and hopefully log it out. And let me just try this real quick. Okay, well, it looks like there's a problem. Okay, yep, great, problems are good. Now before, it's been pretty hard to understand what's going on because again, I could only pause in the very first line of this. But so now what I wanna do is I'm gonna place a breakpoint here. In addition to that, we've also found all the candidates along that line of code where you can place inline breakpoints. All right, yeah, nice. So now that we have that, let's see. I'm gonna run this again. So what just happened is I ran it again. Right now we're paused right here at this first guy but I'll let that continue. All right, now, cool. We're paused halfway down the line right after JSON. Now I do see that this response up here is there. Forbidden, that's gonna be fun to figure out. And I even see the return value, this promise. This is actually the return value of this call right here. Now I think I can go for, yeah, okay, yeah, go for it again. And well, to be honest, it looks like data here is coming back. So problem with this demo is that I'm hitting the GitHub API and turns out that for whatever reason, RIP in this building has already exceeded its rate limit. We're like, kind of breaks the demo. So thanks for the people that are using the GitHub API unauthenticated right now. Luckily, I have a backup piece of JSON. This is what the payload was. That's just sitting there. So let me just, you know. There you go. There you go. There you go. There you go. There you go. There you go. There you go. There you go. Okay. How are we looking? Let's clear off these guys. Uno momento. Okay, okay, great. So run that again. I do have a problem and we can inspect exactly what is going on. I kind of think I know we go forward. It was asking for data avatar. Doesn't exist avatar URL. Yeah, that makes sense. Let me finish this off so that we don't have to worry about it anymore. And uno momento. All right, there we go. Avatar URL. Enter. Really? What did I do? No. Guys. I really, there we go. Yeah. So yeah, console image. A little known thing, you know, just tosses an image into your console. Why not? Okay, to be honest, the implementation is down here and it's cool. Stop. Yeah. Anyways, in line break points, I'm really excited about this, really introducing a much better development experience for asynchronous code and all sorts of code. It doesn't really break anywhere you need to. All right, moving on to authoring. And we're gonna start with the front end and I'm gonna head back into the browser. Over here, we have a PWA that me and Sam Sikoni have worked on. It's called CalTrain schedule. As you can imagine, it shows the schedule for the CalTrain. And now we've been developing this and there's always times when you wanna make changes. Now, a typical way of making changes, like we can try out some new colors. And if we like them, you know, usually the method is shift selection and copy paste over in your editor. Now, we don't really like this workflow and we think it can be better. And in previous talks, you might have heard us talk about features like workspaces. And workspaces allows you to bind your local development folder with the actual site that you're looking at in the browser, allowing you to save to disk the things that you're working on. And this is some powerful stuff, but to be honest, there's been some configuration about it, getting it set up. If you've tried it, like, you know, it's kind of like, is it working? I don't know. So we wanted to make sure it's really straightforward and simple. So I'm gonna come back over to sources and clear this out of the way. And so in sources, we see, okay, yeah, this is the code. I have a service worker here and some JavaScript and CSS, right? But I want to be able to persist the disk. So the new experience now is a lot easier. So I'm gonna take actually just my development folder. This is my CalTrain schedule folder locally. Just gonna drag and drop it here and say, yeah, you can access that. And then immediately you see a little, like, green checkmarks light up. And it says, oh yeah, the CSS of the file? Yeah, that's, I know where that is. That's right on disk. And over here, I'm gonna show you on the file system. Here's the entire folder, like my editor config and things, my service worker. But everything that is coming in from the network has a little checkmark to it. So this is a nice thing because we automatically find out for you how things map. In fact, it's not just the basics, but if you have a more complex setup, like you're transpiling your JavaScript or you're compiling SAS to CSS, that should work too without configuration. So we've, like, I could explain how we, you know, made it, to be honest, I don't. It's like magic. So things like, you know, this TypeScript, we were able to map it back and forth. As long as you have a source map for the actual compiled code, we will figure out where it goes and map it so that any changes you make persist. So let's make a changer. So this title could afford to be bigger. That's nice. It's a little too strong. I'm gonna change the foreground color a little bit, dial it back, get in the gray. That's good. Need some shadow. I'm gonna use the new shadow editor. Little too black, but if we lay it up. Ooh, that is some classy stuff. Yeah, I'm liking that. Now, one thing that you might see right here, this green check, it knows that this CSS is actually the one on disk. And if I click through to view it back in sources, we have the diff saying, oh yeah, I know, you actually changed these lines right here. And if I come back over to see my editor, or my terminal, and I just check my diff, oh yeah, that's the diff with the changes that I made. So automatically persist the diff. Cool, so that CSS is looking good, but I'm actually talking about CSS. So the original styles of this site, Sam actually was like pretty responsible for it, but I don't even know if we were like, there's like a lot of styles here and I don't even know if we're using all of them. I imagine that we've all been in this situation. You're shipping an app and you're just like, are we even using these ones? I'm not gonna try and remove them, because that's crazy, but I would like to know. This is hard. The browser kind of knows, right? We're like, maybe we should, hmm. So actually, yeah, as of today in a canary near you, you might find this little checkbox up here called CSS coverage. Now I'm gonna try it out and just hit record, and in fact, that's it, it's kind of done. I'm gonna head back to sources, and now in the CSS, we mark on the left-hand side if these styles were never used. Yeah, so actually, this is pretty good. Down here at the bottom looks like there's all this animation stuff that wasn't used, and I just wanna verify that this is good. The animation is like, actually these little bars that animate out. Looks like there's just two here. I wonder if I can, yeah, I'll try and trigger all of them. Ta-ta-ta, let's just switch this over there. Yeah, that's a few animations. And come back, and yeah, okay. So we are using all those, not that, but yeah, CSS is looking pretty good. So excited about this, because it gives us much better tools to understand, like what of the code that we're shipping are we actually using? Yeah, some good stuff. Okay, okay, coming back. Now, talked about authoring in the browser. A lot of us are full-sac developers. We write JavaScript for the backend too. And at Google I.O., we showed some work that we've been doing to bring profiling and inspection and debugging to Node.js. We've been excited about this, but there's always more work to do. So let's show a little bit of that. So coming back to this Caltrain schedule, I've actually been working on a small little feature to get the live position of every single train. There's an API for it, and I could get the live location. So you can see down here at the bottom of my JavaScript is I'm asking my local server for the position of a train, and I'm just polling for it. I've just started the feature. I'm very early on this one. Okay, so let's kick off the Node, right? So we'll come over here, this guy, and what we can do is we can hit Node-inspect in the app, and whew, ignore that for a moment. We get this URL right here, and this is URL, and we can just actually copy-paste it into our browser and start debugging. But in this case it's kind of awkward because I already have a tab open with DevTools, debugging the front-end, it'd be nice to be able to look at the back-end too. So I'm actually, yeah, just gonna allow this to run, but I'm gonna come back over to the sources panel. And now when I open this up, and it is just the main thread and the service worker down here is Node, and it's like, oh yeah, you're running Node, aren't you? Do you wanna debug that too? Yeah, yeah, actually I'd be done with that. Okay, good. So now we're connected to Node, and I know this because if I switch over here, and I'm looking at just the Node context, that error that I was getting over here is still also exploding my screen over here, so that's great. Okay, train is not defined, apparently. So let's see what's up. All right, so coming down there's my app.js. This is my Node code, and apparently there's an error. Let's just pause on exceptions. It just paused right here. Train is undefined, right, yes, good. And train ID, yes, mistake, by bad. Train ID is just train. Now I'm just gonna hit Control S, and I think that takes care of it, and we'll know if we see sending API request. It's paused, who said that? They get like two extra points in the quiz. Okay, paused. All right, yeah, yeah, good sending API, yes. Okay, and in fact, coming back to my other context, my page, I went from a bunch of, yeah, 500s internal service errors to 200s, and that's what you like to see. Oh, good, okay. So we're really excited about this because this allows us, yeah, sure, yeah. It got a clap on the 200s. We're excited about this because this allows us to use a single DevTools and speak to both the front end and the back end at the same time, keeping your attention in one place while managing multiple contexts. It's just good. All right, moving on. I've heard a bit about progressive web apps today, and there's some nice tools in the DevTools to tackle that. I'm gonna briefly just review some of them. Over in the application panel, there's some great stuff. First up, the manifest view will tell you what's in your manifest, and in fact, if the browser finds anything that's not so sure and it issues a warning or an error, you'll see them shouted out right up here at the top. Then the service worker pane tells you everything. The state allows you to manipulate your service workers, and then I really like this. The clear storage pane allows you to not only unregister your service worker with one click, but take care of your cache storage, your app cache, your any of your local storage. Just wipe it out and kind of start fresh. I use that all the time. I do wanna spend a little bit more time on the service worker panel itself, and there's two things that I wanna point out for you. Really helpful tips when you're doing this debugging. Up at the top are some checkboxes. The checkbox in the middle, update on reload. This is a super helpful guy. You can think of it kind of as like a disabled cache, but for the service worker JavaScript itself, like it's great for when you're working on SW.js, the service worker.js, and you're just making changes to it. You wanna make sure that you load in the new version every time. It'll just make sure that as you reload, it pulls in the new version. You don't have to worry about some of the caching stuff. The other checkbox, bypass for a network, basically says, hey, service worker, you love to intercept requests and serve from the cache and all this stuff, but I'm working on my site right now and I'm updating my styles and my pages JavaScript, and so I really don't wanna like you to be serving things from the cache and intercepting, so it's just like, just chill with the network stuff. So this allows you to just iterate on your pages, content, your styles, and JavaScript without the service worker getting in the way. So definitely check those out. And as you keep on, as you work with these tools and find things that are like, hmm, making your question stuff, feel free to just holler at us and ask us if there's a better way that the tools can represent what's going on because we'd love to make sure we can help. Now, there's a lot of things in doing progressive web apps that you kinda have to keep track of and especially if it's your first time just getting your manifest and your service worker set up the right way is a little tricky. And so we've thought of been working on better ways for us to understand if we're hitting all the right marks and if there's anything else that we can do to make sure that what we're building is great. A lot of that work and that investment has gone into a project called Lighthouse, and Lighthouse is a guidebook for helping you turn a web app into a great progressive web app. And more than that, it analyzes any web page and any website and not only collects performance metrics but helps identify all sorts of developer best practices that you could be doing and making things better. So like as an example, it audits for a number of different things as far as can the user be prompted to add it to home screen? Does it have a custom splash screen? But other things like are you using passive event listeners when you should? Are you avoiding mutation events and document write? And over 40 different audits checking for just developer excellence. On the other side, it also does a great job of having performance metrics that capture kind of the user perceived performance in the most accurate way possible. So you've heard a little bit about first meaningful paint and time to interactive, and Lighthouse measures those and helps illuminate what is actually happening when things are slow. So Lighthouse is available as a Chrome extension. Let's see a little bit over here. See over here, yeah, I can run it from the command line. It'll just kick off a new version of Chrome itself and just run all of its tests, the same tests there. And this works well. Lighthouse is just a node module. And in fact, a number of other tools are already using Lighthouse and building on top of it. So feel free to check it out like that. It works well with a headless Chrome in a continuous integration environment. So if you want to set up progression tests for performance or audits, you can definitely do that. And the other thing is that we've really been happy with how doing these checks to see like this along the right path. This has been working out for us. But we wanna make sure that it's even more available. So I wanna show you another new thing. I'm gonna come over to our Caltrain schedule and I'm here in the DevTools. And we're like, maybe we should have it available not just here as a Chrome extension, but what if, let's open this up more tools and we have a new Audits 2.0. So this Audits 2.0 is powered by Lighthouse. So as I, I'll just make this, yep, there we go. So I'm just gonna go ahead and this is using the same Lighthouse that is in the extension, the command line, running all the same checks. So it's looking for things like usage of document write, usage of blocking style sheets and helping you understand what's going on. So pretty soon it'll give me a report. I'll be able to browse that. And yeah, okay, looks pretty good. Fast, site is fast, good job, Sam, okay. But scrolling down, this was, this is interesting, check this out. Site opens external links using relnope. And in fact, there's, we have two links on the site which are external, open in new window and not using this guy. You'll have to read about this. And this, like, I saw this and I was like, honestly, we really need to do this. So this is super, yeah. So I'm gonna fix that like right after I get off stage. But yeah, I encourage you to check this out. And the nice thing here is that because this is using Lighthouse, Lighthouse is just sitting on GitHub. It's a bunch of JavaScript. So if there's anything that you're interested in auditing for or just wanna check, just please come by, drop by. We've had a bunch of people collaborating on the project so far. So come check it out, talk to us. If you have any ideas, we just love to work on it with you. So what do we see here today? A few things. We walked through looking at stronger debugging with modern JavaScript and I got to show the inline breakpoints. Love it. The parallel debugging with Node.js and the browser at the same time, a single window. The persistence, saving to disk, really painlessly, automagical mapping between everything. The CSS coverage to find what CSS you are not using and new auditing functionality available in all the right places. If you're not, follow us on Twitter, our doctor there, and just, yeah, please grab Canary, turn on some of the DevTools experiments if you want. And if anything, bugs, certainly, but even just feedback or ideas, go to CRbug. It'll be like, do you wanna report a bug? Don't file feature requests, but just ignore that and just file a feature request. It's just like, hey guys, what about, what do you think? That's fine. We'd love to hear from you. That's it for me. Thank you very much. Thank you very much, Paul. I loved the applications tab in DevTools. When I was building the Chrome Dev Summit website, it was the best thing to be like, here are your icons, here's your service worker, here's everything. I'd love that. It's a really good addition. Well, should we press on with the next talk? We absolutely should. Keep up the pace. To talk about web components, the next one. And it's the speaker who, for my money, has the best name anyone in Dev World. Oh, I can't say it. I can't say it. I was Taylor Savage. I really struggled then. Well, how would you say it? Taylor, Savage. You'd go for the movie one. Why not? See, for me, it sounds like a wrestler. Please welcome to the stage, Taylor Savage. All right, thanks, everyone. My name is Taylor Savage. Great intro. Yeah, my name is Taylor Savage. I'm a product manager here on Chrome on the Polymer project. I'm here with Monica, who's an engineer on the Polymer project as well, to tell you all things Polymer. So I'll start off by talking a little bit about where we are with the project overall and how we think that web components are really changing how we do web development. And then Monica will go into some of the more technical details around how to take best advantage of Polymer of web components to build a really great, high-quality, modern, mobile progressive web app. But first off, let's talk about the mobile web. And we've been talking about the mobile web a lot at this conference. It's kind of like the mobile web conference. And there's good reason for that. The mobile web is incredible. There has never been a more important time to have an open, decentralized communication network where anyone in the world can access this information coming from anyone else in the world. And as developers, this is incredibly exciting. You can put something up on the web and a user somewhere halfway across the globe is just a URL away from accessing your application. That's great. But for developers, there's also a dark side to the mobile web. And if you've been doing mobile web development, if you've been really trying to get the best possible user experience across to your users on their mobile devices, you know this dark side, which is that we are at war with phones. Phones are our enemy. They're our user's best friend. But as developers, they are our enemy. And it can feel like as we're trying to produce the best possible user experience, the phones are fighting against us at every possible turn. Mobile networks are vast. There are over 2 billion users with a mobile smartphone in their pocket to access our web applications. But chances are a large percentage of those users are on slow, unreliable, expensive data connections, or they're not on a data connection at all. And that's something that we've never had to really deal with as web developers, as developing for the desktop web, where you're plugged into the wall at all times. Mobile devices are everywhere. They're in everyone's pockets. You're a pocket reach away from a great user experience on the mobile web. But that means that mobile phones are fundamentally performance constrained. They need to have this tiny little battery that can power them all day long. And they need for when you take them out of your pocket for them to not burn your hand. And that means that to power, for the battery to last all day, to power the sensors and the radios and not to mention this high-resolution screen, it's going to be very constrained in the terms of the power that it can actually deliver to the CPUs that are doing your math for you that are running your application. And we've got a lot of tools available to us, a lot of open source tools available to us as web developers to allow us to create these web applications. Then these tools are incredibly diverse and incredibly powerful. But it can seem like more and more of the tools available to us are getting continually bigger and continually more complicated. Building a great mobile web experience is hard. It's a little bit like climbing Mount Everest. It's challenging. It's expensive. To really do it right, you need kind of a lot of training and a lot of good guidance. And this is a shame. It should be much easier to deliver experiences on the web to users, especially in this important mobile context. But there's good news. We have a mantra on the Polymer Project. We have kind of a philosophy about how we think we should be building web applications, how we should be thinking about as we're constructing these new mobile web applications to make our lives easier and to make our user's lives better. And that mantra is to use the platform. The web platform is getting increasingly powerful. With new primitives like Service Worker, like web components, with new serving mechanisms like HTTP2, we have more tools at our disposal as developers than ever that allow us to build and deliver a really high quality web application. And so it's our responsibility now. In fact, it's our advantage to take advantage of what's already there baked into the browser sitting on our user's devices in their pockets in the form of the web platform. So the Polymer Project is the Chrome web platform's team set of libraries and tools for web developers to help developers take full advantage of the modern mobile web platform, to take advantage of what's right there sitting on the browser. Now, the primary feature that Polymer the library has been focused around is web components. And web components is an umbrella term for a set of low-level APIs baked into the web platform, new web platform specs that allow you, the developer, to create reusable, composable components on the web. They create a new component model on the web, allowing you to essentially extend the HTML language to create your own HTML tags that get understood by the browser just like any other baked-in HTML tag. Now, if you've been following web components, they've been around for a little while now. So the first spec came out in 2012, which was a while ago. And frankly, back then, we were over-optimistic. We were over-optimistic as to the speed at which web components would become broadly cross-browser supported. But this is OK. We went back to work. We went back to work with all other major browser vendors to work out a new, an updated set of these APIs. The idea was sound, everyone was on board the idea. We just needed to kind of work out the kinks in the APIs themselves. And so I'm very happy to say that as of today, we've turned a major corner with the web components APIs with an updated version of some of these web component specs, Web Components V1. So previously, web component support was scattered and it was varied. Template was supported across the board across all major browsers. But Shadow DOM and custom element support was either behind a flag or unsupported in most browsers. Today, with Web Components V1, as you heard earlier at the keynote, this story is completely changed. So all major browser vendors are on board with shipping Shadow DOM and custom elements V1 versions of the specs. In fact, Safari in Safari 10 that just shipped recently has Shattered on V1 shipped. Chrome has Shattered on V1 shipped. It's on the high priority roadmap of Edge. This is very exciting time for web components. HTML imports are still on hold as we're working out how they're going to interact with ES6 modules. But I'm confident we'll come to a really good solution for how to load HTML with HTML. So I can't say this enough. This is a huge turning point for web components. At Google I.O. earlier this year, I said that cross browser web components was not a matter of if, but a matter of when. And when is right now? Cross browser web components are here with Web Components V1, which brings me to Polymer. So the Polymer library, the library itself that forms the soul of the Polymer project is a lightweight layer on top of these web components APIs. And it's designed as an opinionated way to pull together these different low level specs, these low level APIs, and make it easy to build, for us developers to build a reusable web component, a reusable custom element. Now Polymer started out as an experiment. It has evolved with web components as the web components specs themselves have evolved. So Polymer started out just kind of to test out what would be the different low level features that we would need as a web developer to create this kind of reusable element, to extend HTML. So Polymer 0.5 was the last release of Polymer that was still kind of in this experiment mode. And then after a few years of iteration, after working on the specs, after working on the library, it turned out that these web components things were actually pretty powerful. And so last year, we released the 1.0 version of the Polymer library, which was the production ready version of Polymer. It allowed us as developers to take advantage of web components today in production applications without necessarily the APIs having to yet be shipped broadly across the different browsers. So Polymer has kind of quietly been out for a little over a year. And I think because Polymer started out so much as an experiment with these very early web component specs, we often get the question, who is using Polymer? Is anyone actually using Polymer in the wild? So I want to just name a few of the companies that are using Polymer in production today. So Polymer is used by Comcast, which is the largest media company in the world. It's used by the USA Today, which is the flagship brand of the largest newspaper publisher in the US, GANET. It's used by ING, which is the largest online bank in Europe. It's used by Netaporte, the largest luxury fashion e-commerce company. Polymer is used by BBVA, which is one of the largest banks in Spain and Latin America. By Coca-Cola, which is the largest beverage company in the world. It's used by Electronic Arts, which is one of the largest game publishers in the world. By Predix, which is the software platform for the industrial Internet of Things from General Electric, which is the largest digital industrial company in the world. And of course, Polymer is used here at Google, actually quite heavily here at Google, on some of our biggest user-facing products. So Polymer is used in Chrome in the Chrome UI pages, which has over a billion users. It's used in plain music. It's used in YouTube gaming. And just recently at the Polymer Summit a few weeks ago, we announced that Polymer is actually being used on YouTube. YouTube, which is one of Google's biggest products, also with over a billion users, is now building the next generation of their mobile and desktop applications all on top of Polymer. So there's an immense organizational power that we're seeing to relying on standards. To relying on standards-based web development, you get this seamless frictionless sharing of code that we've never been able to really, truly achieve across all kinds of different teams on the web platform before. And we're seeing more and more large companies going all in with Polymer, with web components, with web standards-based development using the platform. So a big value prop for web components is that they're interoperable. That you can build a component with browser-based technology and then share it to other members on your team, share it with other teams at your company, share it with the overall ecosystem that anyone can take advantage of that component, no matter what kind of stack they're using, no matter what the rest of their JavaScript stack, your JavaScript stack looks like. But this is great, but clearly, we've got big projects working with web components, big teams that wanna not just build components, but wanna build entire applications. So we get the question a lot, how can I take web components and then build an entire application, specifically an entire progressive web application out of web components? And our answer in the past has always been, well, that's the whole point of web components, is there's no one way to build an application. You can choose any of the tools that you're familiar with, anything that you like already, and use that to put together web components into an application. But obviously that is kind of unsatisfying. And what we realized is that if you take web components, which are one new set of web platform primitives, and you combine them with other new, really exciting web platform features like ServiceWorker, like HTTP2, you can actually end up with a whole that's much greater than the sum of these individual parts. And so we wanted to put together kind of an opinionated showcase of how all these different features are really designed to come together and make for a really great user experience. And so earlier this year, we released the Polymer app toolbox. And again, the goal of the Polymer app toolbox was to go beyond just components and show how components can be put together with these other technologies into complete progressive web apps. So the app toolbox includes a set of web components, app level components for things like layout and routing and internationalization. It includes a command line tool, the Polymer command line tool that lets you build and deploy your application. And things built with, applications built with the Polymer app toolbox are designed to be served via what we call the purple pattern, a way of using HTTP2 in server push to being able to deliver just absolutely the minimum of what you need to be able to render each view of your application to your users with minimal overhead. And you'll hear more and more about this purple pattern across various talks at this summit. And then in addition to the components and the pattern and the CLI, we wanted to show what you could actually create when you put all these things together. And so we launched shop.polymerproject.org, which you've also already seen in many of the demos up here, a progressive web app that really is just a killer user experience, it uses the app toolbox, it uses the purple pattern, it uses Polymer web components to deliver an e-commerce-like application. You can visit that at shop.polymerproject.org. And we're already seeing the kind of value of this Polymer app toolbox being used by companies to build applications. So take Jumia Travel, which is the travel division of Africa's largest e-commerce site. Now, 75% of mobile connections in Sub-Saharan Africa are on 2G. And that's forecast to still be 45% in 2020. So there's an immense challenge to be able to deliver a rich full application over the narrowest network you possibly can. And so thanks to the Polymer app toolbox and thanks to web components in the purple pattern, Jumia's progressive web app is able to achieve this. They build a progressive web app on the Polymer app toolbox that has twice as fast a page load on 2G and uses six times less data than their native app to be able to deliver the same exact flow. And I think the quote from the Jumia team really speaks to the value and the power of web components, which is that they were able to build a complete kind of prototype of this website, the entire flow in just four weeks so that they could show it to their management and sell the management that this is a very valuable, compelling experience and then go from there to build the actual production application. So this is exactly what we want web components to allow developers to achieve really rapid prototyping all the way through to production deployment. So we're really starting to feel the momentum of web components. Web components are now being truly broadly adopted cross browser. They're being used in real serious production applications by large companies and here at Google. And this means that it's time to kind of open the next door for the Polymer project. So we're working right now on the next major push of the Polymer library, which is Polymer 2.0. So we just released the preview version of Polymer 2.0, it's up on GitHub. And there are a few key things that we're focused on when we're designing and working on Polymer 2.0. A few key features and distinctions that from the Polymer 1.0 release. So the first obviously is Web Component V1 support. Web Component V1 are the specs that are going to be broadly shipped across browser that we're already seeing out there. And Polymer 2.0 is designed to take advantage of these new custom element and Shadow DOM. V1 APIs baked into the browser. Polymer 2.0 also offers better interoperability with other JavaScript frameworks with other JavaScript tools by eliminating some of the Polymer specific abstractions that kind of leaked through in Polymer 1. Namely the Polymer DOM, Shady DOM APIs and some structured data manipulation that leaked through. So the takeaway is that an element, a custom element built in Polymer 2.0 is truly web native. It will be indistinguishable from any other vanilla Web Component that you might build with any other Web Components framework or just with raw vanilla Web Components. And finally, we don't want to leave Polymer 1.0 users in the dust. One thing that we took away from the Polymer 0.5 to 1.0 transition is that transitioning a major framework, transitioning a major dependency, even if it's small, is a huge pain point, especially for large companies, especially for large projects, especially for teams at Google that are relying really heavily on Polymer. So with Polymer 2.0 from the beginning, we've designed it with backwards compatibility in mind. So Polymer 2.0 comes with a near seamless backwards compatibility layer, making it as simple as possible to be able to transfer a Polymer 1.0 component to work in Polymer 2.0. And Polymer 2.0 also supports what we call hybrid mode. And hybrid mode means that you can, there's a way to write a component such that it can work on Polymer 1.0 or on Polymer 2.0. And so what this allows is, if you've got lots of components in your application, if you've got lots of components shared across your company, you can incrementally upgrade one element at a time while your application is still live in production. And once all of these components are upgraded to this hybrid mode, you can switch over from using Polymer 1.0 to using Polymer 2.0. And then continue to take advantage of the Polymer 2.0 specific features. So it's a much, much easier, much smoother, more seamless upgrade process than having to stop all the presses and upgrade everything at once before you put your application back into production. So Polymer 0.5 was an experiment for web components. Polymer 1.0 was allowing you to use and achieve the promise of web components in production. And with 2.0, we can finally realize the full value of web components, which is going web native, which is actually truly using the platform, using standards-based cross-browser APIs to use the platform to write less code, to ship less code, to write more elegant, smaller applications and deliver them across the mobile web. And we're actually seeing this use the platform mantra bearing out in the numbers with Polymer 2.0 when you take a close look at how Polymer 2.0 actually works and is built. So Polymer 2.0, if you build a web component with Polymer 2.0 and you ship it on a browser that doesn't need any polyfill, so that supports web components V1 out of the box, Polymer itself is only 12 kilobytes. It's small, and it's getting smaller and smaller. And that is our whole goal with Polymer. We're not trying to build a massive framework. We're trying to build a tool that gets smaller and smaller as the platform fills many of the gaps in our developer experience. So this is using the platform in actual service to the Polymer library. We are just at the beginning of the story for web components. And we're still actively figuring out all the kind of best practices and best ways that we as developers, as teams, as an ecosystem, can take advantage of all the things that web components provide. So we've been building web components for a few years on the Polymer team, and we've certainly learned a lot in those few years. And so here to tell you more about how to take advantage of web components in the browser and how to build really killer applications using web components is Monica, an engineer on the Polymer team. Coming up mid-talk means that I didn't get an awesome Paul Lewis introduction, so I'm super bummed about this now. Hi. So the thing about Polymer, the library, is that it's not really about the library itself. It's about what you do with it, and that's building elements. And what I've been thinking about on how to structure this talk, I've realized that when Taylor said that mobile web development is hard, the same thing can be said about element development. It takes a lot of expertise. It's really hard to make a good element that you can put on every page that you have, so I think it's really important to actually talk about it. And what we've been talking a lot about is how to make a good element, that how to make a fast element, and we've given talks about, oh, I'm not allowed to go back. And we've given talks about that, but then I thought about it, and there's three kind of people that actually interact with elements. You've got the people who use their elements, who don't actually want to build a good element. They just want to use other people's elements when they're developing a web app. There's people who author the elements, and we've been talking about them a lot, and there's people who maintain the elements, and these may be the authors, but it may just be other people who've inherited these elements, don't really know the intimate details on how this element came to be the monster that it is. So we need to be able to address their concerns too. So I'm gonna do two different things. I'm gonna talk about the people who use the elements and give you some advice about how you can architect your apps using web components, and how we've built some tools for the people who have to maintain those elements. And on the Polymer Elements team, we have a lot of experience with this. We initially authored over 100 elements. I think it's over like 130 now, which is kind of a lot. We've spread them across three different orgs to make everything actually really complicated and hard to sync and test together. Why not have a little fun while you're at it? We've used them internally, like just in our team on over 20 apps, and this is important to us, like the Shop app, because that's how we come up with advice for other developers. That's how we come up with patterns that you can use. And we're also on the maintaining side of this. Polymer Elements are used in over 500 apps. These are internal to Google. They're external to some of the companies that you heard about before. So we kind of cover all of those three different areas that I talked about. So let's talk about app developers. It's probably half of the audience. You maybe wanna use a web component in your application. How can we make this better for you? What best practices do we have for you? And the best advice that I have is that you should not look at web components as something that they are new. You already know about components. If you've used any language, you've got objects, you've got the ideas of like, compartmentalizing your code, that's not new. And web components themselves aren't actually new either. If you've ever used an input element or a button, they're kind of like a web component. They're a little nugget of functionality and code and styles that have been put together in a little box and given to you, and it has an API, and you know how to use them. You've been doing it for a long time. What's new is that other people can now build these web components that are just as powerful as input and button. They just have different names, and you should treat them basically in the same way that you've been treating input. So, I built this really to demonstrate like the next example. I built this really dumb app for the Polymer Summit. It's basically a emoji social network where it's kind of like Twitter and Slack jammed into one, but instead of being useful, the only thing you can type is English and it gets translated to emoji. So the only thing that you see is like a stream of emoji. And I'm walking around with a beacon now. I've got my first physical web beacon, so if you're like around me, you can actually get a link to it. It's mojibrag.frybase.com. But when I was designing it, I was like, okay, cool, let's say that I've never used a web component before and I want to design an app with them, what do I do? And it's basically the same way that you would use like a normal application. You just think about the features that you have in your application. Somehow I have to authenticate a user, then I got to show them something like a giant screen of a blob of text, and this text can be like a list of other people's dumb emoji posts or the amazing ability to write your own dumb emoji post because how else are you gonna get content in there? And once you figure out these features, you can like go ahead and dig deeper in each of them. Well, when you write a post, you have to somehow translate from English to emoji and then if you've got a list of posts, you can like like them and see their location and all sorts of other stuff like that. But once you have this idea of like what the logical components in your application are, it translates immediately to web components. The authentication part is done with Firebase Auth, which is an element that does authentication with Firebase. IronList is the thing that manages your list of elements. And then new posts in my app are little web components that I built internally to my app just to like logically structure code around. And it was really easy. And the awesome part about components, and this again is not new. It's happened if you've ever written a class before. If you've written a component, you can refactor it really easily because it doesn't affect the rest of the app. It just sort of sat there as a standalone thing and you just get to fix its code. So this shouldn't look scary. It's how you would write web components. You could call it a div class equals main screen, but now you can just say main screen as an element. And because web components aren't new and you've been using them in the browser, you just didn't know that an input was a web component, you should use these new web components that you're getting from users in the same way. And that's by using properties and events. If you look at an input, you set all these properties in it. You said it's type, you said it's value. You said whatever, the min length and max length. When an input does something, it fires an event, it fires an input event, it fires a change event, this isn't new. And this is exactly what people have been doing with their web components. Properties go down, events go up, and you get this magical unidirectional data flow in your application. So if you go back to my application from before, you have this giant screen at the top that knows about the state of the world and you've got your post button where you like mash on your keyboard and emoji comes out. And the app is gonna know things that not every component knows about. For example, it knows what channel you're posting to, so it's going to inform anybody that it cares about by setting a property on those elements. Again, just like you've been doing with input. And when you're done mashing on the keyboard and you have a new post ready, you fire the custom event and be like, hey, I got an emoji post, does anybody care? And if anybody cares, they're gonna intercept that event. And the same can happen if you wanna hide conditionally UI in parts of your application. You just set different properties. What I didn't tell you here is that you should call a public method on this element or something like that, because again, that's not how we've been using DOM elements before. We don't call random functions on input. We just set properties, which leads me to my third device. Use properties and non-message. You might be tempted to use methods because JavaScript is really keen on having methods, but that's not how the DOM really likes to be used. The DOM has properties and attributes. And this is really great if you're using properties because then you can just use them imperatively and you can have data bindings and stuff like that. So imagine you have a dialogue, you could call dialogue.open on it, but you don't need to. If it's got a property, you can just say, hey dialogue, dialogue.open equals true. And once you've done this, you can just do it as a binding somewhere in your code and it depends on like some other state of the world. And without writing any JavaScript, like things will open and things will hide as they should because that's how properties work. So properties, properties on methods, properties go down, events go up. Those are your rules. So that's the advice that I have for app developers. But what do we do about element maintainers? You're like this poor sucker that has inherited like 17 elements that somebody else wrote left the company and you don't actually know why they're in that state. And this happens whether you're maintaining elements externally like we do for like the rest of the world or internally, like a lot of companies do, they just have an internal set of elements, but they still have to maintain them. So we've been writing tools and the biggest advice that I have is you keep hearing about like test driven development, that's great, but I think you should practice fear driven development. And that's not being afraid of the code or anything like that. It's really just being afraid of your users and that's a healthy approach to development. Because most importantly, you should be afraid of like breaking them and breaking their applications. That's like your one responsibility as a maintainer. Don't break other people's code. So in preventing breaking changes, we've been using this tool internally and we're working on like making it, it's a public repo on Polymer Labs and we've been working on fixing it so that you all can use it. And it's called TAD2, which stands for test all the things over and over because why not come up with a complicated acronym if you can. And the idea is really simple. When you, if you're a maintainer and you wanna like accept somebody's pull request, your biggest concern is that you don't actually know what this is gonna impact. Look at this dependency graph, which is not a real dependency graph, they're usually way worse than this. But if you modify a leaf at the bottom, unless you have the ability to like hold all the 130 elements in the Polymer Elements catalog in your head, you're probably not gonna know what that change is gonna affect. It could be a behavior, it's maybe like the ability to be included in like a custom form or something like that. You don't actually know how many elements depend on that change, especially since they can go many levels up the tree. So what TAD2 does is it lets you specify a branch or a particular hash or something like that in a particular element and rerun based on that commit a whole suite of elements, a whole suite of tests. So in this case, we make a change to one element and like make sure that all the other tests pass. And this is great because then you have the confidence as a maintainer that like this PR isn't gonna destroy all of YouTube because we've definitely not done that before. The other thing that you should be afraid of is perf regressions. It's really great that now you have the confidence that you're not gonna break somebody's application but making their application slower is kind of slightly worse because that's harder to fix. And we have two tools for that. The first one is Poly Dev, which is a Chrome extension and you can run it on any app that uses custom elements and basically ranks how expensive the elements that it sees on the page are. And it's great if you wanna like audit your page and make sure that as you're contributing to an app, so this is also good for the app developers. As you're like fixing your app, the performance sort of stays as you expect. But it's also really good for maintainers. If you have like a giant catalog that has like different demos for different elements and one of these elements that used to be really cheap after a commit suddenly like spikes to the top, that probably means something bad has happened and you wanna like undo that change. So that's what Poly Dev does for you. It's in the Chrome app store. You can download it, it's awesome. My favorite tool is Poly Perf. And please note how these names have a poly prefix at the end, but tattoo doesn't because poly tattoo is weird. So Poly Perf lets you basically compare the performance between changes. So here, this is an example from Steve Stock from the Polymer Summit where as a baseline, he has an input element and that's not, it doesn't cost you 20 milliseconds to make one input, it costs you 20 milliseconds to make 250 of them on a page. And then he had like this ratings element and he started with like a super shitty version and then just made it progressively faster and these are just like three iterations of that ratings element. And the reason why this is good is because you can start doing it for like, again, different commits and different shaws and different features that you're adding to an element and be like, cool, this element used to cost like 129 milliseconds and now it's 500 milliseconds. Is this change really worth it? Which is great for you as a maintainer because then you can go back and be like, no, this changes shit, we're not merging it, it's fine. So that's fear driven development. The sort of parallel and kinder version of development to that is demo driven development. If you think about your users, they don't really, like I personally can't look at a snippet of code and be like, I totally know what that element looks like and how it's gonna fit on my page, that's great. I can only like look at demos and be like, I want it, I want the shiny button. So that's what demo snippet is for. Demo snippet lets you write basically how you would use that element, shows you what the code is and shows you what that element looks like. Here is a whole bunch of paper fab buttons. Fab stands for floating action button, not fabulous, and it took me about a year and a half on the team to find that out and I was super sad. I think fabulous button is a way better name, but nobody listens to me. So that's a demo snippet, it's really great. And we've noticed, we've heard that Comcast, for example, uses this element very aggressively internally to just be like, these are all the elements we have, this is what they look like, do you care? And we've taken this demo approach very aggressively to the new beta site for the webcomponents.org. So beta.webcomponents.org is the new element catalog where we're moving all of our elements too, and it basically supports collections and elements and they're curated collections. You can make a collection called fabulous elements and you can add all sorts of web components to it. So when people search for fabulous elements, they'll get to it. Oh, sorry. But most critically, it supports inline demos. So this is the documentation page for paper fabulous. And here at the bottom, you see a demo. And it's a snippet, but the best thing about the snippet is that it's not static like the demo snippet used to be. It's actually interactive. So here I can change the contents of one of these buttons or I can even add a style because this kind of element advertises a custom property to change its color. So you can go ahead and do that. So what now? We have web components, they're native in the browser. Polymer 2.0 is right around the corner. What does this mean for you as developers? Because this is called Polymer Web Components in U. Let's talk about the U part. There's never been a better time to actually start using web components. So go ahead, just go and use an element. I have a really dumb element called emoji rein that makes it rain emoji in your page. Go ahead and drop it on your blog, why not? Use Polymer. Don't use Polymer. Use vanilla custom elements that you stumble across. Make your own element. And if you do share it, polish it up, submit it to beta.webcomponents.org so that everybody else can look at it and it's going to be really awesome so that their applications can get better. But most importantly, just make things. Use the platform. Use tools that make your life better and make you write less code. And build awesome things for the web, because it's up to you to make the web better. We can just help you along with it. But at the end, you're going to make it awesome. Thank you. Hello. Hello. Can you stand on the other side? No, you go really consistency. Consistency. Continuity error. Shall we do some more quizzing? Oh, yes. Right. If we get the quiz screen up, that would be fantastic. Bones and laptops ready for the big quiz.com? Yeah, come on. Give me that logo. Switches to the editor. Thank you, Miles. Everyone can get logged in. Look at that. That's a black screen. That was a good noise. That was great with that. OK, so we can talk a little bit about the next speaker. So the next speaker is Alex Russell. No. He was working on these slides reasonably late last night. So I'm staying with Alex right now while I'm in San Francisco. And yeah, he's such a nice guy. There's a few people staying with him. And I got up for the bathroom in the middle of the night last night and just sort of opened the door. And I was greeted there with Alex just sat on the landing and he built himself a kind of fort out of cushions working on his salt because every other room in the house was occupied by someone else trying to sleep. He had a little Alex fort. Yes. Into which he was. Until three o'clock in the morning. So yeah, we'll see if his code works any better than ours has. Can't be bad. Should we keep filling? Quiz is not going to work. OK, well. Well, we'll do the next questions after the next talk then. We certainly will. In which case, here to cheer you up. It's Alex Russell. Do we jig now? Like, is there a vamp? I thought this was their job. I'm, it really is. We thought we'd come back and just say, leave no man behind, as it were. You are not working on the quiz right now? No. No, we've quit. The quiz is solid now. No books. Off, off. Oh, your slides are here. OK, fine. Hi, good afternoon. I'm Alex Russell. I'm an engineer on the Chrome team. And to set expectations, this isn't the talk I usually give. So I hope you'll bear with me through some difficult content. These days, I usually put this slide up to start to talk about Progressive Web Apps, which Frances Berman and I named last year. Progressive Web Apps are the culmination of multiple years of my team's work. I've been working with Jake on service workers for like just four years now. And the team that I work on has been designing and building the core technology for Progressive Web Apps. The stuff that you've been hearing about for the last couple of Chrome Dev summits and all day today and probably all day tomorrow. And I apologize a little bit, but not really. But as you can imagine, building and maintaining all that stuff and working on the standards for it is a full-time job. But I'm not going to talk about Progressive Web Apps today, at least not directly. You see, for the past year, I've also been working with Tao and her team to partner with folks who are about to launch their Progressive Web Apps to make sure that they're really high quality. And this sort of incidental consulting work has given me a broad view into the practices of many of the teams that are building for the mobile web today. What I can say with only a few exceptions, exceptions like booking.com and the great work that the FlipPR team did, is that most of us don't really understand how hard mobile actually is. I haven't exactly been making friends in the JavaScript framework community by saying that sort of thing out loud, turns out. But as the Polymer team will tell you, this is basically the PG version of what I've been saying to them for something like a year and a half. We had some really tense meetings. I kept saying things like, it needs to be more asynchronous or, look at this trace, you really need to load a lot less JavaScript than 12k. Sounds good to me, actually. Or you really need to break up your script so you're not executing this entire long block. What the heck is going on here? And at some point, they said, we get it, we get it. Just stop telling us what to do and start telling us what goal to hit. And this was kind of a breakthrough in the conversation and we've been sort of at loggerheads for a while. And so I kind of put my finger in the air and said, it would be really great if you could get me something that's interactive in about three seconds on a 3G connection on first load and interactive in about a second when I launched it from the home screen. So the Polymers went off and they went through the stages of grief. We had some denial. I'll admit, there was some denial. Anger, yes, bargaining, absolutely. Depression, luckily they sit far enough away from me that I couldn't actually see them sobbing in their cubes. But I finally accepted the challenge and they came back with a purple pattern which Sam is gonna talk a lot more about. Meanwhile, the rest of the JavaScript community kind of hasn't internalized the same message to the same degree. So I'm here to let you down. Not easily, this may be a little bit hard and I apologize in advance, but we need to get to the bottom of what mobile actually means. And when you see me tweeting things like this, this is actually kind of desperate. I have spent years of my life working in TC39 to make JavaScript a better language. I have spent countless hours persistently advocating for extensibility to give you more power when you're writing JavaScript in the web platform. I've designed features like service workers with Jake and a load of other folks that are entirely predicated on JavaScript in the first place. Back in the day, I used to work on a JavaScript toolkit with Scott and Steve from the Polymer team. It's not like I hate JavaScript or I don't like it or I think you shouldn't be using frameworks. I don't hate them. It's just that we're really in the midst of a crisis and collectively we don't understand how bad that crisis is. If we did, we would have already modulated our behavior. So what I'm seeing when I do reviews is almost universally bad news, specifically in the context of the rail performance model. A quick recap of rail, basically our stands for responding to input in under 100 milliseconds. We're animating at 60 frames a second, which means that because the browser has to apply the things that we hand it on every frame, we probably only have about eight milliseconds to get to do our work. When you think about WebVR, it gets 60 frames. 60 frames a second is hard, 120, oof. When we're doing background work, we need to make sure that we're breaking up that background work into 50 millisecond chunks so that we can respond to subsequent input and stay under that 100 millisecond budget. And we really want to complete actions for the user in under a second, because over a second, research suggests that users lose focus on the task that they're trying to accomplish. If we can't actually complete it, we definitely need to acknowledge that work in under a second. Give users the sense that we're doing something for them. So you've heard this number all day today. Darren had it in the keynote, but the double-click folks went and did a bunch of work to find out what are the bounce rates for sites and does performance matter? And the answer, of course, is yes. 53% of users bounce from mobile sites that take more than three seconds to load. You leave real money on the table when your site is slow. Yet most of the apps that I've traced over the last year have been performance travesties. My experience isn't an outlier. The last, that same report noted that the average mobile site takes 19 seconds to load. 19 seconds. Collectively, we're failing. Sam's got more data on this, and I actually don't have time to go into it because we're gonna talk about some of the reasons why. But I think one of the key reasons that we are not succeeding today, to put it kindly, is a lack of understanding and respect for how hard mobile is. I have faith that as a community, if we understood and respected the limits, we'd be doing much better. Nobody here wants to make bad user experiences. I think part of this is because we're the only platform in the world that tried to take all of our desktop stuff with us. You don't take a Java jar that was a swing application and run it on your Android phone. You don't take a Mac universal binary and run it on your iPhone, right? You don't take a Win32 app and run it on your Windows phone. Everybody else switched their tools when their form factor and their constraints changed. We didn't. We didn't make that switch, and the proof is in the pudding. It's in the traces that I'm looking at every day. But that's not the only reason. Why are most of the popular frameworks and the tools that we're using, the tool chains that we all wind up setting ourselves up with, unacceptably slow by default? Why are our tools producing such bismol results? It's not like we're bad people who want bad things for users. I think in part, it's that you all aren't actually developing on mobile phones. Paul showed you some really great DevTools. They're awesome. So, but I want to understand who uses Chrome DevTools to sort of get the responsive view and understand how things will look on a phone. Okay. Now, keep your hands up if you're using web page test for testing on real devices. Oh, I like you. Some of you are liars. And keep your hands up if you use Chrome colon inspect over USB to do real on device debugging. Okay, who's done it more than once? Okay, that's what I thought. It turns out that DevTools emulation is nothing like real devices. Network throttling, CPU throttling, they're all kind of a fudge. They're better than nothing. Please use them. Please set them on by default. Please use them all the time, but they're not the real thing. Not even close. Let me give you a quick example. This is the IO 2015 website, which was a Polymer 0.5 progressive web app. It was super bleeding edge. It had push notifications, which I think we had launched in Chrome like the week or two before. There were bugs. It was amazing. On desktop, it felt super fast on this wifi connection. We get DOM content loaded and a meaningful paint at about 700 milliseconds. Onload isn't far behind, and that starts a nice swooping out animation, which is smooth most of the time. Overall, we spend about a half a second in script, which is well under our budget for actually getting a good responsive experience. And we get interactive content in about four seconds, including that long animation. This is a really great experience on a desktop-class device, which is to say my MacBook Pro. This is the same site running on the same wifi network on a Nexus 5x. DOM content loaded doesn't show up until two seconds. Onload triggers at the six second mark, which is where that animation starts. Part of that delay is down to this huge honking scriptive valve. That's locked up the main thread for nearly two full seconds. Script execution balloons up to four seconds in total, and for all of that work, we still don't even get smooth animations. Look at all those long frames. Content doesn't become interactive until seven seconds. This is what TTI will tell you in Lighthouse, and this is not acceptable. Ouch. So what have we learned? Traces from real mobile devices are a harsh master, and when I show folks their apps on real devices, most have the same reaction. And in fact, I do this a lot. They're shocked at how slow the median mobile CPU actually is, not the iPhones in their pockets. They don't really understand the difference between desktop and mobile disks in storage, and most of us are super ignorant about how crazy mobile networks are in the real world. I think we theoretically know at some level that they're bad. It doesn't begin to cover it. They're so bad. It's important to understand the depth of the deficit, though, so we can start to adapt. I've been letting out down a bunch of engineers for the last year, hard, soft. I've just sort of been easing them into this sort of grief curve, and then hopefully we get out the other side, and it goes well, but you have to put in the work. But unless we do that work, unless we change the way we're working, that web won't work for the next billion users, not practically speaking. So something I say in basically every meeting is that the truth is in the trace, and by that I mean dev tools and Chrome tracing attached to real devices. Nothing else cuts the mustard. It doesn't get you there. So this is what's sitting on my desk on a typical day, and aside from the Pixel XL that's on the right hand side, all those phones are less than $300 new. The folks at Conga report that the most commonly used phones in their market are in the sub $100 range new. I carry most of these phones around in this bag. This bag is in my bag, my other bag, with me all the time, and these are some slow phones. And I carry them because I have zero faith that anything I trace in Chrome on the desktop is gonna be like the real world unless I've put it on a phone and emulated 3G. And we'll talk about 3G. I don't trust that unless I've done it on real hardware. And you know what I also don't trust is the marketing numbers from phone vendors. So here are some of the headline specs for the devices that are in my bag. All these devices have flash-based storage. Naively, there's no reason to think that script should run 10 times slower on my Nexus 5X than it did in my MacBook Pro. Especially if I looked at these headline numbers, 2.8 gigahertz versus 1.8 gigahertz. That's not a 10X difference. Naively, there's no reason for that, right? If we just looked at these numbers, we wouldn't really understand what's going on. It bears repeating, if you think the $700 iPhone in your pocket is what people are going to be adopting in the next couple of years, at the median, you're delusional. The average selling price of smartphones is going down, not up, because the next set of people who are going to buy phones are not replacing their current phone. They're buying a new phone for the first time. And all the rich people already have smartphones? The next billion users aren't buying high-end devices. They're buying at the margin. And that margin is a cheap device. Worldwide, phones are getting slower. So is the average network connection. Your test device needs to represent that reality so that we don't wind up building what Bruce Lawson has called the Wealthy Western Web. So this is MotionMark. It's a benchmark that Apple put together earlier this year. And it tests a bunch of graphics performance, but it's various JavaScript bound in many cases. On apples to apples hardware with Safari and Chrome on running the same version of OS X, Chrome ties or beats Safari in most cases. Basically, this is not something that we're actually slow at. So here's the same benchmark on the same version of Chrome on an XS5X. The desktop version is 25 times faster. For a slower than XS5X is, I was able to change just one thing and get the MotionMark benchmark running 15% faster. 15% for one change. What the heck did I do? Is it magic? We're all adults here. So I think it's safe to admit that magic isn't actually a thing. Instead, I used a little bit of science and I added this makeshift ice pack to the bottom of the phone. I got this idea from my colleague Victor who's been looking at optimizing this benchmark earlier in the year and was seeing massive variants across runs. What the heck is going on here? Going back to basics, Recall the computers are basically just a bunch of wires. Those wires have resistance and voltage and power are running through them, which means they dissipate heat. And we dissipate some more heat every time a transistor flips from the on state to an off state or vice versa. That same process generates computation but it also generates XS wattage in the form of BTUs. So a chip built on the same process with roughly the same architecture with the same number of transistors that dissipates more power and turns it into heat is the chip that does more math. And doing more math is how you go faster. When it comes to computing, power is literally power and power equals heat. So these are the guts of a regular desktop class machine. The chip in there is a slower version of the one in my laptop. The square fins on the top of that thing, they're the heat sink. And the job of the heat sink is to evaporate or sorry, dissipate the heat coming off of the chip. Now that heat sink is seated on top of a metallic top of the assembly for the chip with a little layer of thermal paste between it. So there's no air gap. That air gap would cause a thing that would explode and break the chip because it gets so hot. There's a fan that's running over the entire box extracting all that heat that's getting dissipated out. And the result is that a desktop class or high-end laptop chip like this can dissipate something like 60 watts under load. This is what 60 watts looks like. I don't know about you but I haven't chosen to hold 60 watts or my hand is spitting more than once. And the key, this is the key reason that mobile phones don't run as fast as desktops or laptops even if they can include as many transistors or scale up to the same frequencies. These chips in these packages just can't dissipate 60 watts without burning your hand as Taylor said earlier. So let's look at inside the guts of one of these phones. This is the remains of the Nexus 5X that I use as my daily phone for a couple of years. It gave up the magical blue smoke and stopped booting a couple of weeks ago. So now I get to dissect it. And unlike desktop class machines with a GPU and the memory might be on different sections of the board or different boards entirely, the whole system on a chip lives under the other side of this and that's that thing there is the power supply. On the flip side of the same PCB is the entire system on a chip. It's got an aluminum cover like this, sort of a heat spreader. So when we flip it over, this is what you see. There's no thermal paste, no fans. I took the shield off, but that's all. In fact, the CPU module isn't even visible on this board because it's sitting underneath that Samsung made RAM chip. Think about that. To get heat off of this CPU, it has to go through another chip and then through the casing of that chip, then to air, then to a thin aluminum thing to maybe spread some of that. And then out what? The screen? The two layers of polycarbonate plastic in the back? Two layers, separate layers, I'm not even connected. Remember that polycarbonate plastic dissipates heat 1,000 times less efficiently than aluminum. If you can't evacuate the heat, then you can't really generate a lot of it without the core temperature rising to levels that damage the circuitry. And then the magic blue scapes, smoke escapes and you phones out spooting. I wonder what I did to mine. So chip designers saw this coming. They've been putting dynamic voltage and frequency scaling into chips for more than a decade. And more recently, they've started enabling features that allow OSs to turn off cores entirely. All this reminds me of this paper that I read a few years back from 2011. If you have some spare time, I recommend it. Well, perhaps not intended to be, it reads like a prophecy from half a decade ago about the experience that we're all carrying around in our phones, where a huge percentage of the silicon in our devices isn't actually available to be used thanks to the power and thermal constraints. And the power thing is real. There aren't any heat sinks in your phone, although I'm pretty sure that you wouldn't want a heat sink and a fan in your pocket. But imagine if you could have one. Why don't those exist? Why can't I get a bulky phone? The basic reason is that this battery only contains 10 watt hours of power. Think about that in terms of the light bulb. You'd only be able to keep it lit for a couple of minutes if you had to, if you could drain the battery that quickly, which you don't because doing that causes batteries to explode. So just don't try. Just FYI, not a fun experiment at home. This is why mobile phones are slow. We can't dissipate power because we can't carry power. That battery has to deal with all sorts of stuff. It has to deal with the CPU and the GPU and the Wi-Fi radio and the Bluetooth radio and the NFC radio and the cell radio and the screen and the touch digitizer. It has to power all that stuff and keep you satisfied for a day's worth of use on a single charge on something that can't keep that light bulb lit for more than a couple of minutes. So to keep from wasting power, there's a lot more complexity in modern phones. Most of them today use what's called a big little architecture. And that means that they try to move work from high power cores to low power cores very aggressively. The systems that move that work around are called schedulers. All kernels have schedulers and the Android ecosystem schedulers are a bit all over the map. The big thing to understand about them though is that your phone probably isn't using what's called symmetric multi-processing. That is to say, not all of the cores respond up to the same voltage and frequency running at the same rate all the time. There are different levels. Most of the phones that you probably have have something called a global task scheduler which moves work around between those things. The systems in Linux that wind up doing that management, that work management are notoriously hard to tune and they use all sorts of heuristics to do it. Some do something called touch boosting and what that means is when you put your finger down on the glass, they power up the big CPUs in anticipation of you doing some work like animating something or flinging it around. Some of them have special heuristics for launching applications so that when you launch something from the home screen they power up the big core so that thing launches very quickly. Now, that looks nothing like the web workload. The web workload today looks like tapping on the URL and waiting for the network. Maybe those cores got scaled down again and then your content comes in and then we start processing it. Basically, the web is fundamentally not aligned with the way mobile phones have been optimized to work because our workloads don't look like their workloads. Lastly, remember that light bulb? The light bulb is why you shouldn't believe any of the numbers that really you see in benchmarking, right? The idea that your mobile phone CPU is as fast as a desktop CPU may be true in the limited case but not in the common case. You're gonna get scaled. You're gonna get throttled. Things are gonna move to a low power state as aggressively as possible. That's not how the world works. We don't keep things spun up the way we do on desktop. So here's that chart again but I added the details of the CPUs. It looks a lot different now, doesn't it? I don't even gonna get into the details of the huge differences that come from caches and pipeline depths and in order versus out of order dispatch and memory bandwidth but all of it matters. The TLDR is that you actually get what you pay for on a mobile phone. Importantly, the MacBook Pro packs 100 watt hour battery. That's the FAA maximum limit that you're allowed to carry in a single battery onto a plane, design constraint. But as a result of having that much power available and because the heatsink and the fan and my MacBook Pro I can keep those four cores spun up under load and they can dissipate something between 40 and 60 watts. All the phones in the chart are big little devices and that means that many of the cores are powered down most of the time. That Moto 4G at the bottom has eight cores but if you get more than three of them working for you at any point in time, you are really lucky. Right, so mobile CPUs aren't exactly what you thought they were, I mean, since when would a hardware vendor ever use an opaque number to mask a major difference in performance, right? And okay, maybe memory pressure and smaller memory footprints on mobile devices don't allow us to, on the browser side, trade away space for speed as aggressively as we do on desktop and maybe the storage systems are roughly as fast though so maybe we could get something back there. I mean, they're just solid state flash devices on a Linux OS if you're running Android, right? Who has heard of the term MLC flash? Okay, I think it's like 10 people. That's about what I expected. MLC flash is multi-level chips. Basically, they are chips on top of chips inside the same chip package and that is how you make storage cheaper. And it's a primary reason why my Nexus 5X gets 400 megabytes a second of read throughput and my MacBook Pro gets two gigabytes a second of read throughput. In SSDs, the way you get better performance is parallelism. In order to read or write a block, you want to distribute reads and writes for large reads and large writes to as many different chips as possible because the latency for getting data to and from each of those chips is constant so you have a controller in front, it's got some memory and then it distributes that work out to those chips. Now, physical space is at a premium on mobile devices but so is power so vendors have tried to consolidate those chips as far as possible and that means that they're using fewer and fewer usually one chip for all that reading and writing and that means low parallelism which means low performance. We don't get that benefit that my MacBook Pro does of having many chips in a row on a mobile device. MLC flash is also just now slower and file systems haven't really caught up. Basically, what you should think about the median mobile phone having is spinning disk from 2008. Think of it that way. That's probably a pretty good parallel. Okay, that's kind of a bummer, right? Spinning metal. And if mobile disks make you sad, the state of mobile phone networks will make you wish that mobile disks were the problem you actually had. If you hadn't, I recommend checking out Iliy Grigorek's high performance browser networking. It's free, you can read it online and it goes over a huge amount of the total end to end networks stack that gets bits from your server to your phone. Highly recommended. If you spend some time with it, you'll get to where I got to which is that mobile networks hate you. Cell networks are basically kryptonite to the protocols and assumptions that the web was built on. Where TCP and the web was built around the assumptions of a relatively stable underlying transport condition, cell networks gyrate wildly and from millisecond to millisecond. Where TCP assumes relatively constant packet loss and constant RTT times, cell networks deliver anything but transitioning from one network type to another or one subtype to another in real time. And where the web's model of hot linking subresources assumes reliable networks for the duration of the page, well, we kind of know how badly that breaks down in practice, don't we? At least those of us who use public transport or ride in cars or basically use phones. So this paper is actually a pretty good entry point and especially its references into why these networks hate you so much. And they do, they hate you a lot. When you dig in, it turns out that what's really killing you is the variance and the volatility and the underlying network substrate. Now, some of you might be thinking, isn't LTE gonna save us? Well, yes and maybe. Here's last year's performance for US LTE users compared to the year before. These networks are actually getting slower. In fact, the variance in mobile networks is so massive that it feels like a farce to call something 2G or LTE. Some of the largest emerging markets have median RTT times north of 400 milliseconds. When you open DevTools and you do network throttling and you put it in the regular 3G mode, it says the RTT to 100 milliseconds, which is part for the course in the US, but wildly wrong in other markets. Especially when you think about how many carriers wind up throttling things even further down. The same network type may mean dozens of different things for your users. For the TCP gigs in the house, thinking about what that sort of around chip time does to the bandwidth delay product can really bring you down. Channel capacity be damned. That sort of latency eats your transfer speed for breakfast. But of course, this is mobile, so it's worse than that. As Ilya said to me recently, a 4G user isn't even a 4G user most of the time. Cell radios are magical things. Sure, they try to preserve power too though, and they seamlessly transition between their high power states and their low power states. Across different radio types, different cell locations, they do a ton of work to make sure that we never see what's happening under the covers, but that creates variance. When users try to connect, their phones might be in a low connectivity or a low power state when they weren't just a minute ago. In those cases, the radio resource control protocol that Ilya's book goes into some detail on determines how the connection gets made. For users in very low power states on 3G connections, it can take seconds to just start the radio handshake at the physical layer so that you can start transmitting data. If you wanna get bits on screen in three seconds, you're in a really tough spot. You can't do DNS, TCP, TLS, or even start sending those HTTP headers down the wire until all of that is complete. Now consider adding hundreds of kilobytes of JavaScript to the mix. That's not theoretical. The HTTP archive is showing that the top 1,000 sites put almost a megabyte of uncompressed scripts on their pages today. On those networks, on these CPUs, this is a recipe for disaster. No wonder users have the pervasive feeling that the mobile web is slow. I think it's only reasonable to be sad about all this. The tools and techniques that we've brought over from the desktop era really aren't serving us. To make great progressive web apps, we need to do things differently. We need to load less code. We need to load it at the right times. And we need to let the browser do work for us whenever possible. Use the platform isn't a nice to have. On mobile, it's the only way to go. Sam's gonna go into a lot more detail about the depth of the crisis that we're in, but make no mistake. If you're using one of today's more popular JavaScript frameworks in the most naive way, you are failing by default. There is no sugarcoating this. Except for the tiny club of fast enough to slow by default tools like the Polymer App Toolbox and Preact with some good webpack foo. Today's frameworks are mostly a sign of ignorance, or privilege, or both. The good news is that we can fix the ignorance. So when we're armed with data, we can make better choices and avoid those slow by default tools. Now, I talked to a lot of teams who've gotten a long way into their PWA development story and they've got very heavy clients by JavaScript apps. Their apps feel like Gmail, basically. They get a loading bar or something like it while a ton of script starts to execute, and then they get a fast UI. All the subsequent interactions wind up being fast because they've paid all that cost up front, but many developers find that this is kind of slow. It feels slow to use. Once everything is loaded, it's great. But as we saw earlier, JavaScript execution on phones makes this strategy kind of a loser. JavaScript execution is single threaded. Sure, we can parse and compile off thread, but we can't use the preload scanner to grab some resources if they're embedded in that script. We can't speculatively build DOM or parse CSS or apply it. When you go with one of these tools that doesn't use the platform well, you bet the farm on a single core, on a phone that might be thermally throttled or in a low power state. Good luck. So, what we're seeing now is something called server-side rendering, AKA isomorphic rendering, AKA universal JavaScript. I haven't looked in a couple of months. Is there a new term for this? I'll take that as a no, okay. So the idea is to run JavaScript on the server the same JavaScript on the server that you run on the client and then send down a pre-computed snapshot of the HTML that you were gonna send. And then you load the jargantuan JavaScript bundle and hope that it all works out. On my MacBook Pro or an iPhone with a fast connection or my Pixel, something like that, this works out pretty well. But for the vast majority of users with less expensive phones or less good connections, you get this crazy uncanny valley. When the JavaScript arrives, the main thread locks up all the same. Until it starts executing and finishes, the content might be displayed, but it isn't meaningfully interactive. Now there's a debate that starts. Some folks think that because maybe you can start scrolling this stuff because browsers are magic and they do threaded scrolling and scrolling actually is an interaction. If I can't put my finger down and tap on your UI and have it start responding and doing work for me under 100 milliseconds, it isn't loaded. It's broken. Okay, all right. What we really want is progressive interactivity. And this is what the purple pattern that Sam will go into delivers. The insight here is that you should only load the code that you need right now if possible for the views that you're actually sending to users. And combined with service workers and HTTP to push, it's possible to achieve this without overbundling. Purple in the Polymer app toolbox represent what's possible once we take that mobile by default thing seriously. And it's night and day from where most popular tools are. So this is the shop app that you've seen before. The Polymer team released it at IO. You can visit it right now at shop.polymer-project.org. And here it is running on a desktop browser. We get to interactivity very quickly on Wi-Fi and it only takes a few hundred milliseconds of script overall, you know. So what? We've seen this story before. But what about mobile? Again, Nexus 5x, same Wi-Fi connection. Despite this lower CPU, the app sends down an appropriate amount of script so that we get interactive performance at under two seconds. There's nearly a second and a half of script execution overall, but thanks to the granular use of HTML imports and HTTP to push in contrast to major bundling, most of the components load with tiny execution slices, which means that the content that's already on screen stays interactive. This is what mobile first looks like and it's radically different in a good way. The other thing that the purple pattern adds is a service worker. You might be thinking that service workers are about handling offline and while it does allow you to do that, that's not the primary benefit for most end users. Service workers matter because they let you deliver reliable performance because they can handle the top-level resource and always return something from the cache. You can dramatically improve the performance of your apps when you use service workers this way. That huge variability in network conditions, it evaporates when you've done this. So this is a chart that Eric Biddleman gathered from this year's IOS site. It's also a progressive web app, but with Polymer 1.0. But as you can see from the giant dark green spike, when the service worker is active, the distribution of load times moves hard to the left. And that's a good thing. This is very literally what faster looks like. I'm seeing a lot of teams try to add service workers as some sort of transparent pass-through thing using a network-first approach. Don't do that. Please don't do that. Use the purple pattern and make sure that your top-level app shell never depends on the network. If you do that, you can compete with native apps on the experience that you deliver. If you saw Darren's keynote this morning, you saw exactly that with the keynote tech, the CNET Tech Today PWA. If you don't do that though, you will never match their performance. Until recently, it's sort of been difficult to verify in an automated way that your service worker is installing and that the rest of your progressive web app properties are actually met correctly. You've heard a lot about Lighthouse, but please put it in your CLI, put it in your continuous integration system and let it tell you how you're doing. So I think it's safe to say that mobile is much, much harder than we've collectively understood it to be. To make good apps in this environment, we need to change our outlook, our tools, and most of all, our priorities. And the fastest way I know to get in touch with that, that ground truth is to test on real hardware. So please, if you don't already have a circa 2014-ish Android phone, go ahead and buy something like a Moto G4. If you can use one of these and Chrome Inspect on DevTools, you'll find yourself in touch with how it really feels to be at the median. If you can, get something worse. Like this is an Android one from last year. You probably can't buy one, but get something worse if you can. And if you can't afford any of those, please use webpagetest.org to select from the list of real mobile devices that are sitting in a rack at your disposal to test your URLs. And whatever you do, implement as much of the purple pattern as you can. Sam will fill you in in the details, so stay tuned for that. And lastly, Lighthouse and Chrome Telemetry are potent weapons in your ability to not regress on keeping sure that you're doing the right thing. I wanna apologize for being a bit of a downer today. Usually, I'm telling you about how good PWAs are and how great the experience is that you can deliver. And that's all true. And there is good news, and that it's that modern web technology makes it possible to build truly amazing experiences. But it will require ditching or radically reworking the way that we're using these slow by default tools. Addy's got a whole talk tomorrow about what kind of elbow grease you really do have to put in if you've bought into one of today's major frameworks. But no, I think now that the challenge is much larger than you probably thought it was. Now that you know, I'm actually very confident that the folks in this room and on the live stream are gonna internalize this and use it to make really great experiences. So thank you. I'm pretty sure I did promise he was here to cheer you up before he came out. I feel really sad. No, I was the backstage going, no, no, no, no. I want to touch the light bulb now. Are you? The whole point was you're not supposed to touch the light bulb. I did actually do that once as a child. I even remember being, it's one of my earliest memories sat on my dad's lap and seeing the light bulb and thinking, ooh, we're gonna touch that. And then my dad was like, no, Jake, don't do that. And then it's like, well, give it a second go. And he stopped me again and said, no, Jake, that's gonna really burn. And I remember watching him until his head was turned away and thinking, oh, got him now. This is my chance. This is my big chance. Bang, burned my hand to pieces, big blister to hospital. So that's you and Alex in the same boat. Yes, we've made the same bad life choices. Good to know. Good to know. Well, it looks like the quiz is available. Let's see if we, oh, here it is on the screen. Okay. Oh, thanks. Well, thanks to the fantastic AV team for restoring our quiz. It feels like it's been a while since we've done one of these. It has. Right. Okay. Ready? First question. Everybody on bigwebquiz.com? Bigwebquiz.com. Let's go. Let's launch into our first question. What does the following JavaScript lock? I'm not gonna read that out. No, because I can't take you. Promise.resolve.net. See that code? Does it log one, two, three? Three, two, one. Two, one, three, four. Not sure. Maybe. Maybe. I mean, so what we've got there? We've got some promises going on. We've got an async function. Oh, set time out with zero. Zero. Interesting. That's kind of like set immediate in some contexts. So what we're seeing here. Interesting. Well, there's a lot of confidence in one answer. Not being like, who is voting for that one? I'm pretty sure I know what it is. We have comedians in the house. I know. Four. Some people just don't want the muck, right? Is it not on big enough price? That is a shocker point there. So here we go. But then across the rest, it's pretty equal, isn't it? Let's close it. Shall we close it? So 38% of you said two, one, three. That was the most popular answer. Only just though, isn't it? Equals on three, two, one, and one, two, three. Shall we take a look? Oh, yeah. Let's see what the correct answer is. Two, one, three. So people are very pleased with themselves. So how is this actually working? Shall we take a look? So we've got promise.resolve that then, now, any promised reactions are going to queue a microtask. So that's what's gonna happen there. An async function, I mean, it's obvious to me that an async function will run synchronously. But that is what happens. That is true, yeah, well, wouldn't it? It's not awaiting anything. It's not awaiting anything? It's very much like the promise constructor also, also run synchronously. And then we've got a set time out which use a task. Microtasks happen before tasks, and then there you go, two, two, one, three. Fantastic. It's easy when you think about it. Makes me wanna cry. Yeah. Okay, now, backstage, you know, I remember from the intro this morning that we were wearing tuxedos. Yes. And we didn't feel comfortable in tuxedos, but management felt that we might wanna reconsider that option and we've been discussing it with them. Well, they've been pointing at Alex and saying quite smart and saying, maybe just up your game. Could we represent the company a bit better? A little bit. And so we said, look, you know what? We're gonna put it to you. Ah, okay. So this is a poll, it's an unmarked question. Would you like to? Now, we are relying on you here. Should Paul and Jake wear their tuxedo suits tomorrow? Yes. Or no. It's just one of the select one question. This is a select one, it's not a multi-select. Well, it's looking quite good. It's looking favourable in one direction, my friend. Yeah, sorry, it's 7427. This is where we find out whether they like us or not. Are we ready? Two, one. Right. This is the worst polling result in almost two days. I don't know what to do. I think we know where we stand with you. So I think the only thing left for us to do is to introduce Sam. Sam's gonna speak to you now. Bye. Big round of applause to Sam. Maybe we left too soon. Yes. Oh, hang on. Sam, is this a miming talk? Oh, it's one of his... Oh, with a... This is more of a statement about web performance like Alex was saying. We're waiting for him to boot up. That's what it is. It's like his calls are in low power mode. He's downloading his talk. It's just... I really don't like suits. And yet... Thanks! This will be... I mean, aside from the small intro video that we filmed, this will be the first time I wore a suit where someone's not getting married or has died. Because that's... I just look like a failed bouncer, you know? That's what I was like. I was just like, why am I even... I was really hoping I was gonna look like a spy. And I was just looking in the mirror and went, you look like an idiot, so... By the way, how do I smell OK? Because we filmed the intro a couple of days ago, and for continuity, you know, we had to wear the same stuff. The same stuff from there, so it's kind of... It's into the second day of T-shirt wearing, especially with all the lights and stuff. I did wonder. So, we should have got you out with a saxophone again. No, I think we've all done that one. So, I am now, like yourself, a glasses-wearing person. Indeed. Not wearing them now. I noticed. As you can see, I'm not wearing mine. I'm glad we have this chat. But when I was getting my eyes tested, the optician, they'd go through the series of questions. Yes. Like, are you as well? Is it better, worse, or just the same? Well, this is before all of that, before the better or worse. Well, they have a look around your eye first, right? Well, this was just stuff like, do you smoke? Do you exercise regularly? And then she threw me an absolute curveball. She was like, what are your hobbies? And I panicked. Because I was like, well, I reset web standards, but the problem is that I ended up being my job, so it's no longer a valid hobby. And I just went, I played a piano. I mean, at least it's not verifiable at that point. Well, that's why I was worried about it. Did she ask you to do air piano at that point? Well, I was worried. I was like, oh, well, we're not going to use the normal charts then. Here's some sheet music, if you could just read me what notes are there. Interesting. I'm really good. I play by ear. I play many of their sheet music. Apparently, I discovered, because my kids had their eyes tested, they know if you lie to them, because when they look in your eye, they know what your prescription is, then after that, when they're going, is it better, worse, or just the same? They're just double checking what they already know. Why would you lie in an eye test? Well, do you not have a... I want... No, no, no, no, no. I want better glasses. I want to see into the next continent. I want to win the contest against the optician. Like, can you see that, yes? I can. You can't? Oh, you should get glasses. I have glasses. So, no, I like winning. So, maybe I'm thinking about this all the wrong way. Well, I'm still at a stage where I can't wear them when I am actually sort of walking around. Do you fall over? Yeah, it's kind of like that feeling of like, you know when there's an escalator that's not working? Oh, that's horrible. Yeah, on the London Underground, we have lots of escalators, but none of them work. I think the first escalator... Those are stairs. Yeah, well, exactly. This is the progressive enhancement story, right? Right. I think it was 1917 that they kind of... they ran the first escalator on the London Underground, and they've been trying to do that again ever since. Repeat that fluke. Exactly, yeah. And you feel like you're moving really fast when you stand on it, so... Did not know. Hmm. How's it going over there? Performance books. OK, good to know. So... We could abandon them. Oh, no. We could. Is there any chance we could get another quiz question in? Oh, we could do another quiz question. How about... Can we get a smile from Miles? Miles, hi. Could we do another quiz question while we're here? Is that a possibility? I mean, we've got lots of questions. Yeah, we've been having loads of fun writing these. I thought we were just going to have to keep talking nonsense. We might still have to. We might. It'd be exciting. Oh, Paul, let's have a look at some of these. What do you think we can... Should we go for this one? Yes. Yes, OK. Sorry, it's fun because we can see the browser window sort of scooting around in front of us. Oh, we've got another plug to go in. That's fine. OK. Feels good. What have people normally said? Is everyone enjoying themselves? No. Oh. I think that was a no. That was a very polite no, wasn't it? Are you enjoying yourselves? Right, here we go. This looks good in front of us. Right. Yes, OK. Right, so if we can get that on the screen, that'd be amazing. Can we get the quiz? Everybody heads a big web quiz. OK, here we go. Right, next question. Is it really... But it should be working. This continues to be the best day of my life. That's an active question. Interesting. Keep talking, Paul. Yes! Another question. I don't know why that was right. Here we go. Well, people should have already had that on their phones, I imagine. Oh, yes. How many times does the ECMAScript spec explicitly mention JavaScript? Is it zero? Is it one? Thirteen or ninety-three? Yeah, the ECMAScript spec, of course, being the thing that the JavaScript is based on. That is ActionScript and JScript. ActionScript. Yes, you're an Xbox developer. I am. Now, 53% on one of the answers, 36, 6 and 5. So two more popular answers there. Should we lock it in? We lock it in. Two, one. Zero. I'm thinking quite the low numbers, 50% on zero, 38%. Oh, the correct answer is... Oh, somebody's gone to the URL and gone. I was surprised. I thought it was going to be more than one. Yes. Yes. Shall we do the other related? Let's keep going. Let's go for... I quite like my JavaScript. Is there one like JavaScript or structuring? Because I do. Yeah, let's do that. Here we go. Next question. This is on destructuring one of the new ES6 features. What is the result of the following? Logs world? Logs undefined? Frozen error. Keep your answers in. Do you want to try to just copy and paste the text on there into the console? Yes. Yes. I might have seen one down there. You feel suitably ashamed? Yeah. Okay, so we've got some very confident answers. Oh, it's dipping. Dipping though. 44. 44. There's confidence going down on that middle one. Lock it in. Nice. Just by logging worlds, that's the most popular answer there. But it's just behind error. The answer, of course. Of course. Of course. I totally knew it before I put it into the console. It does throw an error. So this is it. You're not passing an object in. It tries to destructure that object that doesn't exist. Error. Error happens. Indeed. These questions kind of come as a pair. Let's do it. Shall we do the other one? Yes. Interesting. So interesting. You might recognize the curve. What is the result of the following? Logs world? Logs undefined? Both throws an error. Same answers as before. Interesting. Is it the same correct answer? That's the question. The clarity there in the middle. That's 15%. Is that thing? Did they give us two questions that both throw an error? What? It sounds like something they would do. It does, doesn't it? Yes. Let's lock it in. The most popular answer is logs undefined. Interesting. And the correct answer, once it makes its way onto the screen. Logs undefined. Smart audience. Good work. So what's actually happening here? Well, so the object has a default value of the object there, hello world. But because we provide a different object in, it doesn't use the default. So hello never gets set at all. We're going to go to Emily. Okie dokie. So we've got a slight change in the schedule there while we figure out some of these technical issues. You said schedule. I discovered it's schedule here, I believe. Yes. My son corrects me because I go home and I say schedule and he goes, don't daddy. No, it's schedule. It's not like school, you go to school, did you? So our next speaker, here to talk about security, is the Queen of the North, I believe. Emily Stark. Emily Stark. I'm Emily. I'm not going to stall you anymore. So hopefully you're happy about that. Welcome. I hope you're enjoying the first day of Chrome Dev Summit. I'm an engineer on the Chrome security team. And my colleagues and I on the security team are on a mission to be honest with the people using our software about their connection security. And we need the help of you all, the developers in this room to do that. The first way that I'm going to ask you to help us out is to do a little thought exercise where you put yourself in the shoes of an average web user. So probably not a developer, maybe someone who is even new to computers or new to the web. And if you were this average web user, looking at this omnibox, which is what Chrome shows when you visit an insecure, plain HTTP site in Chrome today. If you were this average web user, what might this omnibox say to you? You can see it kind of has the host name of the site, and it has this sort of neutral informational icon, right? So if you were seeing this, what would this mean about the site that you're visiting? As an average web user, you probably wouldn't realize that an attacker sitting between the web browser, between your computer and the web server, can read any data that's passing back and forth between the two of you. So that could be sensitive data like passwords, credit cards, health content, all of this stuff. You probably don't want an attacker sitting between your computer and the web server to read. Or as an average web user looking at this omnibox, you probably wouldn't realize that even though the omnibox says example.com, that's not necessarily who you're actually talking to. Over insecure HTTP, you don't actually have that guarantee at all. You could be talking to any attacker who's impersonating example.com. And that's probably pretty unintuitive to the average web user who looks at the omnibox and sees example.com. And finally, this average web user probably wouldn't realize that any attacker sitting between your computer and the web server can modify or tamper with content that's going back and forth between them. That tampering could be to inject ads, perhaps overriding your legitimate ads. It could be to insert some fake or malicious content. It could even be to trick the user into downloading or installing malware. So if this was your site, with this attacker modifying or tampering with your content, this is obviously very bad for your users, right? They're probably getting a poor user experience. They might even be being tricked into downloading malware. And it's bad for your site. It's bad for your brand. It's bad for your revenue. You're not delivering the legitimate good user experience that you want to deliver. And these risks are real. They happen every single day in coffee shop Wi-Fi, internet service providers injecting ads, software like Firesheep that makes it really, really easy to passively sniff on unencrypted session cookies. These things happen. They're real. They're probably affecting your users. And the way to protect your users from that is to use HTTPS. These risks are why we on the Chrome security team are on this mission to fix this UI, which we don't think is being particularly honest or forthcoming about what it means to use in secure HTTP. What we plan to do in the future is not this sort of neutral presentation, but a presentation that actually delivers a warning to the user, the risks that they're taking by using in secure HTTP. So in this talk, I'm going to tell you about our mission to get to a place where we can use this warning UI to be honest with our users about their connection security and how and why you as developers should help us with that. I'm going to be telling you about some newly released metrics about the honest state of HTTPS usage in the world today. And those metrics will hopefully help motivate why and how you as developers should help us move the web to a place where it's HTTPS by default because it's good for you and your users, it's good for your site, and it's also good for the web as a whole. And finally, I'll be previewing some upcoming Chrome UI changes that illustrate our strategy, which is to gently prod developers like you into adopting HTTPS while simultaneously kind of using our users into the idea that HTTP is probably not what they want to be using. In the spirit of honesty, I'm going to start by telling you about a section that we added last week to the Google Transparency Report. The Google Transparency Report, if you haven't seen it before, is a collection of all sorts of interesting and useful data about Google and about the internet as a whole. And for most of this year, we've had a section on this transparency report that's devoted to HTTPS. Very interesting data, but up until now it's mostly focused on HTTPS usage at Google, so on Google services, Google traffic, and also on some of the top sites. Tracking this data has been pretty encouraging. Since we launched the transparency report, the HTTPS section of the transparency report in February, we've seen 12 more of the top sites adopt modern HTTPS. But this is not necessarily the full picture, right? Because what are the top sites? What does that actually mean for people who are using Chrome every day? That's why last week we released a new section in the transparency report that releases data about HTTPS usage as Chrome users see it. One of the milestones that we passed recently, as you can see here, is that on desktop platforms, Chrome users now load over 50% of their pages over HTTPS. This is a big milestone, and overall we're pretty happy about the trend here, which is that HTTPS usage, when we look at that as percent of pages that Chrome users load, slowly but steadily increasing. That's what we want to see. Obviously we want to see faster increase, but slow but steady, we'll take it. Another way to look at it is not the percent of pages that are loaded over HTTPS, but the percentage of time spent. And as you can see from this graph, this is an even more optimistic way to look at it, because Chrome users spend on desktop platforms about 75% or more of their time on HTTPS. We don't necessarily know why this is for sure, but one way you can think of it is that users probably spend more time on sites like Gmail or Facebook or you're super engaging for rest of web apps than they do when they're just Googling around for some information, like a link navigating away. So we think that users spend most of their browsing time on sort of heavy-duty apps that, for the most part, are top sites using HTTPS. I also want to make a quick note about Android usage, which you might have noticed in both of these graphs is this green line. It's kind of an outlier down at the bottom. Again, we don't know why this is for sure, but one hypothesis we have is that on Android, this sort of serious web browsing on Gmail, Facebook, things like that, that stuff that Android users are doing in apps. So from Chrome's perspective, they see more of the non-HTPS traffic and less of the traffic that tends to be HTTPS that Android users tend to do in apps. So again, that's just a hypothesis, but we think it kind of makes sense and it means that as the mobile web becomes more and more engaging, as you all build and gain traction on your progressive web apps, we would hope to see this line kind of continuing to go up and hopefully catch up with desktop. This is great news. Developers like you are adopting HTTPS. You might be wondering why. What is driving this slow but steady increase in HTTPS usage? And we can't tell you for sure, but I want to pull out a few things that we hear over and over again anecdotally from developers who are transitioning their sites to HTTPS. First, modern browsers like Chrome and Firefox and others are restricting usage of powerful features over insecure HTTP. Some features have already been deprecated and are already not available over insecure HTTP, and some will be restricted in the near future. So these are things like geolocation, service workers, push notifications, the payments and credential management APIs, all sorts of things that you've heard about today that you need to build a progressive web app are increasingly only available over HTTPS. So we're not doing this to be mean. We think it makes sense, and that is the best thing to give our users more control over their privacy and devices and data. And I think this is easiest understood with an example like geolocation. Because if a website wants access to my location and if I grant them access to my location, then I'm giving them information about potentially where I live, where I work, where I shop, where I go to the doctor, what I do on my weekends, all sorts of things that is pretty privacy-sensitive information for a website to have. And that may be fine. I may be perfectly happy sharing my location with some website, but I can't really make that a meaningful decision unless I know which website I'm talking to. And that's exactly the guarantee that HTTPS gives you, which is why we are increasingly restricting access to these privacy-sensitive, powerful features, unless the user actually knows which site they're talking to. As I said, Chrome is not the only browser doing this, and just one other example is Firefox. In this blog post, they actually announced that they're eventually planning to require HTTPS for all new features. So this is something that browsers are pretty much united around the hope that it makes sense that if you're going to grant access to privacy-sensitive information or a powerful feature, the user should know which website they're granting that access to. We think this is one of the drivers behind HTTPS adoption because we hear it from developers. One example of this is the BBC, which cited these restrictions on powerful features as one of the reasons that they decided to move bbc.co.uk to HTTPS earlier this year. Another consideration that we think is behind the slow but steady increase in HTTPS usage is that HTTPS performance is getting better and better every day, and it's no longer kind of the bottleneck that it maybe once was 10 or 15 years ago. What you're seeing here is a website built by one of my colleagues, Ilya Grigorik. It's called isTLSfastyet.com. TLS being the protocol underlying HTTPS. So the answer is yes, but that's not just what this website tells you. It tells you about all of the performance improvements and enhancements that are coming out every day with HTTPS, and it tells you how to configure your server with them and which servers support them. So it's a great source of information about HTTPS performance. I want to draw particular attention to HTTP2, which is the next version of HTTP, and offers a whole suite of web performance improvements, but it is critical in this talk because HTTP2 is only available if you're also using HTTPS. So what we hear from developers is that in the case that they do encounter some performance hit when they move to HTTPS, it can often be offset, more than offset, by the performance advantages that they unlock using things that are only available over HTTPS like HTTP2. These are some of the things, these restrictions on powerful features, the improvements in HTTPS performance, these are some of the examples of what we think is driving this slow but steady increase in HTTPS adoption. But while things are moving in the right direction, we still have a gap to close, and we need your help doing that. We need your help by adopting HTTPS on your site so that we can get as close as possible to HTTPS everywhere. And we need that, we need to be as close as possible to HTTPS everywhere if we're going to get to the place we want to be where we're honest with our users about connection security. My point here is that if we were to tomorrow turn on this warning state that we want to have where we do this kind of scary red dangerous warning indicator on insecure HTTP, if we were to just turn that on tomorrow, it would probably be a little bit counterproductive. Users would see it everywhere, they'd see it all the time, they'd learn to ignore it, they'd have to ignore it to kind of use the web, and they'd kind of get trained to basically just not see it. So that's not what we want. We want it to be the case that insecure HTTP is a pretty rare occurrence. So rare that when the user encounters it, we can show them this warning and they will pay attention, they won't be scared or confused or habituated, they will see it, they'll pay attention and they'll understand the risks of the situation that they're in where they don't have any guarantees against attackers reading their content or injecting malicious content or any of those risks that I talked about at the beginning of the talk. So that's what we're asking of you. We're asking you to adopt HTTPS on your site. It helps you and your users and your site and it also helps us in our mission to make the whole web more secure, to make users more educated, and to make their activity on the web less of a risk for them. But we know this is not always easy for developers. It can be overwhelming, and that's why we at Chrome and at Google and in other organizations are mobilizing a lot of support and investment around helping you transition your site to HTTPS. One of the organizations that is becoming critical in this movement is called Let's Encrypt. Let's Encrypt is a certificate authority. A certificate being a cryptographic proof of identity that you need in order to use HTTPS. It's the thing, the cryptographic proof that proves that your site is who you say it is. If you say your example.com, you get a certificate proving that your example.com, and that's what gives your users the guarantee that their browsers are actually talking to the real example.com. Historically, getting certificates has not always been easy, and it's not always been free. But thanks to the work of organizations like Let's Encrypt, it's now possible for you to get a certificate very quickly with no money, and they also provide easy command-line tools for automating the management and renewal of your certificates. So we think this is a critical part of internet infrastructure going forwards. Chrome has made a large donation to Let's Encrypt, and users are funding it as well, because it's becoming such a core reliable part, a core part of their, the process of running a web application that they've come to depend on. And in case you don't believe me that Let's Encrypt is here to stay, I think you can see it just in the numbers. This is a critical part of internet infrastructure that is really going to change the way that people do HTTPS. It already has. It's internally a little bit more at Chrome and at Google. One of the ways that HTTPS sometimes worries developers is ad revenue. And if you haven't heard about this concern before, it might seem a little bit random. What do ads have to do with HTTPS? The connection is that when you move your site to HTTPS, you have to move all of your content, all of your third-party resources, including ads, in order for your site to work properly. So developers are often worried about having to move their site to HTTPS, needing to move all their ads to HTTPS and therefore losing ad revenue from ads that are only available over HTTPS. To help alleviate this concern, all Google-sourced ads are already served over HTTPS. So when you move your site to HTTPS, you will not have a revenue hit from Google-sourced ads because they are already available over HTTPS. And this is backed up by developers in the wild, the Washington Post moved to HTTPS recently and saw no hidden revenue from their Google-sourced ads. Another Google service that people sometimes worry about when moving to HTTPS is losing search ranking. Because anytime you make a large change to your site like this, you should make sure you follow the proper steps to make sure you minimize the disruption to your organic search traffic. These are some of the questions that people have. How to move their site? Do they do it all at once? Do they do it a little bit at a time? What kind of fluctuation should they expect? And more technical aspects of the move, like what do they do with robots.txt and their site maps and how do they tell Google that they're moving to HTTPS and all those sorts of things. What we're doing in this space is expanding and improving upon documentation. And we really like to hear from developers about what their questions are so that we can answer them publicly. These two FAQs, I recommend to people all the time. There are just lists of questions that people have with very straightforward practical advice answering some of the questions I had on the previous slides. And we also have a web fundamentals guide that walks you through the process of setting up and configuring HTTPS performance tuning, things like that, and also has a section on how to handle your transition from the perspective of Google search ranking. ENAT was able to move to HTTPS with, as you can see, minimal disruption to their search ranking. So we are hopeful that we've improved the documentation to such an extent that if you just do a little bit of research and follow the steps and the documentation that we provide, this isn't a traumatic thing for your search ranking. It really shouldn't be nearest and dearest to my heart. And I could spend a whole talk talking about web platform and browser tools that we're building and sometimes standardizing and evangelizing in other browsers to help developers like you move to HTTPS. These are things that I work on pretty much every day, and I just want to give one example, which is the DevTools security panel. So if you move your site to HTTPS and you open it up in DevTools and you go to the security panel here, you'll see that it's designed to basically help you figure out if you've done it right. If you have any problems, if you've made any mistakes in your transition to HTTPS, figure out what they are and tell you how to fix them. These tools are ways that we at Chrome and at Google want to guide developers into using HTTPS on their sites. But simultaneously, we're planning to start easing users into the idea that HTTP is bad, because we want to get to eventually a place where enough developers are using HTTPS that we can really warn users when they have a lack of connection security on insecure HTTP. And we don't want to just jolt them into that world right away. We want to kind of ease them into this association between HTTP and bad. This is the new UI treatment that we'll be using for some insecure HTTP sites in Chrome 56, which goes to stable in January. So you can see we're still doing kind of the neutral informational icon, but we're adding the not-secure text to start to educate users about what it means to be using insecure HTTP. And we'll be specifically launching this for HTTP pages that have passwords or credit card inputs on them. So our goal here is to use passwords and credit cards as a signal that the user might be in a particularly sensitive situation in which they want to be particularly careful with their data and in which it's especially important to warn them about the risks of insecure HTTP. So this feature is still in development, so I want to stress that it's subject to change, but you can go try it out in Chrome Canary today. And we would love for you to do that, both to report bugs, to see what it's like browsing the web with this feature on. I find it really interesting to see what it's like a glimpse of browsing the web in the future. And also to try it out on your site and see if your site will have this UI applied to it, if you're not using HTTPS yet. So to do this, you just go download and install Chrome Canary if you haven't already. Go to chrome colon slash slash flags and find this mark non-secure as flag and flip it to the option that says something about passwords and credit cards on an HTTP page. So if you do this and then you go browse around the web or browse around your site, you may see that we're doing, as I said, we're detecting when a password or a credit card field appears on the page and using that to trigger this not secure warning from your users. So we really encourage you to try this out. Try out your own site if you're not using HTTPS. And if you find that your users will see this not secure warning come January, maybe you want to start using HTTPS by then. Our hope is that this does help incentivize developers like you to move to HTTPS and also starts to sort of build the association in users' minds between entering sensitive data and the lack of security of HTTP. Fortunately, it's not just about negative indicators. We have sticks and we also have carrots. If you download Chrome 55 beta, we're already using this secure chip for sites that are using HTTPS. So it's not just that you'll get a not secure warning if you have a password or credit card on HTTP. If you adopt HTTPS, you get this shiny green badge next to your site and the user is that, hey, you are using a secure connection. So we hope that this provides some incentive to adopt HTTPS in addition to all the other benefits that you get, like the privacy and security benefits for your users and the ability to use powerful features like geolocation and service workers that you get with HTTPS. So that's the glimpse of the very near future. These secure warnings for secure sites and starting to show not secure warnings, which is closer to the honest truth about HTTP for some sites in Chrome 56. But this is where we're going. We hope to get here as soon as possible to a place where the web is as close as possible to HTTPS everywhere, so that we can be fully honest and truthful with our users about what insecure HTTP means. One of the things that we're considering doing in the future is sort of gradually picking more and more signals. So in Chrome 56, it'll be passwords and credit card fields. Maybe in the future, it might be something like when the user is in incognito mode or when the user is downloading a file over HTTP, things like that, more and more signals to kind of gradually make an assumption that the user is in a potentially sensitive situation and warn them more and more aggressively about the insecurity of HTTP until we get to the world that we want to be in. The theme of my talk today has been honesty. The new transparency report metrics show an honest picture of the world when it comes to HTTPS usage. It shows that we're moving in the right direction. We have a slow but steady increase, but we need your help closing the gap by adopting HTTPS on your site, which we think is good for you, for your revenue, your brand, your user experience. It's good for your user's privacy and security, and it's also good for the web as a whole, the whole ecosystem, by helping us get to a point where we can be fully honest and truthful with the people using Chrome about their connection security. Thank you, and enjoy the rest of the summit. I'm not sure. I'm not sure. I am. I am. I got the sound. You don't. Oh, that's good. That's after a good start. Hey. Hey. Can you hear me now? No. Yes. Good. Hello. So this isn't Jake. Technically, it is actually time for a break, but what we thought we would do if you want to get a drink or do whatever, we're going to do some live coding, which never goes wrong, obviously. Challenging the demo guards is always a good idea. And you see how my day's gone in terms of bugs. So, Serm is going to be doing the coding. And what we're going to be doing is we're going to be adding a service worker to a site. And the reason we wanted to do it was to give everybody an insight into just how to think about the problems of putting a service worker onto a site. So this is in the theme of a YouTube show that we do about once a month, which is called SuperCharge. Yes. And we have been building things before, where we have built a router, where content is being XHedArt in and you get a nice animation when you do navigation to a different site. And we're going to use that and make it offline capable. And that, stay. Stick around. We're just getting set up over here on the AV, as you noted. So, how... Oh, they're still going. So, the kind of things you should be expecting from us today are things like async await. We're going to have a take a look at... Oh, yeah, we're going to use... We're on. Oh, we are on. Perfect. Here we go. Let's roll. Now, if you've got any questions during this, you can go to the Chromium Dev Slack and you can ask them in the main chat area there. I'm going to be watching that and I'm going to interrupt him. So, he can basically forward your questions to me and probably make me more do mistakes. Yeah. All right. So, let's get started. So, what you see here is the thing that we have built a while ago. It is a website with no really... with no important content, but you get nice animations when you go to a different site. And as you can see, we are only requesting a partial, which is just a single line of HTML that is being swapped in and all the rest is JavaScript and transition magic. And this is what we want to try to make work offline. Oh, somebody went full screen. That is not good. Let's not go full screen. So, the first thing that I'm going to do is I'm going to register a service worker and because I'm a fast typer, I'm done. You cheat. You big old cheat you. So, what I usually start with is a string for a version. Wait, wait, wait, wait. Go back, go back, go back. So, you've got a... Right. If service worker and navigator, let's talk about that just a... That is progressive enhancement. Right. So, basically it checks if the navigator object has the service worker call and if not, we're not going to do anything. If it does, we can actually register a service worker. So, we don't register the service worker. We tell the scope, you're going to control everything from forward slash. You're going to control every request. Everything. Yes. Right. As you were. So, version string I usually do because it is a nice place to force a reload of the service worker. So, the service worker file is going to be checked if it has changed, if it is byte equivalent. Correct. It is not going to be reloaded. If it's something changed, a whole new service worker is going to be spun up. So, a version string is a very nice place to force this kind of behavior. Now, good news. If you set far future caching on your JavaScript files, at most the spec says you're going to wait 24 hours before Chrome, or in fact any browser that supports service workers will go and try and get a new version of your service worker. But you could be stuck with the service worker version for 24 hours. So, typically on a service worker, you want to make sure that you're serving it. For example, today, we changed the schedule of Chrome Dev Summit. If we had been stuck for 24 hours on the same service worker, that would be awkward. Bad. Right? So, there we go. So, the first thing we're going to do on install basically always looks the same for me. I usually do a skip waiting in here, which means sell.skip waiting. Type O. He caught me. So, we're not going to wait for SoC shutdown. We're going to take over immediately, which is also what we have to do in activate. Okay. So, let's talk very quickly about the life cycle. So, when a service worker is downloaded, it goes through an installation step. I think Sheik wrote a really good article about that. Yeah. I mean, there's a brand new article on developers.google.com slash web slash fundamentals, I think it probably is. It's probably on fundamentals. And I'll find it and I'll post it into the Slack in a moment. But basically, it talks through the life cycle. But in the short version, you have an installation step. When a service worker is finished installing, it will activate as soon as any, as soon as it's able to, which largely involves any connected clients they're called have disconnected and it becomes available. Otherwise, you have to wait until they've all disconnected. You've got on install. I'm not going to skip waiting. On activate, I'm going to claim all my clients. So my new service worker is active now, but it hasn't taken care of all the open tabs if you have multiple ones. Self clients claim says, give me all the tabs that they are and I'm going to take care of them from now on. Okay. So if you've got an existing service worker, you're just basically kicking the old one out immediately and saying, I'm the new one. I will handle everything from this point on. Exactly. Okay. And for the on fetch for now, I'm just going to say, I'm just going to do a a not service worker basically not going to do any offline logic, just any request the page does. I'm going to do the actual network and pass it back. So if we reload this site now, we see the service worker just got installed, which is good. And now on reload, we should see every request twice because the website does a request for example, the SC view file, which gets to the service worker and the service worker does the actual fetch, which is why it also shows up down here. So everything is still working the same, but we have a service worker now in between our website. So it's really worth pointing out this, that little cog there is the thing you're looking for and also if you have a from service worker, that is good things to watch out for. But you are seeing that two steps. Something went to the service worker, the service worker did a fetch and then it comes back. So a pretty common way is to download the files that you know the user is going to need on install. And that's exactly what we're going to do. So we're going to define an assets array and these are the files that we need. Dude. Boom. You're like, today you're like the king of snippets, aren't you? And I was like, how long has this taken you? And he's like, I've practiced and I can do it in like 11 minutes. I didn't realize it was all snippets. These are actually the two snippets I have. You're done with snippets now because it's boring tidying this out, I thought. There's no semi-colon at the end of that assets declaration. Well, it's not technically wrong. It's just... Awkward. If the linting was switched on it would have a problem. Now we're going to do interesting. We're going to write async function. Oh, yeah. Which now everybody knows will run synchronously. Exactly. From the quiz. Until I do await and do cache's open static. Right. Now you've got to explain what's going on here. Exactly. So async function just think about it as a function. It is actually a function we're trying to promise. Just that we're on the same page. We're blocking it by saying it's an async function. Because only inside async functions we can use await. And we want to do that because it's cool. And that means that this function actually returns a promise. So everything in here will basically be kind of rewritten into a promise chain but it's so much more readable now. Okay. So we're saying we've got an async function. We're saying open the caches and... So usually you do like a dot then afterwards and you get the cache and then you can do something like you can actually just await it for it. And this is the same as a dot then but puts it into a variable which is... So it reads like synchronous code. Like I want the cache and then I want to do something else and something else but under the hood it's magically doing sort of promisey type stuff. So the next thing is another await where we can do cache add all assets. So this step is going to wait until we have downloaded all the assets in our array put it into the cache and then we will return skip waiting ultimate value of this promise that the async function returns is going to be self skip waiting which is what we want to pass into wait until because we're done without setup but before that all the other steps are going to happen and we can check this works by reloading the page because now the service worker... Oh! Remind me I'm going to write a lot of async functions if I forget these two parentheses at the end shout because it's a painful to invoke this function right away. Ew! So let's do this again. Sorry that was involuntary. So service worker and we see now it downloaded all the files again. Which reminds me when we do these it's not production code. I'm not saying you're writing by code. Awkward. There is a sense in which we do this stuff to kind of show the approach that you take this isn't necessarily stuff we'd say just take this copy paste and you're good to go. Yeah. That is important. It's worth mentioning. So now that we have things in our cache we know that everything from our static folder is going to be in our cache 100% because we are downloading it on install. Okay. And this is what I want to take advantage of in our on fetch. Well can you can you go back and reload the page and then show them the cache inspection in DevTools. Really useful. So at this point we should have all these assets in the cache, right? So we have the cache storage and we can go and have our static cache and all the files are in here. This is really useful to see if everything actually landed. Can you show the response? No you can't. Okay. I still don't know why. I don't know what this this thing is. They should say okay but it just doesn't like you right now. I am in canary because async functions are only in canary so there might very well be bugs right now. Okay. But you normally see you normally see the fact that it was an okay request kind of came through. So if I have something in static I don't even want to bother with going to the actual network because I know I have it ready. So something that I kept finding what sort of doing is actually parsing the URL. So event.request.url is the request URL but it's just a string. I actually want to have it separate into like the query part, the path, the domain and all these kind of things. So I am just going to attach a new thing to this URL object because what I can do now is event parsed URL path name starts They don't add that to the spec you are going to feel really awkward. A little bit, right? So basically what I am checking is if the past name starts with static I will give it some special handling namely I am going to respond with a cache.match event request. So I am looking at the cache for the request object and going to respond with it and I know it's going to start and when we get a fetch from the page that says I want whatever URL hopefully we are going to find it if the URL starts with static we go find it from the cache we are pretty confident and we should be able to return it. Otherwise we are going to stay with fetching for now. So what should happen in our network tab is that all these server cycle requests should disappear. So I am going to reload once which is going to trigger a version one as well. That bottom request there is the service worker trying to do an update for a new version trying to find see if there's been an update. Checking if it's byte equivalent or not. So you will see that kind of going the service worker looks for the new service worker so that's normal. So for the rest right now if there's a request for something that we don't have in the cache for example our index HTML it goes to the network and just gives it back to the browser and then it says how many is it? Five. Five assets. If I request something that's not in there we go and fetch it but then we just kind of it's if we're offline we wouldn't have it for next time. Exactly. And that's what we're going to change. And I like to write functions for the different caching strategies. So in this case I'm going to do a stale while revalidate. Revalidate. There we go. So what this means is stale while revalidate means if we have and in the background fetch it from the server and update the cache. So we see this typically on social networking sites where they kind of go here's all the posts that I've got stored. Enjoy those. Meanwhile I'm also going to go off and get the latest set of posts and when I've got those I'll update my collection for you. So one nice thing about the strategy is that we're definitely going to do both. We're going to do fetch and we're going to do check the cache so we're going to somebody's asking on the chat and if you're not in the chat and want to join in is the chromiumdev.slack.com and it's we are in the general channel and somebody's asking if the code is going to go on to github totally the answer is yes we have I will post the link in the chat if somebody else doesn't get there before me we have a UI elements samples repo which has the whole all the elements that we've built all the stuff we've built so far for you to look through and this will be no different so it will be in there I might clean up a little bit afterwards some comments just to remind you what I was actually doing because I'm not going to write comments now like who does really come on so we have two things that we can do now first we have to figure out what to respond with and this is something that I want to give to you in respond with try to get to the response as fast as possible and nothing else caching you can worry about and wait until so we have event respond with and event wait until so respond with expects a promise that resolved the thing that is going to be given to the browser as the response to the request so for example you could respond with the fetch and a fetch is going to return a promise which will ultimately result in the content of the thing that was being fetched which is a response response object wait until however keeps the service worker alive if you want to do some further work twice the service worker might get killed before you actually save it yes now this is an interesting part of service worker work is that they there's no promise given or no I shouldn't say promise there's no guarantees given that a service worker won't be spun down okay so once say for example you've loaded the page even if the tab is open it can be spun down if so once someone has reloaded the page the browser is well within its rights to say I no longer need this service worker but the dev tools says now that service worker termination by a time out time I was canceled because dev tools is attached so it was going to shut down the service worker but because dev tools is attached it said I'm not going to do that in case you want to inspect what's happened in case you just want to have a look at the service worker because when you log an object from the service worker you can't expand it anymore if the service worker has been killed because the context is gone so it's just a thing to do which in this case I assume is going to be putting things into a cache well in respond with no in respond with you're just going to worry about what the response is so our response in this case is going to be a promise dot race because whatever we have the fetched version or the cached version I just want to return whatever is there faster so promise dot race is a function that takes an array of promises and gives back whatever promises settles first okay so okay so you've got a fetch you've got a look in the cache you're going to say don't care pick one whichever is faster most of the time I would expect that to be the cached version yes however if we are offline fetch rejects and promise dot race doesn't care if it's a reject or a fulfill it will turn whatever settles first which includes both so when we're offline fetch is almost immediately going to throw and be like I'm offline and can't do anything so the cached version is going to say okay here is your rejected promise have fun which is not really what we want so what I do in this case is I'm just going to put a little sneaky catch to the fetched version and say if you're going to reject just turn into the cached version too nice that is well cheeky sorry I'm totally stealing that so what's going to happen now is I now we have to think about this can be a response but it can also be undefined which is what caches dot match returns if it doesn't have anything in the cache so in this case what I'm going to do is if the response is not valid so it is undefined I'm going to return the fetched version so this covers all the possible outcomes because you also have to think about there is a way if we are actually online the cache could and then we want to wait for the network so at first glance what appeared to be quite neat and tidy you're kind of going right fetched and cached but if the fetched version decides it's offline and we'll switch to the cached version but if the cached version doesn't work out for whatever reason we'll go to the fetched version yeah and now it gets everybody following along there's going to be a pop quiz actually doing a pop quiz we might actually have a quiz question damn nobody's going to because when we're offline it's going to reject so there might be a way that cache response first with I got nothing see Matt go on who's one of our colleagues he just says I was just sick in my mouth go on T I'm going to get back to him now so what I'm going to do now is fetch could reject so if that happens if we're down here and fetch reject we know nothing's in the cache and we're offline there's going to be a new response offline with nothing to say 4-4 done oh that's such a grown way of doing it I know I just be like I am German okay I would have been like yeah I don't so let's comment this out for a second reload the page get the new server server any errors looking good looking good 4-4 on the local host what did I do wrong no now at this point I would try well what was I doing I find n I was doing I just body heard of the rubber duck theory yeah few hands going up if you've not heard of it the idea is that you have a rubber duck on your desk and when you hit a bug you introduce yourself to the rubber duck hi I'm Paul here's my problem and as you explain your problem to the rubber duck in this case Duck is enough to help. How's it going? 31. Cashed with a D. It's a bug. It's a typo bug. See, I think if you'd had linting on you, you'd have got that. Me, me, me, me, me, me. Yay! A plus. So, everything should totally still be working. We're still fetching everything. We're not putting it in the cache yet, so let's fix that. We have this thing done, which basically does the right thing. Just believe me. I do. I'm just... OK. And now we're going to talk about the caching. This one is actually simple. So, what we're going to do is we're going to wait for... Is it semi-simple? No, it's actually... I'm looking at the other one. So, we're going to wait for the fetched version. We're going to wait for our fetch. We're going to open our cache.caches.open. I'm going to call this one dynamic because we're... We had the static stuff. This is the stuff that we're kind of going... Oh, we didn't have this to begin with. So, maybe, for example, this would be where you'd store your posts. The stuff that changes over time, right? Maybe use a generated content. Incidentally, if you're taking this approach, make sure that you have some kind of purging strategy. Otherwise, your caches can grow forever more. Hashtag topical. There you go. So, you want to make sure that you have a way of getting rid of old stale data. So, we wait for the response, we wait for our cache, and then we put the response in the cache. Done, almost. So, as I said before, the fetch can reject if you're offline. So, we are just going to catch that error and just... Not do anything about it. And also... Wait, did I miss anything? Hey, you weren't grown up anymore. Oh, I'm so proud of you. Okay. I'm so proud of you. So, this should be working, right? Or not? Oh, no. We have actually something subtle, which is why I almost forgot about it. So, let's imagine this. The cache got nothing. That means that our response with returns our fetched version. And then we get into a wait until and we want to store our fetched version. So, we're using fetched version twice. Ooh, ooh. I know this one. That doesn't work because the body of a fetch is a stream and you can only consume it once. So, what we're going to have to do is we're going to have to do a fetched copy. So, this is the same as the fetched version, but the response should be cloned. And then down here, we can wait for the copy instead of the fetched version. Okay. So, let's reload and see if this works. Reload, new server tracker and another reload. So, we can still go to about. We can still go to contact. All good. And now, let's go to the applications panel and go offline. Reload still works. About, cool, contact, cool. Misk is not going to work because we haven't visited Misk just yet. So, this is just going to put up our great spinner. Okay. So, what we would want to find a way to kind of handle that one nicely and be like, sorry, can't get this offline. Maybe. Not today, though. No. I mean, it's almost like you're saying with time constraint that I keep interrupting you. It's almost like it's revenge for me for all our other shares. What doesn't work, though, is that we cannot refresh here. It just doesn't work. No. Because... You've all got errors as well. Well, yeah, because I just... An unknown error. It's great. Oh, okay. So, in the dynamic, we have the root page, but we only have the partials for about and contact. So, that's why we can only refresh while offline on home but not about and contact, because we don't have the complete page cache just yet. Yeah. So, a bit of background for you. When we made this originally, each individual page, we served the whole thing. And then, on the updated version, we only pulled in the bits that we actually needed for the XHR so that when you go from home to about, we only pull in the little bit that was needed. And so, what we're saying is that the thing that's caching, it's only caching the changed bit, rather than if you refresh, it goes, well, I haven't got the full about page or the full misc page. So, we need to figure that one out. So, what we're going to do is, and this is where it actually gets exciting, we're actually going to do the templating and the source work right now. So, we're going to pull in our header partial, our footer partial, and do the assembly of these partials in the service worker. The same thing we built on the server side in the server side rendering episode, we're going to put that into the service worker. So, the first thing that we need is our partials. So, I'm just going to sneakily put those in our static cache, which is header.partial.html and also footer. Just so you see what these look like, they're just partials, the start document with a little bit of, this is the wrong document, but it's similar. Let me check where it is. There it is. It's just basically the top of the document and the bottom and we put our own content in between and there's a little bit of templating magic, which we're also going to take care of. So, now we have the partials in our static cache and now we need to figure out when is this request for a web page, for one of our top level pages instead of any assets or other links we might add later. That seems like something that doesn't have partial on it and would have gone to the dynamic cache. We solved this when we built the backend and we have this great regex that does this. Hang on, are you sure you don't want to just reuse the code in the kind of isomorphic way? This is almost what we are doing. Almost? Almost. And I'm not going full isomorphic because I think isomorphic has the flaw that it assumes you have note in the backend, which sometimes, or maybe most of the times, is not the case. So, we're going to, when you want to do templating in the backend, choose a templating language that has multiple language bindings. So, whatever you use in the backend, all right. So, on the fetch, we're going to see if our top level section regex matches our event parse URL path name. And if that's the case, we can call our function that we are about to write, which is going to build the site. If not, we're going to use the existing code that we just wrote. So, we are going to write build site, which is going to be interesting. So, event respond with, what is going to happen in here? Obviously, we're going to use an async function because they're nice. And I'm going to do these because I'm going to forget them. So, the first thing that we need is we're going to need to get a hold of our files. So, the files that we need are caches.match, header.partial. So, again, those from the static cache. Because we know they're there. The footer. And in here, we are going to basically use our stale-wire-revalidate function more or less with the event, parsed URL to string, plus partial. Got you. So, you basically, okay. You need a comma after that one. I do. So, actually, that's, and because both caches.match and everything else is going to be a promise, we are going to wrap this in promise.all. So, this is good, but if you paid attention, you know that stale-wire-revalidate doesn't actually return a promise or return anything. So, what we're going to do now is basically we are going to use this function and write a little wrapper around it that actually returns a promise. And this is one of the nice and yet ugly things. No kidding. So, stale-wire-revalidate. It's so hard. Request. So, this is the request URL, and this is going to return, for all we know, a... A promos. A promos. I shouldn't mock you. I make so many typos when I'm typing. It's embarrassing. And there I am being unkind to you. And I never mock you for it. And yet you... I'm just unkind, aren't I? Yeah. I feel pretty bad about that. Pretty much. So, we're going to call our old function, which takes an event. We're just going to build our own event now. We're just going to pretend to be an event object, even though we are not. Because the only things of event that we're using inside the stale-wire-revalidate function are a respond with wait until and request. Wow. So, our request is going to be a request. Because, interestingly, both fetch and cache take both request objects, but also strings. Huh. So, this will just work. Great. Our respond with is going to be our result function. So, that means whatever this thing... You can see where I'm pointing it on my screen. Yeah, I was going to say... I'm a genius. Yeah. Well, this thing... So, whatever this thing is going to be passed into respond with, which now is the result function of our new promise, which up here will give back the value. And also, we need the actual wait until. So, we can't really create that. So, we have to pass it in. So, wait until. So, we have to put event, wait until dot bind event. Ew. However, it's going to get better. Because... I'm never writing a service worker again. Service workers are hard. So, the thing is... Your service workers are hard. Mine don't look anything like this. Mine are really like... And they don't work. That is true. They... So, the thing is something that just got fixed. I'm so sorry. I'm going, I'm going. I'm done. The thing that just got changed in the spec, but it's not in the browser, is that right now, you can't call wait until inside respond with or the other way around. Okay. You can only do it at the top level in the same tick that the event got dispatched. So, we are going to have to do our own wait until. And what I found out is a kind of dirty hack which I'm just going to use until this change lands. I'm going to put a new promise into wait until and just save the result function on a variable and just use that instead. So, that means that the service worker will now stay alive until the my wait until will be called and all the browsers should be happy even though we are technically calling a wait until function, even though it's our own inside respond with. The last thing I want to fix here is that we are appending partial to the string, but that isn't technically always correct because this might already be a partial request. So, that it would be question mark partial, question mark partial, which we don't want. The good thing is that we already have a parsed URL, a URL object which has search params. Oh, not catalog. Search params. And we are just going to set partial. So, that means if it's already set, nothing happens. If it's not set, it will add the question mark partial to our URL and we will always get the partial thing. Okay, so it's okay. We got our files. We do. The last thing we are going to need is actually get the contents out of our responses. So, our contents are the files, and of all of those, we are going to get the text. Okay, so you are making this request, the header, the footer, the actual bit in the middle, and now you are mapping that by saying, okay, will each one of those get the text for each of those? Exactly. However, text is a response. So, once again, we have to put this in a promise.all. Because, again, fetch resolves when you get the headers and the metadata, but then the body is a stream. So, dot text basically returns a promise and reads the entire stream, puts it in a string, and gives it back to you. So, now we have the contents. Our content, the thing that we are actually going to pass back is the contents joined because it's just three strings and we are going to concatenate them. And then we are going to return a new response with our content. So, this is basically how we do the templating inside our service worker. So, let's reload this. We are going to get the new service worker in, or not, but I missed something. That shouldn't stop it from working, though. Thanks, though. Offline, you checked the offline box. No, I did uncheck it here. Oh, that's an interesting bug. Usually those are synchronized, but apparently they're not. Thank you. So, let's... I got that. But it's still not working, is it? Okay, I'm just going to unregister my service worker because something is clearly iffy here. Stop. It does happen sometimes when you use Canary. Oh, there's like three service workers installed now. We should be on the safe side. Ah. Ah. Interesting. So, as you can see... That's exactly what it is. So, the default MIME type of response is text plain, which is really not what we want. So, in our response, we have to add headers, content type, text HTML. Reload. New service worker. Reload. Hooray. But, nothing works. Which is expected because I didn't do the templating. Oh. So, I still have my template expressions in here, so now we're actually going to load the templating library. Oh, if we use handlebars, right? I don't anymore because handlebars turns out to be like 80 kilobytes, and I found a nice little... a little library called DOT, and... Well, it is DO capital T, so I don't know how to pronounce it. DOT. All right. And this is one of the bits where I say this is our production code, because in this version... The line keeps coming up in the chat, by the way. People really clarify what we mean by it's not production code. So, I basically exposed the entire node modules folder. Yeah, why don't you? Why not? You don't do that in production. Please don't. But, in this case, it's just the easiest way and you don't have to actually think about the build steps in the background, how I'm actually bundling this or whatever. And also, I'm not doing any cache cleanup. So, if you actually bump the version, you're probably going to run into problems because old files might still lie around. So, there's definitely things that I'm just skipping over for sake of brevity, and because this is already complicated enough. Okay, so this is what I was saying earlier about the purging of caches. You want to make sure that... Cache invalidation is hard. Yeah, but it is definitely worth doing. Is it because we said service worker enough times? Yes. If you say service worker three times in the mirror, it's been really difficult at some conferences because I've just been whisked to the other side of the planet. I've just come to let you know that we've got a conference to do and there are other people who would like to talk. Fine. How close are we to the end? How close are we to the end? Actually, let me think. Where was I at? Oh, the templating. Yeah, it's literally two lines. Here we go. How long has it been literally two more lines? Well, it would have been done faster if you didn't... So we're going to take a template function. Our template takes event.request. We're going to reload. Oh, that looks okay. And now it should go back to normal. We're done. And now the test is to go offline. Really? We go offline. It still works. We can reload on all the sub pages because we're offline. It still doesn't work because we never went to the page. That's fine. And I'm done. Great. That code that code will get a lot of comments and will be pushed to GitHub and we will post the link in the Chromium desktop. And if you have questions, at theSerma on Twitter, at erotrist, and you can mostly bug me because he didn't write it and he doesn't understand it. That's true. They're laughing, but they know it's true. All right. Thank you very much. Have a good one. What are we doing now, Jake? Well, Sam's going to give it another go. Oh. We've got a... Is it the same laptop or is it... It's not my laptop. Different poll. Irish poll. No, he's not Irish poll. Let's be clear on this. So you'll notice that Sam's here. We would normally introduce the speaker and then sort of walk away, but we felt this time we would stand and stare. Hang around until something actually goes on the screen and then we'll introduce Sam. Hang on. You logged on that laptop. You know Paul Irish's password. You two are good buddies. I wouldn't share my password with anyone. Are we feeling good? Are we feeling confident? Get Sam drunk enough you'll let you know Paul's password. Yeah. Right? Well, this time things are on the screen in front of me. That's a good sign. That's a pretty good start. I'm ready. You're going to be okay. Come on. Welcome on the stage. He's been here for a while. This is his second time, but first talk. Sam's encoding everyone. Hello everyone. Today I want to talk to you about what it takes to build a super fast mobile web experience. And to do that well, it's going to require us to plan for our performance. Here's my pitch to you. You've all been in that meeting room. When your manager or boss has asked you, well, does this site work on mobile? And you think, well, sure. It's worked on a small screen size on my desktop. And I wrote some CSS, so things scale. So definitely this works on mobile. But that mentality has a flaw. And the flaw is the mobile web is no longer just this subset of the web that you think about at the end of your development. The mobile web is just simply the web. And we see this through the numbers. Mobile traffic is actually outpaced desktop traffic since 2014, and it's only continued to grow since then. So whether or not you like it, the users that are visiting your web app or website are on a mobile phone. They are not on a desktop computer. They are not on the laptop that you're developing on your device. But you as a developer, you're like, okay, that's fine, Sam, because I have a mobile phone in my pocket. Yeah, just right here. Well, I'm just going to test my website on this, and it's going to be great, and I will have accomplished everything that you told me to do. But that's not completely complete. That's not the right approach, but what you have in your pocket is a $600 phone. It's the brand-new phone, because you're a developer and you want the best thing, so you have the best thing. But the phone that your users have, well, they look like this as Alex touched on. These are the low-end phones. These are the phones that you get for free when you sign up for a cellular plan. These are the free phones. These phones have a gigabyte of RAM. These phones have a single core. These are the numbers that back this up. On the average Android device that checks in, they have, on average, a gigabyte or less of RAM. So not great. And this has some real performance implications on mobile websites. Believe it or not, the average load time for mobile sites is 19 seconds. So from going to the URL in your browser, to that actually loading in your phone and being interactive, that's 19 seconds. 19 seconds that your users have to wait. Now, you've seen this graphic before, I'm sure, but it's really important to think about. Because the web that we're shipping today has a 19 second average load time. And the users expect when you just ask them casually, they expect a page to load in two seconds. And most users, if that site takes longer than three seconds, they'll just leave the page. So that web app that you're delivering right now, if it takes longer than three seconds, throwing away half your traffic. Okay. We have 19 second load times. We are shipping experiences that don't match what users want. So how do we align the web that we're building today with what users want? To do that, I think it's important that we take a look at what it takes to load a web page. From when you issue the request to when that page loads in your browser and when you can interact with it. What exactly happens between when you hit go and it shows up? So I've taken the network stack and everything that happens in between and simplified it down, because it's a lot to talk about into three phases. And the first phase here is requesting the page and the server getting that page and then shipping back an HTML document to you. As I've so beautifully illustrated here for you all, this is what it looks like. You go to the website on your phone, it hits the server. The server then generates a document and has to do some processing work to figure out what exactly we're going to send to you. And then it ships that document back to the browser. And don't forget, that request has to go across cellular towers and then find its way through the internet to the computer that's responding and then when it gets it, it has to send it back. And so that round trip cost on mobile phones, it's real. All right. Now we have the document. The server has responded. So the browser has to do some work now. We have to parse the HTML and we have to figure out what exactly is required on this page for us to actually show it. So we have to find these critical assets. And once we've found these critical assets, the browser says, okay, I need this JavaScript file. I need this style sheet. I need these two images. And when I have that, I'll be able to draw something that I'm not sure about. But we have to issue requests for those. And those requests go over the wire through the cellular towers onto the server. The server figures out what exactly we're sending to you. The server then responds back. And all of this takes some time. So all right. We have our high priority resources. We've made that initial connection to get the document. And here we are in my favorite phase. The parse and execute phase. We have the assets. The browser isn't showing you anything yet because it actually has to compute what all of these individual pieces look like when they're combined together. So we have our HTML, our JavaScript, our CSS. The JavaScript parses and compiles so it can actually be evaluated by V8 and Chrome. It runs some JavaScript. Maybe it adds some DOM onto the page. The browser then tries to render. It takes your styles. It calculates where all the positions of all your elements. It lays them out and then it composites any layers. And then you end up with a beautiful page. But this is just the loading phase. This isn't interactive yet. This is just getting something on the screen. All right. Given all that, I think it's important that we take a look at this network phase. If we're going to optimize one layer to start, the network seems like a good opportunity because we're issuing requests to the server. The server has to respond. The server has to respond to requests. And there's a real cost here. So what I did was I took the Polymer shop site, like you've seen today, and I cloned this down locally and I started making a bunch of changes to it. I started out with a pretty simple baseline. I didn't bundle any of my assets. So I have individual assets for everything, not one big blob. I then set up an HTTP2 server and I simulated a 3G network that I tested this on. So we got some real-world sort of metrics. So let's take a look in DevTools how we can get a feel for what this is like. All right. So here's shop on the left and here's our recording that I've done before and saved this off. So you'll notice I have this pane up here, which you might not be familiar with. This is the network view. Network view is usually hidden away and you check this box. And then you see this beautiful waterfall of all the things that are getting downloaded. And you might be saying, what is this gray line? I've never seen that before. Well, of course you've never seen it before because the patch line did yesterday and I have it right here. So what this means is this gray part is we're just waiting for content. We haven't gotten anything. The request went out but we haven't taken any action yet. So you can see that in this case it takes 1,500 milliseconds until we actually get a response from the server and then we're downloading the content. Okay. And then it looks like we issue a request for this other file, this shop app, which is for this site it's sort of their app wrapper, which then has a bunch of dependencies which all need to download, which then have a bunch of dependencies which all need to download, which then have a bunch of... Okay. So all of this results in a paint that takes around 5,500 seconds... or milliseconds. Okay. So 5 seconds, 5.5 seconds for this on a 3G network. It's not terrible. It's nowhere near that 19-second average. So we're starting off from somewhere that's not horrible. However, as a developer we can see like clearly there's some room here for improvement. Yeah. So again, I'm just holding down shift here in the timeline as I drag, I can actually measure how long. So right. So 5,500 milliseconds roughly between when we got our first bite from our server to when we rendered a screen. Now shop paints something pretty quick. We have this frame up here so the shop, but really that's not useful to the user until we actually have content. So this is the first content full frame or the first meaningful paint and this is what I like to measure till. So we see we get these network resources. The browser then executes some JavaScript here just for a tiny bit and then we decide to paint. All right. So HTTP 2, no bundling 3G, 5,500 milliseconds until first paint. Okay, let's look at some techniques that we can apply here to drive that number down. Now I don't know if you've heard of this really cool feature that's in Chrome called link rel preload, but what this does is it allows you as a developer to basically say I know exactly the things that my page is going to need before it's displayed and loaded and so what I'm going to do is tell the browser what those are and the browser is going to see this and say, okay, I'm going to download these. I know you haven't requested them yet, but like I know something as a developer, you're like something is going to request these, so just start. So the browser will download these. They will sit there and so when your browser finally issues a request for them, it's like, oh hey, I already have this, so you don't have to hit the server again. So I took the site, working off of our base with no bundling going on and I looked at all the assets that were required before we actually issued a paint and so I did link rel preload, put it all in the head tag and let's see what the effect of this is. Oh, so this looks quite different. It's now very flat. We no longer have this sort of stepping effect of dependent resources on dependent resources that eventually resolve into a painted page. Instead we just have a flat line of things. It's like, hey network, just grab all these. Thank you. And then when we have them, we end up with a paint. So from our first bite here to when our first contentful frame was, we're down to 3,300 milliseconds. So we've cut out two seconds roughly. Just by avoiding that network work of having to download, discover, download, discover, download, discover and flattening that out. Now you might be thinking, okay but like why would I ever have a site that was daisy chained like that and have all these dependent resources and this is totally contrived. Fair point. But on your site I guarantee that you're downloading fonts. I guarantee that you're downloading JavaScript. If you're taking advantage of some of the new module splitting features of build tools you probably have lazily loaded JavaScript files. And those are all late discovery documents. So what you can do is you can use link rel preload to sort of say hey start downloading these because I'm going to need them. Which can be a real win and in this case a massive win. Alright we're down to 3.3 milliseconds on a mobile network which is good. We're getting closer to that two second time that people want but we aren't quite there. And we still like if we look here we have this cost that's kind of crazy like we have this initial connection cost which is 5 seconds which is insane but then once we finally get a bite we're spending you know essentially 1.6 seconds just downloading this document and we're not taking advantage of the network during this time we're saying give me this HTML document please give it to me thank you I'm receiving it and then once I have it I download more stuff it seems like a wasted opportunity like it'd be nice if we could jam some requests in here as well turns out there is a solution for this a solution is called h2 server push how does this work what is this well it's the basic idea that your page when requested from your browser it hits the server it opens this connection the server as like while it's responding with html the server says I know you're going to need these assets so I'm going to go ahead and push them to you you didn't ask for them the browser has no idea that they're coming but I as the server know the world so here just take them and when you finally need them on the client side well they're already there this compared to the previous approach that we were doing which was two round trips which was get the document scan the document request all of the critical assets and then we can paint so in this case the server is pushing the assets to us it changes who's responsible for what now you're probably like I read a blog post about h2 push and that blog post told me lots of things that were not so great about h2 push and I probably read that same blog post so let's talk about them because it's important to h2 server push it's not cash aware what does this mean well this means that the server doesn't have an idea about the state of your client so if you visited the page before and you have these assets cached the server it can just say hey I'm going to push main.js again because I don't know if you have it and by pushing it the client's unable to cancel that right now and so it causes this network contention and can cause a real cost to your users because you can basically push everything that you want and the browser's just going to take it so not great and can actually slow down your page quite a bit the second is that h2 push doesn't have resource prioritization alright what does this mean well it means that the browser natively is pretty smart about what things it requests because it's able to determine that like this is critical this is not critical I can defer this work and so it tries to optimize for its network activity h2 server push is like a bully it just pushes it to you you don't it's like here just take all of it and the browser's like okay I'll take it so it's not so great but there's a solution for this which is kind of the first P in purple it all revolves around this one idea it's that h2 server push plus a service worker is like this nirvana it's a magical thing because it avoids the big downfall in my opinion of h2 server push so let's step through this so we can understand it on our first load the browser requests to our server the server then pushes the critical assets and at the same time delivers our document our document is then scanned by the browser the browser says okay I need these files go out and make the requests but oh you already pushed them to me so I don't have to hit the network great now on your next load you have installed your service worker as represented by this beautiful green square with the letters SW the page you go to your page but it doesn't even hit the server it hits your service worker the service worker intercepts this request and it says hey I have index.html so here you are and oh you want these assets too well I have them cached as well and what this avoids is you are not even opening a connection to your server so because you have not opened a connection to your server the server can't push you things that you don't need so by combining h2 server push plus service worker you can get all of the benefits of that first load with h2 server push and avoid the majority of the downfalls of getting pushed assets that you already have cached so this is really good so let's take a look at what shop looks like if we actually used h2 push and this is the default thing that the shop site actually uses which is really awesome so here we are we have the site this timeline looks really different so it looks like we are still paying that really high cost here to get our initial page and we are still spending 800 milliseconds or more inside of that initial request and then we see this very interesting sort of representation of what is going on and what you are seeing here is actually the files being pushed to you from the server now these in reality are probably being pushed out here but right now it is shown just right here which is fine so we look we see we get all of these assets that are sort of sticking around they are all marked as lowest priority then we scroll down and we start that wrapper element that root element that shop app html we see the moment that this is finished right here being downloaded we then fire off all these requests but you will notice that these requests are really fast 63 milliseconds 78 milliseconds 62 milliseconds how are we doing that well it just so happens that these are those assets right here when we request them the network says hey do I have this go into the network stack of chrome network stack of chrome says why yes you do here they are in my cache please take them which ends up making for a super super fast experience and we can see from first byte here to when our page actually renders we are under 2 seconds which is amazing so we went from 5.5 seconds to 1.7 seconds and we are now on a 3G network for our initial load with no service worker installed so that's pretty impressive alright what did we learn network takeaways link rail preload what is this good for and when should you use it well it's good for moving the start of downloads earlier during that page parse so the browser parser can instantiate those requests before the browser knows that it really needs it as a dependency h2 push when you boil it down it's good for cutting out one full roundtrip to your server so the most optimal delivery of h2 push is you are going to save at max one full roundtrip and that's important because when you are measuring your site and figuring out where to optimize you want to optimize your biggest cost and so if your latency that exists for a roundtrip is your biggest cost well congratulations because you are in a minority because that is amazing and h2 push is probably your solution alright we've talked about the network cool we know how to get our assets to our browser quickly and how to get that first paint the first meaningful paint pretty quick but paint and that first frame is only part of the story the real interesting bit in my opinion is getting to interactive and the costs for modern websites to get to interactive well it's our friend javascript just sitting there like hey you need to execute me and parse me and on our phones that tends to be kind of slow to understand just how slow this is well we need to look at what javascript deliveries have been like and these are gzip size in november 2010 we were shipping on average 100 kilobytes of javascript pretty good today we're shipping four times that on average 408 kilobytes of javascript on every page load okay so what well there's a cost there there's a cost to shipping this parsed code if we look at some older devices like an iphone 4 nexus 1 our parse time for 300 kilobytes of javascript from anywhere from 300 milliseconds to 500 milliseconds half a second remember users want that page to load in two seconds but you're looking at this and say Sam these are ancient phones this is a terrible graph not applicable to me well remember the phones that your users are actually on are those older devices which are very very similar to these phones listed here but it's fine I understand your concerns because I have a chart for new phones all right four megabyte of javascript because you're shipping all the frameworks all at once on a nexus 5 it's a pretty new phone I like that phone we're at like 1800 milliseconds of parse time iphone 6 with the latest operating system we're at a full second of parse time s7 about a second all right there's a cost here users want it in two seconds you're shipping a megabyte of javascript all that time is gone let's measure this because I can talk about numbers and we can talk about goals but I find it really helpful to take a look at something that represents the real world so I found a cool little app it's a budget app that uses some technologies that you're probably familiar with webpack react, redux awesome, sounds fun so let's load it up here all right, here's our app let's clear this out this is a really good budget app I'm going to say what do I want to buy? cat food great I spent $100 on cat food I got the fancy kind so great I'm really struggling with my guitar and the Trader Joe's food so let's record let's record a profile here and as you've heard today we can enable this CPU throttling which is not a real device but it helps kind of get slower so this is on a MacBook Air yeah sure and we're just going to do a 5x slowdown which should make things slower, not quite a mobile phone and we're going to look at the javascript costs just for the simple site so we'll do a reload command shift R, we record the timeline it comes in, here we are my friend all of our friends really, just this chart okay well what does this mean? well right here we see that we have this bulk of yellow it's goldenrod color actually it's a bad sign it's javascript executing and we're spending this frame 421 milliseconds just handling this so what's our cost here? why is this taking so long? so I click on this frame here which gives me a bottom up view of the javascript here and we zoom in here 140 of the milliseconds is spent in T obviously it's T of course, T oh T, I can't so I'm not really sure what that is but we can find out what T is and looking at this code really isn't useful so I can pretty print it okay great oh there's T, hello T oh I don't really know what this is but I kind of know what it is it's actually the sort of module that the webpack uses but what's strange is this doesn't look like a very expensive piece of code it's not doing anything that's explicitly slow so it feels like the numbers that are reported to me and dev tools are lying to me are not completely accurate this cost is being associated here but I don't think it's actually here yeah so I really think that it's probably parsed time, it's parsing that javascript just from some experience that I've had so we start here, we have this T function but I want to see the parse cost and I know that I could step down into about tracing and click those checkboxes and reload it and then find it but it's hard and it always confuses me so wouldn't it be nice if there was a way that we could see those V8 metrics inside of dev tools I agree well I'm happy to say that in Canary we have an experiment where the metrics are now in timeline which is exciting screenshots are great but demos are better so here we are, let's have a demo great, enable our CPU throttling again awesome let's just reload the page, command shift R wait our 3 seconds okay here we go 4, great good 739 milliseconds that time alright where's our cost oh that's different parse function that's what I thought, parse function compile code lazy, compile full code compile script, function callback these sound like native V8 runtime things excellent alright and we could go into exactly why this cost is there but there's a lot of blog posts that describe how to optimize and this at least gives you a starting point so you can understand the real parse cost of your website okay but parse time that's part of it but you have parse time because you're shipping javascript and so when you're shipping javascript it's really easy with npm just to require everything and then say okay great it works so it's never been more important to actually understand what you ship webpack recently had a plugin released it's called the webpack bundle analyzer and this actually shows you what's in your bundle your webpack bundle and you can explore this tree map and see the gzip size the bundle size everything great about it you can find out why you have three versions of jquery on the page to improve things and then for those of you using browser fi there's a similar tool called disk which has a sumburst chart which is beautiful I'm always so happy when I see this I'm able to find disk size etc same information and understand what you're shipping you're shipping less code ideally but you're still having that parse cost and you have to think well the only way to shrink parse time is to ship less parse code okay well how do I ship less parse code because I'm shipping javascript and I want to be parsed that's a good question well there's two techniques that I like pretty simple to do you know the script tag it always has that type on it when you set source well you can change that type to be whatever and if it's invalid and the browser doesn't know how to handle it it will download the script file for you but it won't do anything it'll just sit there and so you can put type inert type poo emoji it all works you'll get that script tag and then what you can do as a developer is say oh I have some idle time here let me go ahead and evaluate this javascript take the contents put in a script tag this gives you control over when the parse time happens so ideally not at that initial boot up experience now you can also have another script tag where you wrap your code in comments okay so you ship down javascript that's commented out but then when you want to evaluate it you just strip those comments out and then the code is now evaluated so some techniques for manual shipping of inert code you need to avoid that parse cost which is non-trivial alright that seems pretty manual it is wouldn't it be nice if there were ways to do this automatically in my framework of choice and there are the community has been listening and solving these problems for you so it's much easier to do these things Angular 2 actually ships with lazy module loading by default ahead of time compilation so you can do per route javascript bundle downloads pretty remarkable Polymer CLI which built the shop site has per route fragment sharding so it's aware of your page and all of your routes and it's able to say I know that this bundle is going to be for this route and this one is for this other route and so here are these independent bundles that you can download when you feel like you need to the other way is a little more manual but still really amazing Webpack has a plugin called aggressive splitting plugin and it redefines the semantics around require to add require.insure and what this does is it essentially builds a dependency graph of your requires so that Webpack can say okay I'm going to split this JavaScript bundle, this one, this one, this one, this one this one and you get like a lot of JavaScript files but they're great because they're really small and you can manually control when you download them which is so awesome all right so we looked at network we looked at JavaScript and we looked at some of the tools and visualizing it and measuring our cost so what do I want to leave you with well as you've heard time and time again today it is a mobile world it has never been more important to test on real devices not the one on your pocket the one that your users are experiencing your Web site with and it's not just testing on a mobile phone it's also testing on a mobile network You need to go and you need to go get a 3G network and say, okay, here I am on my phone on a 3G network. What does my web app feel like? Is it slow? We should probably fix that. Now given what your users visit your site on, it's critical that you optimize for network utilization by using techniques like service worker, link rel preload, HTTP to push. These things can help you get super fast first loads in under two seconds. And on reload, it's instant because you have that service worker just sitting there. And finally, my favorite, it's a JavaScript parse cost. JavaScript that you ship has a cost because it has to get evaluated. It has to get parsed. So when you ship more JavaScript, parse time goes up. There's no way you can really avoid this. So the trick is you ship less JavaScript. You ship less parse JavaScript. The end result of all three of these is that your users have a blindingly fast web experience and everyone wins. Thank you very much. Well done. You made it through, buddy. So happy for you. Go and lie down now. You did well. Well done. Well, our next speakers are here to talk about predictability. So expect the expected. Please welcome to the stage, it's Rick and Robert. Hi, everyone, and welcome to our presentation about predictability. But first things first, we are Rick and Rob, which kind of sounds like two cops on stake out. But just go with it. And since I got the opportunity to put together this slide, I got to pick which picture to use of Rick. This was the best picture that I can find of Rick. Thanks a lot. This is Rick. Hi, I'm Rick. I lead a team of software engineers working on the web platform. And my name is Robert, and I work with developer relations around feedback and community and then much more. This is the worst picture of me available on the internet. Don't check. And the things that we're going to talk about today is what is predictability? You've heard many interesting talks today about new features and all the progressions that are happening on the web. But what we believe we're covering today in this talk is the most important thing. And that's having a reliable platform for developers. If we don't have that, we don't have anything. And web developers love the web, right? Well, so-and-so, right? There are still a number of issues and challenges that developers come across. So we want to be honest about this. This is an uplifting talk at the end of the day. We want to be honest about this. The web does have a problem. Working cross-browser has historically been really, really hard. It still has a number of challenges. And also with inconsistencies between different browsers, interoperability between different platforms and devices and all that. So we want to make it better for you so we have one joint web platform. So that's why we started the predictability project about six months ago. And maybe you've been working with square wheels so far. But we see this as our responsibility to make sure this is actually good for you and expected you could spend the time on the right areas. And we put our most neutral people working on that. So I'm Swedish, Rick is Canadian. So basically you can complain a lot to us and we'll say we're sorry to see the theme here. And actually thinking about the team, we have a number of more Swedes and Canadians on it, so this is not a coincidence. And the main areas we want to go through today is how Chrome is trying to improve predictability for developers. All the work we're doing to make things better and, well, more predictable. Also how we work with other web browsers to make sure it works the same way across the board. This is not just about us. This is about the web and how we do things together. Having browsers fight against each other is just a waste of time. The important thing is the web. And finally it's about how web developers, how you can help improve the platform as well. Basically we want the web to just work for developers. That's it. And it shouldn't be that hard, but there are some challenges around that. So there are five main areas where we want to address this. First, we want to make sure that you fight the platform less. Less need for browser-specific code paths, making sure you don't have to have too many work arounds for regressions. Basically things that used to work and then three months later it just stops working. You have no idea what happened. Also trying to get away, diminish or even just completely get rid of all kinds of polyfills and shims and all that just to cover up for interability. That's not the way it should be. We also want to make sure that we don't chip any accidental regressions. And when we deprecate features, we really want to understand that we're knowing what we're doing and what the cost is for you. How will this affect you? Not just like, yeah, I never liked this API. So we want to make sure you actually know what's going to happen. We also want to be way, way more open about interventions. And Rick is going to cover interventions more later in his part, but basically giving you options to, well, solve issues when that happens. But to be honest, things do fail fast in the world. And when it does fail, we want to make sure it's both fast and obvious to you. So it's not just a complete surprise every time you have no idea what happened. It's also about having quantified data and, sorry, analysis to make sure that we know that when we cancel different features, we have the numbers to back it up. How is this actually going to affect developers? And finally, just giving you a more coherent platform, making sure that the most commonly used features work really, really well together. Like, we want you to feel this passion, right? If you look in their eyes, they love the web. Slightly scary, but still love. OK? And working on the web might have been hard historically. You might still have some issues. But moving forward, we want you to look back when it was hard and just laugh it off. You're just going to be happy because working with the web is going to be a breeze. That's where we're going. And to go more into detail about that, we have the amazing Rick. Thanks. So hopefully that gives you a rough idea of what our vision is for predictability. It's a big dream. We've got a lot of work to get there. But I want to get a bit more concrete for a minute. It's always been part of Chrome's mission, as you heard Darren say this morning. It's always been part of Chrome's mission to make the whole web better. Not the web shouldn't be just a collection of browsers that kind of behave similarly. But we really realized over the past year that we've got more to do here. In fact, first and foremost, we need to collaborate better with other browser vendors. In fact, part of the reason this project exists is because we were really inspired seeing how hard Mozilla and Microsoft were working to make their browsers just work for the websites that you have already built rather than trying to get you to change your websites to make them work on their browsers. And even when that required copying some buggy, non-standard stuff from WebKit and Chrome, it sucks that they had to do that. But it was inspiring and it made us want to invest more in this space. And so there's all sorts of ways that we've been working better over the past year as a community, as a browser vendor community. I'm not going to go into all the details here. It's probably kind of boring for you. Standards are obviously a huge part of this. We invest a lot in the standard process. We care a lot about standards. But even the day-to-day of how we do browser development has really changed. We're constantly filing bugs in each other's bug trackers. We're constantly collaborating on shared test suites. It's very different than it was a few years ago. But I don't think that's too relevant to this audience. I think probably the area you care more about is it's really important that we do a better job of listening to you. And honestly, this is why I'm here. I'm hoping this will be the start of a conversation. Hopefully, somebody will grab me afterwards and complain what's bothering you about what makes the Web hard for you. And this is important because I think the Web is unique in that it's the commons. We all own it collectively. No one controls it. It's really a marketplace of shared ideas that compete against each other. And in that kind of environment, it's essential that the different players in that ecosystem are talking with each other and understand each other. All right, so typically the best way for you to tell us that we're doing something bad is to file bugs against us. For those of you that don't know, Blink is the web engine underneath Chrome, Opera, and Samsung browser. And so I'm going to talk a little bit about Blink bugs, bugs in our web engine. Over the past year, we've really invested a lot in bug health here. We realized we had a bit of a problem. And so now, I think we've got a really good process where if you file a bug on us, it first goes to a QA team that tries to reproduce it and they'll engage with you and try to ask some questions. And then once we can verify there's a bug there, it gets routed directly to an engineering team. Pretty much we have complete coverage now of all of our bugs so that there's some team responsible for checking on the bugs regularly and trying to prioritize the most important and working with you to get fixes. And as a result of that, you can see over this past year, for the first time ever in the history of our project, we've consistently closed more bugs than we've opened, which it's always a good place to be in. APPLAUSE Thank you. Good. And here's some stats. I just picked September. Bugs filed in September by you all. These were bugs that were filed via our wizard, so people that aren't Chromium committers. There were 300 such bugs filed in September. And already 93% of those have been reproduced and routed to an area. And that's what we mean by triage. They're on some teams plate to deal with. About two-thirds of them have been resolved in some way. Sometimes this means, actually, it's not uncommon that we dig in some issue, we talk with people, and we agree that actually turns out it's not a bug in Chromium. It's a bug in a website or a framework or something like that, and that's fine. Or sometimes it's a duplicate of another issue. And about 16% of the bugs that were filed in September turned into actual fixes that have landed in the code are now shipping in Chrome. And I think there's more to be done here, but I think this is pretty good. I think this is a signal that if you file a bug on us, there's a good chance that the right people will see it, pay attention, and something will happen. I think it's worth your time. The other signal that's really valuable to us is our stars. You can see in our bug tracker system here, there's little star next to the issue. If you're signed in and you click on that, it means that you care about this bug. You want to get email updates. And we use the number of stars as a really important signal in prioritization. We know it's flawed, it could be gamed, so it's not the only signal we use, obviously. But if you look at the stats for just the top starred bugs, the top 1% in terms of stars, we fixed 2 thirds, which I think is fantastic. And that's true for the entire lifetime of the project. It's also true if you just look at all the bugs filed in the past year, the top 1%, 2 thirds have been fixed. And that's fixed. That means it fixes landed, right? Some of these weren't actually bugs or some of them were other things. In fact, I'm particularly proud that if we look at the top 60 starred bugs of all time in Chrome for web platform bugs, we've fixed nine of them in the past year. And many of these are things that you may care about. You'll notice there's two on this list that have three-digit bug numbers. That means these bugs were filed the day the Chromium project opened in 2008. So we're a little slow getting to them, I'm sorry. But we're on top of it now. I think we're also getting a lot better at involving all of you and listening to all of you in terms of new API design. Google, now when we work on new features, we will initiate new web platform features in a process that we call incubation. That is a process that really emphasizes starting with use cases, not starting with a solution. Starting with use cases and involving web developers, trying to vet that these use cases make sense and that the ideas we have for them solve those use cases. And we do all of this in the open via the W3C's Wiccig group, the web incubator community group. All of this is on github.com. Take a look at the repositories there. There's an explainer document that describes the problems that we're trying to solve. And there's often draft specs. And we love to involve you. File issues, tell us what you think. And then when it comes time for us to ship a new API, this is a really important time for us because we want to balance, like it's our mission to push the web forward, but we want to push the whole web forward. So the most important signal for us here is what's the interop risk? What's the risk that we're going to regret shipping this because it's going to end up being a Chrome only thing? We don't want to add Chrome only things. We're happy to be able to head. We're happy to push things hard. But we really try to get feedback from the other vendors. You can see on our Chrome status page here, the colors under each of the other browser vendors represent what signal we've got from them. And you can click on those and get links. In this case, position sticky was something that's already shipped in Firefox. A prefix version is shipped in WebKit and it's on the Edge Roadmap as priority medium, I think, meaning that they intend to work on it. So that's like a really strong signal. Position sticky is something that's going to become part of the web everywhere. And at this stage, we get a ton of feedback from the other browser vendors too. Microsoft and Mozilla in particular, we discuss this trade-off in public on our BlinkDev mailing list. And when they don't like what we're doing, we hear about it and we will delay shipping things to try to resolve outstanding issues. All right, and then once, even before an API ships, it'll show up behind this experimental web platform features flag. You can go to Chrome flags, turn on experimental web platform features and play with the APIs that are coming up. Of course, we've got Chrome Canary, we now have Chrome Canary for Android, updates basically daily, so you can really try out the bleeding edge stuff, file a bug, and see how things change day by day. All right, the third main area where I think we've gotten better over the past year is that we now have better tools and processes for minimizing breaking changes. So first of all, how many of you have worked on a site where a new stable version of Chrome has come out and you've had a big emergency because something's broken on your site and you gotta do something about it? Come on, don't be shy. All right, okay, not quite as depressing as I feared. I'm sorry, I apologize. We definitely don't wanna do that, but I can't promise that we're never gonna do it because it's fundamentally incompatible with our goal of pushing the web forward. The only way to never break anything is to not move. And so we're trying to be thoughtful and strike a good trade off here. And in particular, I think we've gotten a lot better at minimizing those cases. Let me give you some examples. This is a specific example that's pretty recent that I think highlights how things should go when they're working well. So this was, in September, a developer noticed that they were just using Chrome Dev Channel and they noticed that on their site, their input type equals range element wasn't behaving correctly. And they actually figured out that it had to do with a particular CSP rule they were using. That if they hadn't figured out that it would have been fine in this case because the most important thing is when they filed the issue, they told us that it was a regression, that it used to work in Chrome 53. And that was an important signal for our QA team. The QA team said, okay, great, we're gonna go do a bisect. That means we're gonna binary search through all Chromium builds between Chrome 53 and then and identify the single commit that broke this website. And you see that happened within a day. The next day, QA team had done that and they had identified one particular Chromium commit, which is great. It means that we can make progress on this issue right away. We know who to assign it to, the developer that landed the change. And we know one possible fix is to river that change. So this cuts out a lot of the uncertainty that we used to have in our regression process because we don't have to try to point fingers and do a whole bunch of debugging to figure out why your site's broken. So in this particular case, what this meant was the bug was introduced back in August and no one noticed for almost a month. And then after Chrome 54 beta was released, this developer filed the bug. Within two days, a fix had landed for it. Within a few more days, there was a new beta release of Chrome 54 that had the fix. And by the time Chrome 54 hit stable, the fix was in there so it didn't affect any users. This is how we wanna see regressions happen. And this is fairly typical these days. So if we take a look at those bug stats I posted before and extend to logistic regressions, you'll see the numbers are even more promising. 100% of the regressions that were filed in September have been triaged, 85 have been resolved, and 40% pretty much have had a fix landed. All right, but unfortunately, breaking changes aren't just about accidental regressions. We believe that it's important, in order for the web to be able to move forward, we believe it's important that there's some way to shed the mistakes of the past. But this is something that we wanna do very carefully and very thoughtfully. We take it very seriously. We really don't wanna break websites as a result of this. Try to balance what's best for the platform overall. Let me give you a concrete example. Any time we're thinking about maybe we should break some functionality intentionally in the web. The first thing we do is collect a bunch of data. So in this case, the security team made an argument to us. They said, look, geolocation API returns precise position. When users say yes to that on HTTP, we don't think they really understand that they're not saying, yes, I want this site to know where they are, where I am. They're saying, yes, I want everybody that's sniffing to the network traffic to know where I am. And we know that's often a fair number of people. So they argued that we should make geolocation behave as if the user always clicked reject if you weren't on an encrypted connection. And so we said, okay, well, let's look at the stats. So if you've opted in to anonymous data collection in Chrome, then we send this anonymous data back to Google that we can look at. And we saw that 90% of geolocation was already being done over HTTPS, and the remaining 10% accounted for about 0.05% of page views. This is still higher than what we'd normally like to see if we're really gonna break something, but weighing the trade-offs, we weigh the trade-offs in public again on our Blink dev list. We solicit feedback from various parties. And in this case, we decided that, yes, it was worth the cost to break this scenario. And so we have a console warning in dev tools to say, warning, you're relying on something that's gonna stop working. We're working on a new API, so you can get this from the wild rather than just having to use dev tools. Normally these days, this will always include a milestone and a date for when it's actually scheduled for removal. But then after some period of time that there's been a warning and we've got a blog post explaining that there's gonna be a breaking change, we'll eventually rip it out. And then we go through our normal launch process, right? We've got Canary, Dev, Beta, Stable. And if we see that there's a bunch of complaints about things not working, we can reevaluate, reconsider before it hits stable and affects a bunch of users. All right, so it's still really hard to build a website that provides a great user experience, while also being built out of components that you don't necessarily control. iFrames, ad networks, third-party scripts. There's a fundamental tension there. And if you think about this, this isn't new. Browser vendors have always made a trade-off. The browser is a user agent, right? It's designed to mediate between developers and users and sometimes act on the user's behalf. Most classic example is pop-up lockers, right? All browsers have some heuristics in them to decide when am I gonna allow a window dot open to succeed and when am I gonna say nana? You can't do that, sorry, that's gonna piss off the user. And this is a really tricky trade-off. We've always struggled with this because on the one hand, we want the platform to be predictable. We want you to be able to reason about what's gonna happen, but finding the right trade-off for these sorts of things is tough. So over the past year, we've gotten a lot more disciplined about how we approach these types of difficult trade-offs. We formalize the concept into a term intervention. An intervention is something that minimally breaks existing behavior in the browser in order to get some substantial user benefit. And good interventions should be predictable, meaning that you can know when it's gonna happen. It's something that we could standardize. We will be on a track, hopefully to eventually be standardized. It's avoidable, which means if you're following best practices, like using HTTPS for anything that's privacy sensitive, then you won't be impacted at all. It's only really for things that we consider legacy. It's transparent, which means that there's APIs so you can measure and understand how often you're being impacted by an intervention in the wild. And critically, it's justified by data. We're constantly collecting data from the field to evaluate the cost-benefit trade-off of interventions and try to strike the right balance for the overall health of the web. Let me give you a concrete example. In Chrome 52, we shipped an intervention called, where we throttled the rendering pipeline for off-screen cross-origin iframes. Basically what we realized is there was a lot of sites that were using a lot of CPU for updating animations of ads that weren't even visible. And we're like, well, that's silly. But that was how the web was designed, defined to behave, like request animations frame and supposed to fire whether or not your iframe is visible. So we did a bunch of investigation and looked at what some other browsers had done in this space. And we shipped an intervention in 52 that showed substantial power improvements. On a bunch of sites, if you just leave the page sitting there, power usage went down by 50%. In some cases, 90%. And this was kind of an ideal intervention in that when we shipped it, to this day, we haven't had a single report of any site being broken by this. It was theoretically possible that some site could have been, but this was a great example. We saw a huge user benefit for very little cost. And there's really a theme here. Thanks. There's a theme that we're trying to do more to protect the top document, the main application, from iframes that might not be well-behaved. For example, we're trying to extend this to also include timers. So set timeout doesn't fire. We found a couple cases of that spraking. We're working with people and trying to mitigate that before we ship that. Again, we're designing all of this in public. We think it's important. This is about the web, which nobody owns. And so we think it's important to have these trade-offs be public discussions. Again, we do it via the W3C's WCAG community group. There's a repository called Interventions, where each of these ideas we have is filed as an issue. And we'd love your feedback on them. In particular, if you've got a concrete example of where your site is being impacted, maybe it's a scenario we didn't anticipate. Maybe there's a way we can change the design so we can get all the benefits without actually hurting your site anyway. So we'd love your feedback here or just file bugs on Chrome again. All right, Dr. Robert. Hey, what happened to Amazing? I called you Amazing. Sorry. We rehearsed it, right? Well, OK. So back to the high-level guy, I guess. So of course, part of predictability is also working with developer feedback and listening to you. And the three main areas are, of course, hearing what you have to say and acknowledge the issues that you're facing, also understanding different challenges that you have, and finally also getting information from you, getting data, getting use cases and all that to make things better. And one part has been improving the bug wizard for Chromium. So Q and other stock photo or bugs. But the general idea has just been to, with the bug wizard, make sure that it has a very clear web developer focus right now. And also that if you file a bug, we can have a direct routing to that team, fixing that specific issue. So the way it looks now, you would come in and you would pick WebDeveloper. And it's a very clear view from you. You would have a few choices that are just relevant to you, and then you can dig deeper or describe your case or something like that. Whereas before, it was a long list where most, if not all, of these were completely irrelevant to you. So we're just trying to make it slightly easier for you to go through that path. We also want to talk about services like Browser Stack, where you can quickly get screenshots from many different browsers and devices, even those that you don't have, but just to see what it's like across the board. So for instance, you can test your stuff and you can see what it looks like in IE 11. And then comparing and seeing with Opera 12.15, this is the same experience. And then what about the iPhone 6? Does it work there as well? It's just a really easy way to at least get an impression and a perspective of what it should be across the board. Also, interestingly, they offer the way that you can use your browser interactively. So you can pick one in that list and you can go in and you can try Safari or Chrome on iOS, for instance, and you can see what it's like in there as well. So services like Browser Stack and Sauce Labs and other ones, we really recommend checking those out to get a good overview. And we can't stress this enough. Filing a good bug or starring or contributing to an existing one is definitely the fastest way to get an issue fixed. So we can resolve the challenges that you're facing. And also as part of this, in our website, we're launching a new feedback section where we will surface a number of ways for you to, well, give feedback and also getting involved earlier on and try out new different things as well. Because engineering for, well, basically any browser is being handled by bugs. It could be things that aren't working or feature requests or something like that. And we also want to teach you or help you in how to file a good bug. So there's also information here how you best described your issue to make sure it gets resolved and also how you can create a minimized test case and then host it somewhere so you can share it with us. So we also want to foster discussion. We want you to be able to talk with each other because you never wanted to be like the poor Denver coder that disappeared and was never found again. So the main idea here, and we have some information on the feedback section, is just about, you know, share information, help people or share the issue that you're facing because, you know, being silent on your own and upset won't help anyone. So please take part and contribute. And also, as Rick was talking about, like many of the bugs that are being filed is by our own engineers or between different browser engines. And since everything within development is still driven by bugs, we wanted to make it way, way easier for you to find bugs and seeing what it looks like. At the same time, we want to present the web as one joint platform. We don't want it to be able to or having to hunt down every bug in every tracker everywhere, so we want to present it in one joint interface. So I started thinking about this, how we could do that and we're Google, so we kind of like the idea of searching for stuff and also getting it in one interface. So I presented my ideas to Eric Bidelman on the team and sort of describe what I wanted. He had a few questions for me and then he started hacking. So he created something that we officially nicknamed the BBS, which is the browser bug searcher, and when I saw it, it was bliss. It was fantastic and it was just the way it should be. So as part of the new feedback site, we now have the browser bug searcher as well. We got good help and input from other browser vendors as well, how to interact with their browser bug trackers and getting information from them as well. And why it's so important to search for existing bugs is that last month alone with Blink, 25% of the bugs being filed were duplicates. So please, please search before you file something. But with that said, it's always better to file a bug than to not file a bug. So if it's a duplicate, it's not the end of the world. Make sure to share information. So this is a shiny slide. Do you wanna see a demo? So we'll try and do a shaky demo. Well, don't clap yet. I appreciate it, but no. So, how would we get this here? Is that you? Yes. Perfect, thank you. Also like they were kind enough to make the cursor really, really big for me here. Could we get it? I have a nice view here at least. So the idea is that you would go in here into the new feedback section of the website and you would have this field and then you can immediately start searching for something. And what you get presented with is a list of bugs across all bug trackers. So both where they are being reported, across WebKit, Chromium, and also Mozilla and Edge as well. So basically all the major web browsers. You can also see the current state of these bugs are they being resolved, won't fix, are they just being new and filed or something like that. So it's just a really, really quick way to get an overview what's happening. And you can also easily page between different results here, or you can choose to see all the results. And also in this separate page, for instance, if you wanna filter only on a couple of trackers, you can do that as well and just compare those as well. Or just fade out, fix the issues. So you only find the actual relevant ones that are still working right. This is pretty cool, right? Now you can clap. So we had a little backup video in case, you know. And also what I wanna say, tomorrow afternoon at 4 p.m. we're gonna have a breakout session about web predictability. And it's the only session with the welcoming of come there and complain as much as you like, okay. Come and why and come and tell us about your biggest issue because we need to fix this. We need to make this as good as possible for you. So summarizing all this, we are really trying to treat the web as one single platform, the way it should be. It's just one big platform for you and should work across the board. It doesn't matter for you if things only work in one place and not the other one and or which browser's doing right or less right. It has to work across the board. So also please keep on testing on beta releases, file bugs, star bugs for features so we know what you're interested in or need help. Go and visit the new feedback section, try out the amazing browser bug searcher as well. And finally, get involved. This is your web. And we wanna end on a note of saying thank you. The web would be nothing without you. We're doing this for you so you can create all the amazing experiences for people out there. And I think now and these times more than ever, we need one big joint inclusive platform for everyone. Thank you. Dad. Right. Well, for the final time today. Indeed. After this, there'll be the big prize. The big prize. Later on. We're gonna do a couple of questions, the final questions for the big web quiz so we can get that on the board. And we'll just remind people that we're what we're playing for here. The big stakes. That's, this is showing me that this is frozen up so I can make this work. Yeah. What? Well, oh, that's all to play for. Oh, that's the current leaderboard. That is the current leaderboard. Did you, Paul, perhaps put the leaderboard on in the back and get to turn it off? That's possible. Yeah, okay. That's good. Right. Let's hide the prize and let's go for our first question, our first of the final two questions. Ready? Here we go. Here we go. Of the latest stable versions of each browser, which support marquee? Chrome, Firefox, Safari, Edge, i.e. Check all that apply. This is one of the select many ones. You can take a look at the answers as they come in. Almost were pretty, pretty certain. On one of them it looks like 64% there. The rest of them are unsure. Oh, we've got one that's, a few of them are creeping over 50%. It's a pretty even split, isn't it? It's a serious one. Chance, should we lock it in? Interesting, that's how you voted. Confidence was high on i.e. I guess as the older of the browsers there, most people thought, well, it's a fairly old thing. Which one's the least confidence edge? Okay, so people say it's deprecated, it shouldn't be there. If you were saying it might be in Firefox, but not Edge, which is interesting. Interesting, it is interesting. So, let's have a look at the answers as they appear. It is in all of them. It's actually all of them. You can marquee yourself happy. The predictability of the web. You know what I mean? We can always rely on marquee. You just had the talk. Right, and let's go for the final question of the day. Which? I'm so sorry, I enjoyed doing the voice. Which of the following are valid return types for video elements that can play type, passing in a mind type? True, false, definitely, probably, maybe, oh, look not so good. So, two of them are very high confidence. Well, there was particularly little confidence. I wonder which one that could be there. Yeah, we have some smarty pants in there. That's interesting. It's like a four, one, two, three. Right, and shall, let's lock it in, shall we lock it? Interesting, so very high confidence on true and false. Yes, the Booleans, I mean that's, because if you're asking can I do something? You would think, you would think. True or false? You would think, wouldn't you? Yeah, that's what you want. You'd be wrong. You would be very wrong. Because the actual answers are. The correct answers as they appear now. Probably, and maybe. I kid you not, I look this open. The only other option you have is an empty string, which is, that's the no. But other than that, it goes, yeah, maybe. The most nonchalant API on the platform. You give me the video and I will give it a shot. I'll do it live. I'm not promising anything. I mean, I'd love to play it. I really would. So, that is our final questions. And after the next session, we will take a look at the leaderboard and see who's the winner and hand out the grand prize. Which, as a reminder to you, is frozen. It's frozen. There you go. Oh, well. Well, you can enjoy the side of the mug. Meanwhile, I'm gonna leave and you can do your intro, sir. Yes, we're going to do the leadership panel. So, I'm gonna get my tablet full of the questions that you've been sending in today. It's awkward to hold these two at once. Right, let's get our panelists onto the stage. We have Tao Tran, who is the partner development manager. Dion Alma, engineering director. Yeah, come on, yeah. Go and take a seat. Yeah, so Dion Alma, engineering director. We've got Parisa Tabriz, who is, well, down as browser boss in her work bio. So, I'm gonna go with that. Darren Fisher, VP of engineering, who you met earlier. Greg Simon, engineering director. Alex Komorowski, product manager. Dmitry Glaskov, engineering lead. And Grace Klober, principal engineer. So, let's see what question. I haven't really looked at these yet. So, I hope they're good. We haven't either. Right, so, question one. How many HTML tags are in the HTML spec? No, I can't, this is the wrong question list once again. Wrong with it. Let me figure this out. Too many. Maybe. Probably. Probably too many. Okay, as you say, we have some microphones set up. We've got one here and we've got one over here. If you want to ask a question live for our panelists here, that is something you can do. I mean, we've got someone being very brave. So, I'm not gonna ignore that. Should we take a question from the audience straight away? This is gonna be very tart. Can we get that microphone on so we can hear the question? Here's the question. There you go. This is gonna be a very specific one for such a big panel. But it hits close to home. It has to do with messaging across Google as a whole in particular how it affects Chrome. Hangouts, I use it personally. I use it in business. And the app versus extensions been shifting and fluxing. And recently the extension has broken entirely. We were pulling it off of GitHub because of a feature that was pulled out of Chrome, the docking feature. It seems like a decision that had to have come from a lot of different places that would have affected a lot of users and doesn't seem like it needed to happen as a breaking change. And I'm wondering if you can tell me anything about the process and how something like that comes to be on the Chrome ecosystem. So, I mean, there's no one here on the panel who works specifically on Hangouts, but does anyone want to take a stab at that? I think we can talk about the API in question a bit. Anyone else, feel free to jump in too. But in this particular case, there was an API developed specifically for Hangouts. And oftentimes when you build an API like that, specifically only for a one-first-party application, it's a lot harder to build an API that's gonna stand the test of time and really hold up and, in fact, be implemented well on all platforms. And in this particular case, we were left with the question of, do we try to really make this thing work well, even though it was really only built for a specific application, or do we move beyond it? And the decision was to sort of move beyond it because it wasn't something we felt like we could actually build in a solid fashion. So I kind of wanted to lead on from that question a little bit more. So the things we promote here, things like being progressive, accessibility, working in all browsers, I mean, that is something that we don't see happening across the websites that Google actually produces. Is there something that we can do there? Are there other efforts there? Is that something we can change? Dmitri, do you want to say, as one is from a polymer standpoint, is that something that we can do? I would love to see that changed. I think Google does need to play a larger role in the Progressive Web Apps ecosystem, and it does need to kind of get on the strain. The strain is moving. Tao was telling us all about it. I'm doing all I can to make that happen. And Yal can help me with that too. So that's also a call for help. So if anyone has any, oh, we'll do the live ones, because, you know, we don't have many of these. This question is about promises. I know you've been very happy about promises, but personally I find it horrible. In the next few sentences, are you going to say the word observables? Just a prediction. Actually, I think it's kind of stuck between two different promises, one being trying to become simpler, like not having nested callbacks, and the other one trying to have like parallel execution, like promise all, and ended up being neither. It's kind of really, really complex, this given point in them. Why is it this two different objectives taken in one single thing and complicated? I mean, is it my personal experience? I don't know, but I think it's kind of, it has two objectives and it has not met both. Well, I mean, how have you used async awaits, where you feel like you're writing a synchronous function, but you're using promises? Have you found that's helped the problem at all? I'm saying, you know, you're saying from nested callbacks because you have, then it makes it easier. It doesn't necessarily, right? I think the problem seems to be that if you really try and build that, you're having a sequential execution, right? But you really don't have the if-then kind of structure that you would normally do in the sequential execution. And also, you know, most of the time when you're having multiple execution, you suggest doing like promise all, like building that structure, and anyway you have lost the whole structure anyway. You have to rethink the whole thing, right? I think so, tomorrow we have Seth Thompson speaking from V8, but we also have Alex Russell, who's on TC39. I think speaking to him about that would probably be better than anyone here, if anyone's got anything to say about that. Yeah, Alex Russell, who spoke earlier, he's around this evening. He's a good one to talk to about that. I think personally, as a developer, if I don't find it useful, it's easy. I think that is what you should look at it as an end result. Maybe it's still easier for you guys, because you're designing the system, but... That's a really great feedback, thank you. So one of the questions I have here, which I think has popped up on every time we've done this panel thing is that are there plans or discussions taking place around making progressive web apps discoverable in the Play Store alongside native apps? And it's interesting that that gets a round of applause, because I always think, like, if only there was some kind of discovery platform on the web, if only one company would step forward and make such a thing. But people like their Play Stores. By the way, there was not enough clapping. Don't pity me. But in all seriousness, I think, to some extent, you can look at app stores to some extent as almost a failure that the web already had that piece. App stores were necessary because there was no other way to get these things. And yes, it has become something on mobile that I think some users expected to be there. But what users also expect is that when you tap a link into anything, it will load up that experience. And so I think it is an interesting other source. I'd like to see how, as we evolve these things, what we can do in that space. But ultimately, I think it kind of underplays the strength of URLs on the web that are like, it's super power. I would totally see the point that if you are in an app ecosystem today, it is important for you to, you know, quack like a duck, right? You need to behave like other players in that app ecosystem. So I can totally see it. I think especially as with the improved add to home screen that we were talking about earlier today, I think as these things become more and more, so they fit in more and more like apps, I think users might bring over more and more of those conceptions. So for someone who had like a gains portal, that was their app, so to speak, and then they wanted to mint other apps. So you're in their thing and you want to grab an app. Well, wouldn't it be nice to have the flexibility for use cases like that that makes sense to be able to do that, to have a meta app that can mint other apps and they're like, when we have these nice things with, you know, to put paths and scopes and URLs and sub-domains so we could actually, you know, look at, you know, be able to deliver those types of things. There's a set of other PWA's and then you can, like, go to them and then you can add those to your home screen. That sounds like a pretty good idea. Get Yahoo to build one, yeah. Tau, like, do you hear this a lot from partners wanting this feature and what do you think makes people really want to be in the store? I think it's more about just discovery overall, right? So why not have both platforms be at your disposal? I mean, at your disposal in terms of discovery, right? So I don't think... I think for most people, they understand like the web is great and has the superpower of reach, but at the same time, having another place to have your progressive web app be available is just additive in terms of discovery and especially if people are in a mindset that the first thing they do is click on, you know, the place or icon or the app store in order to discover content, right? It's just about giving people as many opportunities to actually find your stuff. And so on mobile device, it's the place or the app store. I think to some extent, too, like what we shipped for the add-to-home screen first, that wasn't the final thing. We've been evolving that as kind of a bit of a journey and I think we aren't done yet, I guess. We'll take another question from you. It's friendly face. Hello. Yeah, seeing Jake, should I talk about streams? Or surely? Yeah, my question is a two-part or one. I've been seeing throughout the day that Google has a single browser but building for the web. What's stopping it from influencing Chrome and iOS to have service worker or Safari to have service worker? And the second part is extending the add-to-home screen part. Would it be possible to have a direct link saying add-to-home screen when we search for, say, some web apps? And we know that we have a manifest file already, so it would be nicer to say like add-to-home screen directly from the link. Is it technically challenging and why is that not happening? Okay, so the first part of that is like, what can we do about Chrome and iOS? What more can we do there? Grace, do you want to take this one? I think for the iOS is... for the service worker, we... Very limited. Yeah, so... Yeah, I think it's like we don't... we have to, like, using the WK WebView, right? We don't really have a lot of choices. And what we can do is try to influence Apple to put a service worker into the Web... into the WK WebView, so which means all the apps, like a browser-based app on iOS can enjoy it. And part of things, I think, for us to demonstrate how it works well in Android, and then, I mean, we need you guys to build the app using the service worker and the user can see the difference, benefit, and then hope that can influence Apple to changing, adding the service worker into the WK WebView. Absolutely. Yeah, you go make your Web experiences much, much faster on Android because you're using the service worker, and so if you're an iPhone user, the Web is slow, and if you're an Android user, the Web is fast. Yeah, and there's actually Apple representatives here. It's been really great for them to show up at the event, as well as Mozilla and Opera and all these other folks. So I feel like, you know, if you... I don't know if we have a polymon for them, we can catch them. If you can find them, like, talk about, you know, what you want from Safari. Yeah, this actually came up last year as Chrome Dev Summit on the talk about benchmarks, and really, that's the ultimate benchmark, right? It's like, well, my website runs much faster for users on this browser versus another. That beats any synthetic benchmark out there. I'm going to do one more question from here before coming back to people in microphones. How am I... Oh, yeah, you did ask. Yeah, I can... It was about at home screen from the search base directly because we know that these apps would have manifested some of them. Yes. That's a great idea. Yeah, things like for the search result page, right? So, yeah. We're actually definitely looking into that with the search team. Yeah. Yeah. I'm hoping to see you that soon. Thank you. Thank you. So how might users' expectations of the security model change when a web app is launched from the home screen? Parisa, do you want to take this one? So it feels like a native app, so should it be able to do all of the stuff a native app can do? It feels like a native app. I worry about this, actually. There is a different security model for native applications, whether it's on a phone or any computer, and the web. And there's great... I think that we have an opportunity to merge that experience and actually make it more immersive between native applications and websites, especially on the phone. But most users don't understand the security model differences. You shouldn't need to. Most developers don't necessarily need to. And now we have kind of native apps asking for permissions and websites asking for permissions, and users don't necessarily know which is which, especially as we kind of evolve the UI between these two things. Was the question specifically asking what... Yeah, is there any things we would grant if the app was added to the home screen that we wouldn't, if it was a website? Is there anything that we would infer? Well, one thing we do is full screen. We'll hide the omnibox. That is already happening today, that you do get the durable storage for your smartphone, things like this. So there's a lot of things that are already happening that add to home screen is such a strong signal from the user that they want to engage with the site that we sort of do have some affordances. But there is, like you pointed out, a really interesting line to walk. Yeah, and I think... I don't think of it as like this is less secure, but I mean, you're getting more capabilities and with those capabilities come, you know, risk of abuse. I think I mentioned earlier today that we were looking at auto granting the notification permission when the user goes to the add to home screen flow. And one of that, too, is as these... with the improved add to home screen, it feels much more like an app in many other ways. In Android, for example, you native apps get that permission to push notifications by default. Yeah, and I think this... I don't think you always want to ask. I think there's a tendency to say, well, we should always ask for permissions, but people get desensitized to constantly being asked to grant permissions. And then you've lost any security benefit, but that question was going to be asked. So I think there's a lot of work we're doing into finding out the balance for any capability. And the more powerful it is, I think the more, you know, thought we put into where that balance is, but... I think there's a non-security aspect, too, of just, like, when you tap on this, what should show up? Should it feel like a web page? Should it feel like an app? And someone actually in the audience, or it was definitely earlier in the audience, showed me they'd taken a native app, an Android app, and they'd pulled it to a PWA. And they were going through how, like, it was basically, you know, perfect fidelity, other than the fact that they couldn't affect the screen brightness for this one scanner piece. And as I was sitting there, I was like, I remember, like, a couple of years ago, we'd be kind of like, oh, the web can't do this. It can't do this. And to, like, be talking about, like, the screen brightness is, like, the one thing left that it can't do was kind of like, pinch me, pinch me, you know? And so thank you guys so much for building these great experiences that they actually really do feel like. You know, when my kid goes up and taps on this icon, he really doesn't know what technology and definitely shouldn't care what's going on. I don't know what technology. I mean, people don't know, and I think that's awesome, right? Like, you just want to enjoy kind of, I mean, you know, yeah, you shouldn't need to care. And I think... Well, I think what you said before about people not understanding the security model, I think that's true. One of the things that sort of terrifies me about native apps is the power they have just over making web requests. I mean, I think as developers, we complain about cause quite a lot. It's a bit of a pain. But it also terrifies me that native apps, like, if you've got anything in your house or in your company that you kind of think, it's kind of password because it's internal only. Any native apps on people's phones on the same network are just able to read and write from that. The web's security model is somewhat paranoid almost, but that paranoia is a strong word, but is what allows us to have that really low friction. You know, it's no accident when you tap a link, it goes right to it even if it's a different domain. That's part of the 25 years of the security model that we've been developing and maintaining and strengthening. We start to feel like security model is a trigger word for this panel and it's a good question for a little while. Let's take a couple more questions from the audience. So, the rest of that. So you guys touched on it a little bit already, but it seems like you guys are kind of encouraging developers to go more towards, obviously, PWAs versus something like Chrome package apps, which is what my company has been developing for several years now, kind of jumped on it right when you introduced that. So the question was, I see that there's like this migration strategy and not all the APIs that we need are there yet, and so I was actually talking to Darren, it sounds like there's definitely hope for that, but there's still something in the education area, which is that these are usually Chromebooks or some kind of device that is managed. So how do, what is the strategy for, let's say a school district, be able to push these applications to a set of devices that are strictly managed? Where are we going with Chrome apps, then? Who wants to take that one? I think as we looked through this, this was not an easy decision, obviously, and ultimately we care a lot about the open web and what we call the linkable web, the ability for people to be exposed to lots of different diverse experiences relatively easily. I think there's a number of gaps between what was possible in Chrome apps. It was a quite different security model in progressive web apps. For that particular case, I can imagine how that would work, I could push an icon, and then maybe that icon is pushed, we fetch and boot up the service worker in an off-screen tab to give it a chance to sort of fetch the things it needs. We really want to hear feedback from people like you about the gaps like that that are in place that we can work to address them and make sure that we offer the best solutions we can for that. For what it's worth, it does not seem like anything but a technical problem that we probably should tackle. This problem is probably also relevant in many other applications. For example, for next billion users where you might have offline a lot and you actually might have to resort to some peer-to-peer swapping of progressive web applications. I can imagine a world like this, and how is that different from what you described, except yours is a slightly different application of the same type of technology. So I don't really see this as a possible thing. At the end of the day, web apps work really great on desktop as well, and there's really nothing stopping us from fleshing out those details, so that the enterprise management features of Chrome OS and so on work well for pushing PWAs. Can I just want one more thing? How can we give feedback to Chrome team for things like this, because for a lot of shopping sites and stuff like that seems like there's a lot of people who are in that space that you can feed off of, but for education it's a very different market, and it's very narrow, so... We love getting feedback from all developers. Almost everything we do is fully an open source, and there's a reason for that. We love when people come on various mailing lists and give us feedback. It's very specifically on this issue, when we announced this change on the Chromium blog, there's a link to either a feedback form or a mailing list, and we really urge you to engage there, because this is a great example of a thing that we should just do, right? Thank you. Good evening. As the modern web application's goal is to make the user experience better and make the web applications native, right? So in that case, if the user uses the web application for the most of the time, the memory consumption of the web application is also matters. So I'm glad that we have debugging tools to identify where the memory leakages are in the Chrome. But what are the suggestions do you give to the developers to prevent the memory leakages or what are the areas that developers should concentrate to prevent the memory consumption? That's one of the things that I found the most difficult thing to debug on web pages, despite the DevTools we've got. Who's going to fix it? We are going to fix it. Yeah, this is actually a huge pain point for us. We've invested a bunch of effort into trying to understand memory usage ourselves inside of Chrome this year. And I think... I don't know if you are feeling it, but we definitely know our graphs are all, you know, going down in terms of memory consumption. And I think the actual developer experience is next. It's very hard to do your right. Greg is actually one of the pioneers of this back in the day where he went and engaged with the Gmail team and built them a little bot that runs Gmail for, what, 72 hours? We run Gmail for many, many days. Right. And caught their leaks. I expect it to be flat. Right. And it's hard. I agree it's hard. And we are sorry that this is not working today, but we will get there. And this is one of our focus areas. There's a lot of effort being put on to the low-end devices, too. Yeah. And also, I think, like, in the past year, we did a lot of work in the DevTools, and then we actually can capture some of the memory you can, like, using the DevTools today when you run your website and then try to capture the memory snapshot and then to see where the memory... Well, part, at least, like, relative to Chrome may not be relative to exactly what part of your code, but you can see where the memory goes. Yeah. It's not just, like, any good programmer. Pay attention to how many references that you're keeping. It's easy to understand in the code that you write yourself, but if you bring in a bunch of frameworks that you don't understand how they work, you can... All it takes is one reference, right, to pull the whole world with you or keep it around, and that's hard. Well, a way that this can definitely get better. Sorry, where we tackle a lot of this on the server side is you run a pool of, like, five workers, and once memory gets so high on one of them, you just kill it and restart it. And I'm kind of pushing my own agenda a bit here, but, like, can we have... I really want us to look at navigation transitions again, and I think we're starting to do that because in something like Gmail, if you're clicking on emails, you know, we could do full-page reloads, and if we could do that fast and we could do that in a way that, you know, you can still have a fancy transition, then you've got that sort of tear down. Because you're already killing it constantly. Yeah, exactly. Can we get agreement on that now? That's the next question. This is a really... This is a good one. It's quite spiky. I've got some unease about Polymer. It seems weird to have browser folks advocating a specific framework. Is it, you know, is the idea that it should just shim new APIs and sort of eventually become redundant, or does it make sense for a browser to push a framework? I don't think of Polymer as a framework. I think of it more of, like, a mix-in, right, because it uses the platform. I mean, that's the trendy thing to do now is to claim your framework's not a framework, but you're involved with that. But in all seriousness, I think tomorrow, Adi Asmani, I think, is going to give a talk about how to build progressive web apps on many of the popular frameworks. And ultimately, like, there's a million different ways to build progressive web apps well, and we're excited to see a lot of stuff the React community is doing and the Ember community and other communities. The way I think of Polymer, actually, is there's this gulf between browser vendors and web developers, browser engineers and web developers, and it's kind of weird, actually. When I first joined the team, it was kind of surprising to me because I came... It's two plus-plus coders. Yeah, it's very different, right? And so, actually, one of the reasons that we think the Polymer team is part of Chrome is it helps us test out all these new features, you know, HTTP push and web components and a number of these new features and give some feeling of what it would look like to do something that is idiomatically as close to the platform as possible. And so, to me, it almost feels a little bit like a... Well, it's just like a way for us to just explore what you could do if you try to keep this thermolayer as possible. But, of course, frameworks add a ton of value, right? I mean, frameworks are... In user land, they're able to explore concepts way, way, way faster than we can in browsers and in standards, and they absolutely have an important place in this whole ecosystem, I think. So, I'm going to take a couple of questions from the audience right after this one because this one's been... The font size has been made very big on this one, so I think maybe a lot of people have been asking it. A lot of people use Chrome on desktop. Oh, we released Chrome on desktop as well. What plans are there for installing PWAs on desktop Chrome like add to home screen? Well, I mean, it already works, right? You can go under... Oh, it's easy. It's done, yeah, it's nothing more to do. In all seriousness, this is actually... We get this request a lot. It's... On mobile, it's actually easier to imagine exactly what it operates like because on mobile, you tap an icon on the home screen and then it goes full screen. That's how it works. That's what users expect, and there's not really that many sort of weird edge cases. On desktop, we have multiple operating systems. We have task bars and desktop launchers. We have full screen things. We have tabs within existing windows. Does this thing pretend to be a totally separate application or within Chrome? There's a lot of other interesting questions to reason through, and we definitely want to do it, but it's a lot more stuff... Interesting questions. I'm really excited that Microsoft a few months ago announced in a blog post that they're going to be exploring progressive web apps on desktop. I think that's really awesome. It's going to be really cool to see. But how far can we get down, like, an electron? How far can we get down that route? Launching without tabs, launching without Chrome? For example, today, you can go and you can say... You're on a Chromebook, you can say add to shelf. And your website now is on the shelf, and it launches in its own window. On Windows, you can say add to desktop, and so on. This doesn't work quite as well on OS X. I mean, that was even true when we were doing Chrome package apps that just doesn't quite give us the flexibility to present these experiences as distinct from the browser. But on Windows, it works really well, and so too on Chromebooks. I think the other thing is I wrote an ode to the desktop, because I think we talk about mobile all the time, and that's great, but one of the great things about the web is that it can stretch and do this responsive design and give us access to all of these different things. And I've seen certain productivity-type companies that go all in on mobile, and then they leave behind their desktop applications. This is what I live in all day. I use this for work. It may make sense to actually fix up the desktop side. So I'm excited to see as we kind of grow out, I think the PWA story actually works really well, much beyond mobile. It's definitely on the... It's definitely what we want to do. Let's take some questions from the audience. Okay, we spoke a minute ago about the gap between what was available in Chrome package apps and you specifically addressed sort of the distribution model, but there was also other APIs, of course, and some of them were very important in the educational space, so my company as well as others have built things for education using some of those APIs. Those APIs are not likely to have web standards implemented before the end of life of the Chrome Web Store. What do you guys think about a compromise of getting some of those APIs into just standard Chrome extensions that we can message as opposed to, you know, they were only ever in Chrome package apps, Chrome Serial, ChromeNet, things like that? So there are a lot of things that are difficult to bring to the web platform given its paradigm security model, but that seems like an approach that could work for some of those... some of those kinds of APIs. Again, with this, it's really... We love this feedback and to get thoughts and the APIs and use cases are really important to you. Yeah, I would just plus one that. I work with the extensions team who build the Chrome extensions platform and there's probably going to be increasing needs for extension APIs to solve some of these things. Okay, I mean, just the existing ones removed over with that same security model would be awesome. Solve some problems. He's saying security model. He's saying security model. Well, what would be helpful is... It's a small team. So what would be helpful is to know what the most important things are, and that's... I can't remember who gave the talk on it, but yeah, via feedback is... Okay, thank you. We have some of the product managers working on that stuff here today. Walking around, so... Yeah, I mean, I picked some of them already, but... We would like to ship those APIs on the other way as fast as we can, right? But we have to be very careful. It's very difficult to unship things from browsers. You guys are probably at that gap. Functionality means that there's going to be no functionality until the... when the Chrome Web Store goes away and the APIs don't show up as standard APIs. And we're aware that the time scales are different. That's one of the reasons we want to hear this feedback so we can figure out which things prioritize that transition. Thank you. My question is about HTML imports. They were mentioned a couple times today, and maybe just me, but I sense less optimism than I have from you in the past. Do you still think... Are you still hopeful that HTML imports will be supported by the browsers the way they are today? We've locked horns. Me and you have locked horns over HTML imports and what they should do, so you can take this one. As the proud father of HTML imports. Yeah. Let's see that, Brad. No, I think it's still a pretty cool primitive, and it does... it did advance a field of how do you do modularity on the Web pretty far. I do believe that there is interest among browsers to implement something like imports. And the latest proposal that I have so far is called HTML modules, which is effectively taking the semantics of ES6 modules and transplanting them to something that looks like HTML imports. And folks have been receptive so far, but right now our biggest blocker is actually shipping and getting ES modules out in the wild and trying to understand how this will actually work. One of the saddest things ever, I think, is that this is the first time we're actually going to be... This week. This week you're going to say something that's the saddest week ever. I'm looking forward to this. Let me roll those back. Rebase. One of the saddest things in the last 30 minutes is that we actually are not sure what the performance characteristics of ES6 modules will be once they're available because they are a brand-new primitive. And even though ES6 modules are used pretty widely in the developers build systems and environments, nobody actually has done a good performance characteristic analysis of ES6 modules. We actually have a running code in the browser we won't know, so that's step one. And once we have something good and we'll understand what is the next steps, we will start thinking about the HTML modules. And the precise timing of all the things that are loading across the wire when they're ready and what other things that are blocking on them. Some of the things that's been, when I joined the team, just crazy complicated. A lot of this was intuition in the beginning. And I think right now we're really like looking at what Sam was talking about, look at what Alex was talking about. We actually understand the space a lot better. So in a way my answer today would be no, HTML imports will not survive the way they are. But yes, there will be something like it that is better. Cool, thanks. Who's next? So a few years ago at Google I.O. it was showed off that Chrome tabs in the app switcher are treated like every other app. Now that's no longer the case what happened to that is that ever going to come back or is that permanently gone or what is going to be replaced? So we tried that model back then in the Android I.O. time is when they introduced the document mode it led the app to go into the system. And we adopted that we are first adopter from the app perspective but when we start to get it to the wild and then we realize it's not a lot of other apps adopting that model and for Android also some of major like devices like Samsung devices they don't have the quick affordance the recent button is not available there so that makes a lot of users now finding their tabs. So based on that kind of like feedback it is a kind of decision because we actually run this in the wild for like over a year but there was we're collecting a lot of feedback coming back we change back but we are going to reevaluate if you're looking at like today's Chrome I think we actually run the new it's like if a tab is opened by another app we actually will put it a similar as in the Android reasons. So we'll try to introduce this if you're using Chrome as a Chrome browser and all their tabs will stay in Chrome but if they're using like haven't spoke model that's what we call this like they're using say Twitter and click the link just to view the content and then that will show up and then one ahead of the back and then that will just go disappear. I think ultimately it's about user expectations and with that model every single site you visited even if it was like accidental or that celebrity gossip site that you aren't very proud of that one time is kind of there in the same mix. And I think the model that we're at now is in many cases users are just tapping around to a couple places they don't intend to come back to something like that but now as you grow a stronger and stronger connection to this when you add to home screen that's more of a strong signal of like no please promote this to be like a thing that is treated like an app. So I think to some extent this is like us exploring this space figuring out what works for users what works for developers trying to figure out the right mix for all of that. There was another factor if I could pile on. We introduced a feature called and prior to that some folks were flirting with using WebView for tracking content in their experience what we found with Chrome Custom Tabs is that people really like to they didn't want to intent out of their app into the browser because the users sort of got lost and didn't know how to get back to that app. But with Chrome Custom Tabs they had that X in the top left corner it's really easy to pop back to the app you're at so it works really well for this hub and spoke style of browsing but once you start to have a lot of experience and adopting Chrome Custom Tabs and I don't know about you but I've seen that more and more no longer do you have that experience where you sort of the segregation between the browsing that happens outside of Chrome and the browsing that happens inside of Chrome and so then we sort of that led us back to this model of well if I launch Chrome I want to be able to find all my tabs I want to be able to find the activities and the tasks I was doing there and then we thought well maybe we can even evolve the task management within Chrome that notion because it's actually really hard we can't evolve the task management of the OS in many ways we're just saddled with whatever old versions of Android implemented for that and as Grace said some old hardware didn't even provide a convenient affordance so anyways look for us to do some you know explorations in the task management space I want to be able to use voice just be like show me that celebrity side that you poked on on my computer come back this is a genuinely sorry when I started Google I just realised that every story I tell involves a bathroom and a toilet but this one does as well I started and went to the urinal and I saw that the person standing next to me was wearing Google glass and I just went okay glass take a photo and he just went dude works this is my question from the audience my question is about page performance earlier we talked about PWA and mobile performance and the need for having less JavaScript and less parsing a lot of times websites have this one megabyte of DOM size but the rest of the megabyte comes from the advertisements so the biggest challenge that we face on many websites page performance yeah I can go PWA, I can go offline but also we have users 2G, 3G what are your guidelines and how can we bring it out of the clear guidelines from the FP that allow us to say we don't really recommend you to put heavy ads or you know you have the AMP ad that's excellent you only allow certain type of ads to work so AMP pages are faster so what are your guidelines to make sure the ads somehow don't affect the main page flow and faster it doesn't impact the user this is a very complex area there's a lot of moving parts and we're focusing on, we're digging into it on a number of levels so in particular we're looking at ways to isolate third party iframe their performance from the rest of the page making sure they reduce them out, they can jank the page we've also implemented a few APIs and designed a few new web standards like intersection observer which is one of the things that many of these ads do like viewability calculations that many other things sites do much, much, much more efficient depending on the ads to go and do the right thing the ad networks there's usually a countably few in the case of the intersection observer a lot of them are using flash on desktop to measure position and so for example we've changed our public our plugin power saver heuristics to also target now that you can do intersection observer very, very efficiently we're actually changing the heuristics for plugin power saver to disallow small flash plugins which is one of the things you see on desktop that needs some performance problems in many ways we're looking at making some targeted interventions roll back the clock, remember pop-up blocking this was browsers intervening to try to help move the ecosystem to a better model you could argue whether that worked but the point is that things like what we're talking about here ways where we get involved, right and another example that we've been talking about is in the standards group is around blocking synchronous script that's injected through document.write a lot of times these analytics packages or ads will go and document.write one script and then another one and another one you get this awful soft-tooth pattern so we're exploring ways to kind of like say hey that's not okay, you don't need to do it that way how about we just start breaking that is that one in particular we're shipping I think very relatively soon on 2G connections we'll basically kind of ignore it won't wait for that document.written script and actually if you as a developer open DevTools on a page that does that behavior even if you're on 2G it will warn you by the way this behavior we might intervene in certain conditions to change this behavior there's a lot of other work happening in this space this is obviously a really complex situation because just like Rick and Robert came on stage and said we want this to be predictable and we're with our interventions coming in and saying hey we're going to break your randomly it's going to be great but if you don't know what the bad things are it does look like random so it's a hard problem but we are really interested in solving it we hear this loud and clear this is a really hard problem there's an exploration on GitHub as well looking at a spec where you can have an attribute on an iframe to kind of set some limits on it it's very early days and sort of how to attribute usage to a particular iframe or to a particular origin is not easy but it is we are looking at it because you're right so you can imagine saying this iframe can load no more than 3 megabytes exactly so a page can go one day it can be loading in 5 seconds the next day is 15 seconds so there's no telling and there's no way to monitor what comes in and what goes on absolutely last question from the audience I'm just kind of curious for some inside perspective on kind of the seeming contrast between Android Instant Apps and kind of that side of the house versus the Chrome team I realize that's good there you go I realize I'm kind of asking half the group here but I am curious kind of what your perception is of kind of the internal dynamics there because as you did so shall I go well I think that it's no surprise that the Android team is investing in Instant Apps right we talked a lot about low friction and how that's so valuable or friction and how that's such a problem and so they're on a path to try to figure out how to bring instant loading native apps to become a reality there's a lot of challenges there security model somebody said yes the reality is the reality is that we're all sort of thinking about the same sort of ideal model one where you can happen on an experience very easily discover an experience and then as a user choose to retain that experience and reengage with it easily and that active retaining additional powers and things like in the case of PWAs today it's full screen tomorrow maybe it's notifications and perhaps other things but the point is as a user you make a you discover content within the context of the browser or in the case of Instant Apps and similarly within the browser as you're following URLs and then you might as a user retain it and that makes that transition to being a thing that you're keeping on your device so in a sense we're all kind of converging on a similar model for computing but there are some fundamental differences between web and Android I was a betting woman I would bet on pdlba so that takes us quite nicely to a good last question what's the best way to convince my management to jump on PWAs because it's management that has the money it just makes sense cost wise if you think about just like iteration and updating I imagine that developers can have capture the cost of being able to update and evolve whatever product or service they have and how challenging that is on native apps probably one of the best reason examples of that was the big quiz right no one had to reinstall an app when you guys ran backstage just a native app would have had the same problems that we had today I just want to stress that seriously we have a number of case studies that are new today that Tau covered in her talk we're going to have a blog post a couple of days that summarizes it as well a lot of these things like that stat about the user acquisition cost for example these are very powerful to people who are making the business decisions in this the other thing to remember is I'm starting to see progressive web apps as a term it's coming up in press articles it's coming up at conferences imagine at some point if you already know these technologies know what it would look like for your company at some point someone from business is going to come to you and say what's this progressive web app thing and say here's an example of how our thing would look like I think the best thing you can do is probably today people aren't experiencing progressive web apps on a daily basis yet and sometimes it's really hard to imagine your site inside or what your site should look and feel like it's definitely better West Elm is such a great example they built a demo first got sign off and now they're going to do they did an early beta they're going to move public beta and move their site over because once you see something so amazing you don't want to go back I think you sometimes you just need that visual demo you don't have to take your entire site take a couple of APIs on their device so if you can take somebody 20% and build a demo or a prototype I think that's the way to go make it real, make it very concrete because abstractly people are like homescreen icons and offline but when they see it for real it feels very different I think that's a good note to end on can we have a huge round of applause for the panel so, Jake yes? hello Paul creeping in from the background there look what I've got Jake it's the real thing set it on the table it feels like it should have a this is tense I wonder if anyone in the top 3 is still in the room we're going to find out one way or another shall we get the big web cruise on the screen please here we go this is the moment of truth I'm just going to make sure wow it's still working it's just free here they are we have first place right come on up we haven't really told you big round of applause very high score of 47 that is a good score but the real gift of this is going to be that we'd like to take a commemorative selfie with you so if you hold that and let me look at the camera this is the main prize right commemorative selfie really this is hang on hang on yes so would you say your life has changed by this yes yes it's much better now improved are you happy with the spelling mistake we spelled your wrong we want it to be really we want to troll you every time you see it basically and obviously you're a GDE you're actually one of our experts which sort of feels quite fitting that is good because we nearly had Mozilla Deverel winning Poch did really well is Poch still here well that's good so congratulations again thank you very much a round of applause wow well that does in fact finish up day one imagine that in terms of the actual sessions for the live stream we always say goodbye to the live stream thank you very much for joining us see you again at 10 10am tomorrow but for the people here the party is just starting I think does that sound exciting we do want to apologize for the overcrowding that some of you have seen and experienced today not right now though but we do want to thank you for your patience and understanding and while we expect it to be a little less busy tomorrow we do actually have the place at 301 Howard booked as well so if we see lots more people tomorrow we have plans in place but now there's going to be drinks out there and then at 8pm we're going to have a live band on in here and then at around 9.25 if you want to stay around for that there's going to be a jam session jam sessions I've already played my saxophone it's your turn bring your A games alright thank you very much we'll see you 10 tomorrow