 Welcome, everyone. Welcome to Chrome Dev Summit. It's really awesome to be here with you all. We have over 300 of you here in Mountain View joining us live, as well as many people on the live stream. It's really fantastic. I also want to give a special shout-out to the live streaming viewing parties that we've organized in Montreal, Waterloo, London, and Paris. And to our friends joining us in Paris, I think I say this for everybody. Our thoughts go out to you. Thank you, everyone, for being here today. I just want to take a quick moment and reflect on where we've come with Chrome. So Chrome's been a product. We've had Chrome out for a long time on desktop, but on Android, actually, it's only three years old. It was in 2012 when we first brought Chrome to Android. And we've been working very hard to make it a much better product on mobile to make sure that we are building the best web platform we can to help developers reach users on mobile through the web. A lot of work's gone into Chrome. A lot of work's gone into making the web better. We're going to be spending time today, tomorrow, talking about that. We've also, Chrome teams also put a lot of work into the web view. And for users on Lollipop and later, it's the web view and Chrome. I'm very pleased to say that web view and Chrome both auto-update together. And that's a fabulous accomplishment. So we're very excited about the things we can do to make the web ecosystem stronger, as well as to make the web work better in the context of native apps. So I put this slide up last year. Last year, we had 400 million users on Chrome on mobile. We were very proud to share this. And this year, I'm pleased to announce that, actually, the number is doubled. We're up to over 800 million users on Chrome on mobile. So we're excited about this. Obviously, we've put a lot of work into Chrome. It's great to see users liking the product. But I think it's really exciting even more. So because it means web developers get access to this set of users with a modern up-to-date web browser that implements modern features on the platform. And it makes for a very large, addressable population of users for web developers trying to reach users on mobile. So we're going to get into some of that. But first, I want to spend some time talking about the web. And we talked about this last year, but I think it's worth highlighting. So the web has many, many virtues, things that are great about the platform. But one that really stands out is that it's low friction. And so it really stands out that it's low friction. And what I mean by low friction is that to a user trying to engage with developers, when it comes to the web platform, interactions are just a tap away. A user taps on an ad. A user taps on a search result. A user taps on a URL in a tweet. And they end up taking to a website. What does that mean? They're landing on the front door of the web developer. The web developer now has a chance to interact with that. The user presents some experience, allow the user to interact with their service, develop a relationship. There's no install friction. This is really powerful. It means that the experiences you can build can be presented to the user right away. There's no need to get them over some install hump. And so we're all about trying to make this work better. And I wanted to spend a little more time digging into numbers. So earlier this year, in June, there was a comm score report that was announced. And it had this sort of numbers that, on average, users have about 25 apps installed and that they interact with every month on their devices. When we look at Chrome browsing data, we see that on Android, users are opening over 100 sites every month. And what does that mean? That means that, well, it's not only four times larger, but it means that the users are interacting with four times as many developers, if you think about it. And this reach is really interesting, really interesting if you're a developer. And to put this into more perspective, of those apps that users are interacting with each month, 80% of that time is dominated by just the top three apps. This is also really interesting. And in that report, they looked at monthly unique users. They looked at the amount of traffic that these top sites and top apps are seeing. And so comparing the top 1,000 apps to the top 1,000 sites, they actually see this kind of disparity, that there's actually a lot more unique users reaching those top 1,000 sites than the corresponding top 1,000 apps. And this reach is really powerful, again. And it makes sense, given the low friction nature of the web, just to tap away to a whole new experience, just to tap away to the user being unengaged with the developer they never interacted with before. And the other fascinating thing that they reported on is that this disparity is growing. In fact, the mobile web traffic is growing at a much faster pace than app traffic by the factor of 2X. Again, looking at the top 1,000 sites compared to the top 1,000 apps. And then when you zero in on just the top 50 apps, you see that it's only the top 12 of those apps that have a corresponding site that actually enjoy more traffic on their native app than on their website. And these are the YouTubes, the Instagrams, the Pinterest of the world. Makes sense. But it's not very many apps that enjoy that sort of benefit. And so earlier this year, Flipboard put together and launched a whole new responsive design, mobile and desktop web experience. And they reported an astonishing number that they saw a 75% increase in their active user base on mobile, thanks to targeting the mobile web. I think this is really impressive. It makes a lot of sense, though, again, given the reach, given the low friction nature of the web. This is a great quote. All great apps need to be on the web, especially the mobile web. We totally agree. Chrome's focus is helping you all be successful at doing this. And so I think it goes without saying at this point, and it's obvious, that the web is critical, should be critical to your mobile strategy. Some of the strongest, smartest businesses today are targeting the mobile web. And you can see how that plays out. And so from Chrome's team's perspective, we're trying to make the web work better. This means figuring out how to make the web really work well on mobile. But I want to call attention to the fact that the web is not just Chrome. So although we have 800 million users on Chrome on mobile, and that's a very large user base, there's a lot more users on mobile. And we really care about the web being great. And that means that everyone should enjoy a modern web browser, a modern web platform on mobile. And so we're very committed to working with standards bodies, working with other browser vendors, working with web developers, working with others in the community to build new web standards features for the web platform that are built to last, that all their browsers are going to adopt, so that we can move the web forward in a very positive way. We've been having a lot of success here. And we're getting only better at working on building standards. I'm very excited about that. And so I want to take a moment to take a drink of water, but just a second. I want to talk about the things we've done to make Chrome better. We make the web platform better. And it's really along these axes, the axes of reliability, performance, and engagement. And let's just get into reliability. So when I talk about reliability, not just talking about, does it crash or not, I'm really talking about, can users count on the web working? Can they count on the mobile web experience being good for them? And when you think about mobile, what are you thinking about? You're thinking about unreliable network connections, flaking network, inconsistent access to the internet. And as we're talking about web apps, well, web apps are deployed over the internet, so they're reliant on the internet. And so this is an issue, but I want to say something crazy, which is that I think as a developer targeting the mobile web, we shouldn't assume a consistent network connection. We shouldn't count on that. And so with this in mind, we really set out to try to build enhancements to the platform that would make this the case that enable developers to reach users even in the presence of really poor network conditions. And our answer to this is the service worker API. It's something we talked about last year. And I'm pleased to say that this has been deployed in Chrome for some time now. And developers are creating great experiences on the service worker. And we're going to talk more about that a lot throughout this whole presentation today and tomorrow. But the service worker in a nutshell, so you have context, it allows a web page to designate a piece of script that would run outside the context of the web page. And that script has the ability to serve network requests on behalf of the pages, of your pages. It can control both resource fetching and caching. And it gives you the kinds of control you need to create a robust experience offline. Just so for instance, I understand that the Verge is live blogging this event today. And their live blogging app actually uses a service worker so that it can be robust. I think that it makes a lot of sense. You can imagine conference Wi-Fi is not always so hot. And being able to have access to such a tool in the presence of a poor network makes a lot of sense. So I encourage you to check that out. Another example that's really great to see is the Guardian. So the Guardian did something quite simple, actually. They deployed a service worker so that instead of a user experience being like what you see on the left there, Chrome's error page when you're offline, instead of a sad dinosaur, what you see instead is a crossword puzzle. So they're able to provide an experience that's interesting when you're offline. I think that's just a clever use of service worker and not terribly complicated to add to an existing web app. So another thing that's really great, like I said, we're seeing a lot of use of service worker and over 2.2 billion page loads per day through service worker. This is actually, this is great. And I want to call out that this is pretty evenly split across desktop and mobile. And for those in the know, this number does not include the service worker used by Chrome itself for the new tab page. The new tab page is actually a special variant of the Google home page that uses service worker. We actually use it in Chrome so that we can make sure that the new tab page is always fully functional whether you're online or offline. Now performance. I want to spend a little time digging in here. We put a lot of work into making the engine faster. And a lot of focus has been on understanding, characterizing performance. And when I say performance, I don't just mean micro benchmarks, JavaScript micro benchmarks. JavaScript performance is important. And I don't just mean traditional page load performance. What I really mean is the things that users really care about, responsiveness, interaction. When a user touches the phone and they tap on something on your application, it should be responsive. It should indicate that it's listening, that something is happening. Animations should be smooth, et cetera. So we've taken to characterizing performance with a metric that we call RAIL. And I want to introduce this. We're going to talk a lot about this today and tomorrow. And RAIL stands for reaction time, animation time, idle time, and load time. So let me just detail this a little bit. So reaction time. The ID here, the guidance is, within 100 milliseconds, your application should respond to the user input. It should indicate that something's happening. If it can't complete the task, then a progress indicator is present. Something so the user understands that I got this. I'm working on it. Animation time. This is the classic 60 frames per second, the gold standard. This means there's only 16.67 milliseconds to get work done. And that includes the work that the browser needs to do. And so we're very focused on making sure people understand how to achieve good animations in the presence of these kinds of constraints. And what that really means is making sure your idle work is managed properly. And our recommendation is the idle work is chunked up to units smaller than 50 milliseconds. This means that the idle work that maybe is happening in the background isn't interfering with your app's ability to be responsive. And we'll talk a lot more about how to manage that. And then, of course, the classic load time. And here we set a very aggressive goal of one second. You think about it. This is even the very first time a user navigates to your page. Being able to achieve a load time like this is important. It doesn't mean your whole application has to load, but it means that enough of your application should have loaded so that you can start interacting with the user and can start responding to them so that you can start showing progress according to what your app needs. And I think this is really important. There's, of course, tools like service workers such that allow you to manage your caches and make sure that subsequent loads are always fast, but even the initial load should be fast. And tools like HTTP2 and new protocols like Qwik, these are all designed to help here. So put it all together. These are the kinds of metrics that we're really focused on, the kind of user experience we're really focused on, things that make sense to users. And I think we're going to spend a lot of time helping web developers understand how to achieve good rail metrics. But also, as Chrome team, we've put a lot of energy into making the engine faster along these same axes. So this has been a big focus for us as well, just looking at Chrome itself. And so under the hood, I'm pleased to share some of the stats, some of the improvements that we've made. There's been a ton of work, and this is just capturing a few items. A lot of focused work went into V8 and the garbage collector. And on the whole, we're actually reducing memory, JavaScript memory by 10%. But on sites that use a lot more of JavaScript, actually the reduction is even more. And this just comes from being a lot smarter about how we're managing the garbage collection. And doing all this cleverly at idle time so that we're not interfering with the things that the page needs to do is all very important. We also made a lot of strides on startup time and power reduction. Power reduction, in particular, on Mac has been a big focus. Really delighted about that. So there's just some great stats. Moving on, I just want to call attention to AMP, the AMP project that was recently launched by Google. Accelerated mobile pages. And to put this into perspective, the way I look at it is it's a great prepackaged way of doing static content on the web that achieves great rail performance. So following this, it's like a guide rails to help you achieve a really good performance on the mobile web. So I'm very excited by that. And Polymer is a more general solution for achieving great performance on the web. Again, not only have we focused on making Polymer faster, but also Polymer includes a whole bunch of elements that are designed to enable you to have a very easy time creating web apps that are interactive, deal with large data sets, and so on in a performant manner, achieving great rail metrics. There'll be a lot more talk about Polymer later on. And so engagement is this last area of focus that we've had. And I want to call attention to what I really mean by engagement, which is re-engagement, helping users get back to your site. So it's one thing that they have an easy time finding you in the first place, but how can you help them re-engage with your website? And the two main areas of focus here are really helping you get onto the home screen and helping you re-engage through push notifications. These have been features that we've deployed, launched, and I want to talk more about them. So the one stat about home screen that I just want to call attention to is that we've seen a real rise in the efficacy of home screen icons. So in other words, we see a lot more traffic, 79% increase in launches coming from home screen icons to websites. And this all makes sense. It's what you expect. You expect it to be an effective access point. Indeed, that's true. So one thing that Chrome does is if a user engages with the website a lot, we'll actually promote to the user that they might want to add that site to the home screen. Now, this is caveat that the site has a service worker, has a manifest, and so on. But here's an example of such a site, sumo.jp. It's a real estate site in Japan. They see about 70% of their traffic. They have a native app to have a website. About 70% of their traffic is on the website. They integrate it with add to home screen, and they get this kind of experience. And a user who's using the site has an easy time putting the site onto the home screen, and it just works great for users of the site. Push notifications. This has been a big focus of ours. I think everybody understands what it is, but it's about allowing you sites to, web developers, to push notifications to Chrome that will then be represented to the user on behalf of your site. So on the left here, you see Facebook who rolled out push notifications to everyone, asking the user to accept push notifications from Facebook. And then on the right there you see on the home screen of Android a notification from Facebook, and below that you see an eBay notification. eBay is also working on integrating with push notifications in Chrome. This is very exciting. And in particular, Facebook, a couple months back, had their at scale conference where they had this presentation. And they were talking about the mobile web and so on, and the work that they've done to improve the Facebook.com on the mobile web. And they had this slide up that I just want to read to you. It says, mobile web matters. Mobile first cannot mean native only. And we totally agree this resonates absolutely. It's great to see this. And another great example of how effective push notifications can be beyond the rack. So this e-commerce site deployed push notifications in Sol, some really great stats of the users to re-engage with their site through the push notifications. They spend on average 72% more time on the site. And they spend 26% more money on the site. This is pretty great stats. And it's not surprising because you can imagine that they're able to deploy very targeted and timely notifications to the users. And we're seeing quite a large volume of notifications flowing through Chrome up to 350 million push notifications every single day. Just a month ago, this was 250 million. So it's growing rapidly. And across the world, we're seeing about 2,300 sites using push notifications. And this is also growing rapidly, which is great to see. So I feel like all of these technologies put together can really transform the mobile web and transform people's expectations of the mobile web. The idea that mobile web experiences can be reliable, can be resilient to poor network conditions. The idea that they can be fast, fluid, interactive, responsive. The idea that engagement can be strong. The idea that you can be on the home screen. You can have push notifications. The experiences you can create on the mobile web are just profoundly better. And I think this is very exciting to us. We're very excited about the kinds of experiences people are creating with these technologies. And it really reminds me back to well over a decade ago when, at that time, pages were very static. People tap on links and a whole page would reload. Think of MapQuest. You pan left or right in the map and it reloads the entire page. And what did people discover? They discovered Ajax. They discovered the XML HTTP requests and so on that they could use these technologies to incrementally update pages. And with that ushered in a whole new sort of decades worth of innovation on the mobile, on the web. And I feel like some of this stuff that we're talking about here with ServiceWorker really has the chance, the opportunity to really transform people's expectations on the mobile web in a similar fashion. I'm very excited about that. And so as we've been talking a lot about this, we've been taken to calling these web experiences that people create progressive web apps. So I just want to introduce this name because we're going to be talking a lot about it throughout the rest of the conference and beyond. So progressive web apps. I think this name works because you think about progressive enhancement. As these websites, you build to take advantage of ServiceWorker. Well, they work better on browsers that support to ServiceWorker, obviously. But the experience still works on an older browser. So your investments are there and you add the new features and the application is progressively better. Or you think about a user who's interacting with the website more and more and the experience is progressively better. As the user adds the experience to the home screen or the user enables push notifications, the experience that they can get is progressively better. Or you just think about the fact that these experiences that developers can create progressively better experiences overall. So I'm very excited about progressive web apps and the kind of experiences that people can create using the technology that we've developed. And I just want to call attention to one such example, which is flipkart.com. And they are one of the major e-commerce players in India. I think one of the things that folks may be familiar with is that earlier this year, they famously turned their mobile website into just an ad for their native app. But shortly after that, I think some developers there got very excited about rethinking their mobile web experience and looking at features like Service Worker and some of the other work that has been going on in the web community. And they started rebuilding their mobile web experience around these technologies. And I'm very excited to share with you flipkart.com, which just launched last week. So I'd like to roll the video now, please. It's like you to pay attention carefully as you watch this video here and notice some of the animations and the interactions and notice how smooth they are and how fluid they are and how quickly the application is experienced. Even when the data is not there, it's changing state. It's showing progress. Something is happening in response to your interactions. It's always very responsive to you. And now we're going to tap on this. And Chrome is prompting to add to the home screen. And you see the icon appear on the home screen. And then when we launch from the home screen, what we actually see is a full screen experience. Gone is the location bar of the browser. So we can flip back to the slides. And I just wanted to call out some of the tweets that we're seeing. First off, this experience is very delightful to people. And you see some of these tweets. For example, if you've not checked out flipkart.com in Chrome, you're missing out on the future of the web. Flipkart Lite is the fastest web application I've ever seen. Or flipkart.light is working as smooth as butter, even on 2G. Awesomeness. Awesomeness, indeed. I really agree. And I encourage you all to check it out. It's really impressive. And flipkart's actually here that they're going to give a talk later today detailing and getting into some of the details of what they built. It's very exciting. And so flipkart's a great example of a mobile web app that has really taken to heart these sort of things. They build a very reliable experience, a performing experience, an engaging experience. And in a marketplace like India where network conditions are so poor, actually the fact that it works so great is really impressive. The fact that they're built an experience that not only is resilient to poor network conditions, 2G connections, but they're also built an experience that initially works well, even on such networks. It's very, very cool to see. And so I think the theme here is that Chrome Team is working really hard to try to help you all be successful in the mobile web. And we're going to get into a lot of details about what we're doing along those lines. We have a lot of different talks lined up to share with you on how we're trying to help you be successful. And in particular, I want to call out, in addition to libraries like Polymer and AMP that I showed before, there's also tools like DevTools, which are a lot of work going there to try to help expose rail metrics and so on. But also documentation efforts like Web Fundamentals and MDN, we actually contribute a lot to MDN to document all the new APIs that are on the platform. Very excited about that. And I just want to emphasize this education point by giving an example. So right here, I have a stat. So we did an experiment. We studied the effectiveness of Chrome's auto-fill, the auto-complete feature. So as you're filling out forms, Chrome will suggest contents of those forms for users. And actually, this feature increases people's form submission rate by 25%. Pretty darn cool. Turns out, though, that Chrome is guessing what to put in the fields. And sometimes, I think we all have experienced this, Chrome gets it wrong. Browsers get it wrong. And user has to go and frustratingly fix up what Chrome or the browser put into that field. Turns out there is a feature of HTML5 which developers can use. They can add an auto-complete attribute to all the input fields, and they can tell the browser exactly how to interpret those input fields. And this makes these auto-complete, the auto-fill features perfect. Because the developer knows best what the intent of those fields was, browser shouldn't have to guess. And so with education, we have the ability to get people to realize that they can make changes to their websites that would dramatically improve, for example, the chances of a user completing a form submission. And I think that's really interesting. So I want to call attention to another thing, which is today, Google and Udacity are teaming up to offer a web nano degree. This is very exciting. So it's all about helping developers learn the best practices on how to create. We leverage all the technologies that we've been talking about, the ingredients that go into creating a great progressive web app. Very excited about this. Please check it out. And so what's next? Well, as I was saying, we have a lot of content for you today and tomorrow. Today is going to be all around detailing how to build progressive web apps, getting into the tips and techniques on that, as well as detailing and previewing some of the new features that are coming. For example, the Bluetooth API. And then tomorrow is going to be all around performance and tooling. And then looking out further, it seems like we should do this more often. So we've actually decided to hold this conference twice a year. So we'll see you again in six months, next time in Europe. Thank you very much.