 Hi, everyone. My name is Tal Oppenheimer. I'm a product manager on the Chrome team. And I'm here to talk to you about how you can use all the technologies that we've learned about today to make sure that your experiences can work for billions of users. So when we're talking about billions of users, that's a pretty big number. And that means that we really need to think about how can we reach all of our possible users. And one of the really critical things here is to figure out who your users are and to actually understand how they'll be accessing your experience and what this means. Now for a lot of us, we spend a lot of time thinking about what product problem we're trying to solve and who we sort of have this mental image in our head of who our user might be. And for many of us, this can look a lot like us based on just what you're used to and the experiences that you've had. And this can lead to a perception of the world that looks something like this. And now we are in Amsterdam, so a few of us might be thinking a little bit outside of the United States. And you can throw sort of Europe in there as well. But this isn't the whole world by any means. And it's definitely not your user base when you're thinking about all of the internet users. So today, there are roughly 3.3 billion users using the internet around the world. And if we actually drill down and look at where these users are, this is a map of internet users today by country. And you'll see that while there are some users in the United States and some in Europe, we see much more pronounced number of users in a lot of these other areas. So while the US has about 286 million internet users, India has 462 million internet users, and China actually has almost as much as the two of these combined with around 721 million internet users. But what's really striking here is not just where the internet users are today, but looking at where the growth is coming from. So if you look at a snapshot over the last year, you'll see that in the last year, a lot of internet users came online in one very specific country. And this is India. So we saw over the last year that 108 million users came online in India alone. And for India, this was actually a growth of 30% year over year compared to the number of users that they had before. And this growth was 10 times more than the growth we saw in China in terms of absolute users. And over 100 times more, the growth we saw in any other country over the last year. And just to put this in context, this growth in India in a single year was equal to one third of the United States' entire population. And that's just in one year. And what's more is actually if we look at who's not yet online, and where we sort of predict that the growth will be coming from, we see the shift away from the United States and Europe to other countries. So in India, you still have 864 million users not yet online. The current user base, there's still 65% of India's entire population not online. Or over 20 times the number that's not yet online in the United States or similar areas. And so this sort of question can come up, how do we reach these users? If we need to be sure that we're building for all of them and thinking about all of them. And as I mentioned before, what's really critical here is to understand your users and understand who they are. So I know we've been sitting for a little while, but just with a quick show of hands, how many of you remember the first time that you accessed the internet? Okay, looks like most of us do. Now, keep your hands up if that was on a mobile device. Okay, we've got no hands up at this point. So most of us probably accessed the internet for the first time on a desktop machine or maybe a laptop. But when I was in India last year, we spent a whole lot of time talking to internet users who maybe knew where to the internet or had been using it for a fair amount of time. And I was sitting down with a woman who was sort of in her mid-40s, we were sitting in her living room and I asked her the same question. If she remembered when she accessed the internet for the first time and what device she used to access it. And her answer was yes. She did remember the first time she used the internet. It had been earlier that year. She borrowed her husband's cell phone and accessed the internet for the very first time. A few months later, she got her own cell phone and was now able to regularly access the internet. And so what this means is that how people are coming to your experience and interacting with it is just fundamentally different. We've heard the mantra mobile first probably a number of times. And for us this often means thinking about design mobile first, thinking about how our experience would work on a mobile phone. But for a lot of these users, how they're actually accessing with the internet, isn't necessarily mobile first. It's actually mobile only. They haven't had an experience on a desktop or a laptop computer. And they may not be using one regularly and they may not even in the coming years be using one regularly. So in terms of how they'll be interacting with your experience, it is only gonna be on that mobile phone. And so this means that you really need to think about what your experience can be like for users who may not have had experience interacting with your product on other platforms and making sure that you're still designing for that in mind. But beyond just the sort of using mobile first, this means that it's also really important for us to think about what the device that users are using are like. So taking a look at one device, this is a device that some of us might have in our pocket. This is the Nexus 6P and it was released in 2015. So last year, it's a pretty big device, 5.7 inches measured diagonally, and has three gigabytes of RAM. And then depending on how much you wanna buy and how much you feel you need, it can have either 32 to 128 gigabytes of storage. Now in comparison, when we were in India, we went to a number of stores and actually asked the shopkeepers, what device do you sell? What device do people ask for? What would you recommend for me? And this is just an example of one device. This is a Samsung J1. And this device was also released in 2015. It's 4.3 inches measured diagonally, so a bit smaller. It has 512 megabytes of RAM and 4 gigabytes of storage. So these are two devices that were released in the same year but have very different specs. We see one sixth of the RAM and even in the best case scenario, one eighth of the storage capacity. And this means that the user is gonna be accessing your experience on their mobile phone under a very different context than the phone you might have in your pocket and the phone that you might be testing on and seeing what your experience looks like. And now the difference in context goes beyond just the physical form factor of the device that they're using. Because they're relying on cell phones, this also means that cellular connection is their primary way of accessing the internet fairly often. Now, many of us are probably used to accessing Wi-Fi, we've connected to Wi-Fi here, probably sometimes complaining about its speed. This isn't necessarily the case for the users. And it's because you're relying on something that's in your pocket, as you move and shift scenarios, so does your connection to the internet. And you need to keep this in mind when you're building experiences. But this phenomenon is happening all over the world, we also see that in the United States, 20% of US households rely only on cellular data when they're making connections to the internet. And what's really interesting is that this number's actually doubled since 2013. So we're seeing this increasing. So the reliance on cellular networks as your primary way of interacting with the internet is increasing across the globe. And this has some consequences when you're thinking about the conditions that someone is trying to access your experience under. Now we've heard a lot about sort of slower connections and the impact this can have, but we see that globally, about 60% of mobile connections are 2G. And this is just actual 2G connections. It's not necessarily talking about 2G-like speeds, which can actually be even larger. And when we start thinking about the areas where people are coming online for the first time, we see this more pronounced at about two thirds of the connections. But what's more is that, while we're seeing this decreasing, we're not seeing this decreasing at a very fast rate. The predictions, if you sort of estimate it out, is that by 2020, one-fifth of the connections globally will still be 2G. And again, this is still excluding those 2G-like speeds. So the problem of connection speed is gonna persist for the foreseeable future. And we've seen some stats about this before, and it's sort of widely accepted that a delay in your experience has a very large impact on how users experience your site. And we've seen that a study found that one single second delay in your page load time can lead to 11% fewer page views or a 16% decrease in customer satisfaction if we're talking more qualitatively. And so that 2G connection that might have very slow round trip times, if that impacts what your experience is like for the user, is likely to have a very negative impact on how happy they are with what you've built. But beyond just the connection quality that is introduced by users relying very often on cellular connections, cost also starts to play more of a role here. So looking at India again, and doing an estimate of sort of minimum wage, minimum wage in India is a little bit complex as it depends on your job role, et cetera, and looking at how expensive a data plan is. With some simplifications, we see here that on average, you would require 17 hours of minimum wage work in India to purchase a 500 megabyte data plan. And we're all, we've been thinking about the mobile web, so just to put this in context, looking at sort of the average size of a web page today, if a user in India receiving minimum wage were to spend that entire paycheck on just data, just to access the mobile web, one hour of minimum wage work would load about 15 web pages. And just take a moment to think about how many web pages you've visited today or even visited during the last talk or during this talk, and think about how many hours you would have had to spend to be able to afford that. And what this really means is that the cost of data requires a trade-off. If they use one thing, it means that they're not using something else. And they're constantly making these trade-offs to make sure that the data that they have is used in the best way possible. And this results in the frequency of their connectivity really varying. When data costs are so high, you need to make a choice if you're gonna use one thing or the other, and sometimes you just wanna turn it off altogether. One user that we spoke to actually said that on an average day, they turn airplane mode on and off 12 to 15 times, because when you're not using your phone and you put it to the side, if data's this expensive, you wanna make sure it's not getting used unless you find value out of it. And this means that if you're trying to get a user to interact with your experience, you really need to make it worth it for them, because they need to be willing to pay that amount to just access that experience. And so this might be a little bit daunting, right? These are a lot of different constraints and conditions under which people are accessing the internet that you may not be familiar with firsthand. And so you may be posing the question, great, people are using mobile-only devices, connections can be intermittent, they can be slow, and when they do exist, they're really expensive. So what can I sort of do, and what does this mean for how I develop? So some of the methods that we think about might be a little bit hard. Under some of these conditions, installs become really challenging, because what you need to do here is convince a user to pay the time and data costs to install your experience before they've even tried it out. And this can be really hard when the costs are so high and the networks are slow, because it can take sometimes hours to download a single app. And what's more, if the device has limited storage capacity, your APK size starts to be really, really important. You need to start to make sure that it's small so that a user doesn't have to delete photos or videos or other apps on their phone to make space for your experience. And what's more is even beyond this first step, you're probably working to improve your experience, which probably means you want your user to update their app, and this is, again, once again challenging because they need to take that extra step on that slow connection or expensive connection. But you're all here. You probably all know that there's an app that solves a whole lot of this. The mobile web, as we know, solves a lot of these things just inherently and how users interact with it. With the mobile web, as soon as they navigate to your experience, they see your experience. They don't have to take an extra step before they try it out. They got there, they see it, they can try it out. This also means that storage constraints for that initial interaction are non-existent. Just by virtue of finding it, they can see it and start using it. And it's always up to date, so as you continue to make improvements on your product, your users get them right out of the gate, and they don't have to go take an extra step just to see the latest and greatest that you've built. But as you know, we've been talking a lot about the reach that this introduces. And what we've seen, these are some stats that we talked about last year, is that removing these barriers has a real impact on the reach that your experience can have. We see that on average, users navigate past 25 apps per month, and this is compared to over 100 websites that a user will navigate past on Chrome on Android in a single month. And this not only is a breadth of experiences that users pass by, but has a real impact on the number of users that a single experience has. So looking at the top 1,000 mobile apps and the top 1,000 web websites, we see that on average, there is 2.5 times as many users on the mobile web as there is on these top 1,000 mobile apps. And what we're seeing is that mobile web is also growing at two times the rate of native apps in terms of numbers of users in these same buckets of top 1,000. So really what this means is that the web inherently provides you a whole lot of reach. And we've been talking a lot about today is how you can use progressive web apps to not only leverage the reach that the web inherently has, but to build experiences that really work well for you and for your users so that they highlight and have all the capabilities that you need to build the best possible experience and for your users to get the best possible experience. So I'm not going to focus on this too much because you've heard a lot of this today, but progressive web apps overall not only offer a very smooth experience, but they also offer a lot of options for how to support some of these other situations that you really need to think about when you're building for billions of users. So how can you leverage progressive web apps to actually reach and build great experiences for users around the world? So the first is cost. We talked about how cost can be very limiting for users to even try out your experience for the first time. So we'll talk about how you can leverage progressive web apps to really remove that barrier. And second is connectivity. When you do interact with these sort of flaky connections, how can you address that to make sure your experience is still as fast as possible? So you're not incurring that one second delay that has a huge impact on users' experience. And finally, how can you make sure that you're making the experience as simple as possible and just removing as many extra steps that your users may or may not need to actually take so that things continue to be fast and efficient? So to jump into the first one, cost. Now on Chrome, we've been working on addressing this issue across the board. So we do have a Chrome data saver. This is a proxy for HTTP content that a user can turn on. And with functionally no fidelity change, users can see up to 60% data savings. But we've taken this a step further because we know that cost can be very constraining for some of our users. And we've actually decided that on slow connections for HTTP content, we will automatically replace most images on the pages with placeholders. We maintain things like navigation icons, et cetera, so users can continue to load the page. But at this point, the user's in control of where their data goes. So they can choose to load all the images on the page. They can long press on a single image to load it if they need it. But we're not using their data without their knowledge and without them needing it. And we've seen that we were able to increase data savings to over 70% in some of these situations. But we also know that this doesn't necessarily work for all experiences. And so there's also a number of client hints that you as a developer can use to make sure that you're optimizing the experience for the users based on the device that they do have. So with DPR Width and Viewport Width, you can make sure that you're only sending the image size that you need to the users and so that they're not incurring data costs for something they may not be using or may not actually need. What's more is we've also launched a save data header. And in Chrome, this maps directly to whether the user has that data saver had feature turned on or not, which means that you as a developer know which users are the most data sensitive and can adapt your experience accordingly and can do so in the way that works best for your product. So maybe that means only loading one key image that's critical for it and making the other one sort of on demand for the user or not auto-playing video or whatever it might be that makes sure that you aren't removing constraints for the users who need it most while still making sure that your experience works for them. But we also know that this can be challenging and there's a lot of optimizations to go on. So we also have the PageSpeed module, which is a server side component that you can actually drop into your web server that will do a lot of these optimizations for you. And if you drop this in this, it can do the optimizations on both HTTP and HTTPS content with functionally no fidelity change. So it's similar to that data saver feature that we have on Chrome overall, but you can do it on all types of content. And what we've also done is we've actually gone a step further so that for the users who have data saver on, we do a few extra optimizations to make sure that we're really doing as much as possible to help those users who are feeling sort of most constrained or who have expressed interest in us saving them even more data. So just to give an example of this, this is an example of a Monk storefront that we built. On the left, you'll see a screenshot of the store with no PageSpeed. And on the right, you'll see it with PageSpeed. Now these look really familiar and very similar. If anyone can point out any differences, let me know afterwards, but they look functionally identical. But there are actually differences when you dig into this. So if you look at the one on the left here, this is 350 kilobyte paid. So it's relatively lightweight compared to the sort of the average website across the board. But simulating a 2G connection, this page can take over a minute to load. And as we know, waiting is bad. It causes a bad user experience. It causes your metrics to hurt. And you really want to reduce that as much as possible. Now by just having the optimized for bandwidth in PageSpeed module, what we see is that we are able to actually shrink this to 165 kilobytes or about 50% fewer bytes. But for users who have data saver on and we go even further, we're actually able to shrink this to 120 kilobytes. And what's more is on the same simulated 2G connection, we actually drop the load time to under 30 seconds. And this is functionally with no fidelity change to the user. The user is seeing the same thing, but you are saving them data and saving them time just by dropping this one line of code in. And what we're seeing is this is just one example, but we've seen that on average, even for users who do not have data saver on, we see about 37% data saving with no fidelity change at all. But beyond just removing cost and decreasing cost that comes with data usage on mobile, in connectivity is really important and you need to make sure that things load as quickly as possible. So just to give a sense of how these things can vary based on connection types. So round-trip time or the time between making a request and actually getting a response varies pretty drastically between all these connection types. At one extreme, you often see sort of 50 milliseconds, round-trip times on Wi-Fi, I know conferences can be different, but at the other extreme, you have sort of 50 times slower on an average 2G network with 2,500 milliseconds round-trip times. And so this can be a little bit daunting, what can you actually do about this? So the first thing you can do is downlink Max actually offers you a way to know which connection type in the first place your user is actually on when they're accessing your experience. And you can subscribe to updates. So if a user switches connection types, you as a developer know and can make sure that you're giving them the best possible experience and not incurring any of those delays that might otherwise happen. But what can you actually do about it when you do know, okay, my user is now on a 2G connection? So we've heard a lot about Service Worker today, right? We know it's a client-side proxy and written in JavaScript and you can use it to support offline and all these things. But you can also use it to make sure that your experience is as past as possible. So Jake this morning talked about Wi-Fi or the experience where your phone thinks it's connected, but you as a user are not actually getting anything and this can be incredibly frustrating. This isn't only those sort of really flaky intermittent connections, but this can also be the case when you're on a really, really slow connection and the round-trip times are just so large. And so what you can do here is with Service Worker, you can actually implement request time-outs to address these flaky connections so that if a user is on that really slow connection, they're still getting something very, very quickly and they're not waiting for it to load. But we do know that sometimes there's no connection, right, we've seen this offline down to a lot today when we've been talking about Service Worker and we're really trying to make sure that you all have all the tools you need to kill the offline dyno and make sure that when a user goes to your experience, they're never gonna see this offline dinosaur. But there's been a lot of interesting ways that we've seen people who have been leveraging progressive web apps address the offline situation in a way that addresses the flows that are most critical to them. So just as one example, this is Conga. Conga is one of the top e-commerce sites in Africa and they will actually be talking a lot more detail about their progressive web app tomorrow. And what they've done is they've built a checkout flow that can work completely offline. So for users online and add some things to their cart and then loses connectivity or goes offline or turns on airplane mode for whatever reason it might be, they've actually adjusted their flow so that instead of having an online checkout flow, it has sort of a call to order flow so that the user can still complete the transaction or the flow that's most critical for their product in a way that works regardless of their connectivity type. So they've really taken their time to think through what is the critical use case for our users and how can we actually let them complete that use case even if they have no connection. And what's more, they've actually found that for that critical flow, this has shown a lot of improvement. So compared to their previous mobile website, this used 84% less data. And so addressing a lot of these speed connect issues also has a benefit of addressing some of those cost issues that we talked about earlier. What's even more is that compared to their native app, this new flow actually used 82% less data. So this has been a drastic improvement, not only to their previous mobile website but also to their native app experience. And again, they'll be talking a lot more about their overall work tomorrow morning, so feel free to come to that. But beyond just trying to address connectivity and cost, removing complexity is always a good thing. Making things easier is always just gonna be better for your users. And when we're talking about users that are sort of coming online for the first time, every step you're asking your user to take is time and money because on those 2G connections, every page load is just gonna be sometimes minutes of waiting. So if you're giving them a page load, you need to make sure that page load provides value. And if it doesn't, get rid of that step. And there's a few ways that we can make that happen. So we've talked a lot about add to home screen and how you can use this as an easy way for users to get back to your experience. This can also be used as an easy way to cut out steps for your user so that users who are more engaged and have expressed interest in your site can with one tap get right into your site. They don't have to take extra navigations, wait those five, 10 minutes, spend that data on those page loads just to get to your experience. They can tap on it straight from their home screen. But beyond that, with the notifications, you can also make sure to deep link them to specifically the part of your experience at the most critical times so that they're not taking extra steps even within your product experience to get to the part that might be most relevant to them. So this means that regardless of what their connection is or their cost is, you've just removed steps and they don't have to wait that extra time unless it provides value to them. But one of the things we talked about is that it can be really hard to try this out and make sure you understand what it's like. And so there are a few tools you can use to actually test this experience directly and make sure you're testing it with a global perspective and under all of these different situations that maybe aren't what you have in your pocket or what you use on a daily basis. So we do have a mini mobile device lab and it's up on GitHub and so this will let you simulate a bunch of different devices so you don't have to go out and buy a million and a half devices, but you can make sure you're simulating your experience on all of these different devices to see what users who use devices that are very different for yours are actually experiencing. But what's more is you can actually use DevTools to understand the cost of your experience. So just to walk you through one thing here, so we've talked a lot about DevTools but I wanna call your attention to the network piece specifically and so you'll see a button at the bottom here that actually lets you know what the payload of your load was. And so right now it's started sort of pretty light, 785. If we look a little bit more into this we notice a lot of things came from cash so probably why it was pretty light but you can actually just go ahead and hit refresh here and now you'll see that sort of on a fresh load this was actually quite a bit heavier and so it was over 200 kilobytes and so this is just one example but you can use this as you're navigating through your experience to get a sense of like, okay, how many megabytes is a user using if they're actually actively using my experience? But going beyond this, you can also use this to understand the time and how much time users are spending on just waiting for your page to load. So you'll see the time down here right next to the megabytes but what's more is you'll also notice that up here you can throttle it and change the simulated network speed so that you're not relying just on your wifi to see how the page load actually happens. So if you'll see that if we change this to 2G this actually starts going from 600 milliseconds that we saw before to roughly 11 seconds for just this page to load. And what you can do is as you adapt your experience as you use service worker and now these other technologies that we've talked about you can see how this changes and make sure that you're really optimizing for experiences and that you're building an experience that you would be happy to use if you were actually facing sort of some of these other conditions that you might not have firsthand experience with. So the main idea here is that by keeping sort of three principles in mind you can make sure that the experience you're building not only leverages the reach of the web but also takes advantage of progressive web app technologies to build the best possible experience for your users across the board. And we have a lot of different technologies and details about how you can apply these not only for progressive web apps but specifically to address the needs of billions of users online. So feel free to go there for more details. But the big takeaway here is that just by keeping in mind the fact that not all users who are using your experience look like you and are accessing the experience under similar constraints you can do a whole lot to make your experience much more accessible and as a result have a much larger reach and have the potential to reach billions of users. And so with all of this you can really build an experience that is built to work well for everyone. And with that I'm gonna hand it over to Chris Wilson to wrap it up for the day. Thank you very much. Thank you.