 Hi, everyone. My name is Tal Oppenheimer, and I'm a product manager on the Chrome team. And I'm here to talk to you about how you can use the web to build experiences that work for billions of people. We know that the way we access the internet has changed. A lot of us probably use the internet for the first time on a desktop machine. They were big machines. Over time, maybe these machines got smaller, could fit on your lap, maybe in a backpack. But today, a lot of us regularly access the internet with a smartphone, something that's in our pocket and goes around with us everywhere we go. And we see this trend happening everywhere. On Chrome, we recently announced that we actually crossed the $1 billion mark on Chrome Mobile specifically. And so we're seeing that more and more people are accessing the internet on different form factors than what they had been before. And what this means when you're actually trying to build for billions of people is that if you want to reach all the users, you need to think about where the users are and where they're actually accessing the internet and the experience that you're building. And part of doing this means you actually need to understand who your users are and under what conditions they're going to be accessing your experience. Now for many of us, when we're building our product or trying to address a specific user need that we're building for, we have a mental image of who our user is. And sometimes this can be in part based on research, but also inevitably based on your own personal experience and what you're used to and what you've experienced. And for a lot of us, this can result in a world that looks something like this. And now for a few of us, we might be thinking slightly outside of the US and you can throw Europe in the mix there too. But this is not actually what the world looks like, especially when you think of internet users. So today there are roughly 3.3 billion internet users. And that's more than 10 times the population of the United States. So if your mental image looked like that picture of the globe, that's really just a small piece of the pie when you're talking about billions of users and really trying to reach all of those users. So what's really critical here is when you're thinking of new users for your experience and for your product, you really need to think globally and think about the users all around the world. And when we look at where the internet users are today, this is just a chart of looking at internet users in 2016. This maps countries and the darker the country, the more internet users today. And you'll see that while the United States is pretty prevalent here, there's about 286 million internet users in the United States, you'll see that there's a number of other countries that start to be very dominant here as well. India has almost two times this many users online today with around 462 million internet users. And China actually has almost as much as both the US and India combined with 721 million internet users today. But beyond just a snapshot of where internet users are accessing the internet from today, what's interesting to see is how this has changed. So looking over the last year, this is a similar chart, but this is looking at just the pure number of users who came online the last year by country. And what you'll see here is that there's clearly one country that's quite dominant in this particular map. And we see that in India, we had 108 million internet users come online in a single year. And for India, this was a growth of 30% year over year in their internet population. And that number, that 108 million, that's 10 times the growth that we saw in China. And over 100 times the growth we saw in any other country over the past year. And so this is an immense number of people. But just put this in a little bit of context. So 108 million people, that's roughly one-third of the United States population that came online in India alone over a single year. So that's a huge number. And so when you're really thinking about who your internet users are and who are the sort of pool of possible users for your experience, you need to think about a lot of these areas. But beyond just where we're seeing the growth right now, you can also sort of project this out to see where we expect growth to continue to come from as you're thinking through your roadmap and the experiences you're going to be building. And so taking a look at the users who are not yet online by country, you'll see that here we see more of a representation of different countries. But we see that over 65% of India's population is not yet online. And that's 864 million people, not yet online. And there's a number of other countries that still have quite a large number of people who are coming online. But you'll see that some of these other areas, like the United States, for example, is just a much smaller pool of potential new internet users. And so the growth that we're expecting to see for internet users and people who have the potential to access your experience is shifting away to some of these countries that we might have more direct experience with. So great. Hopefully, I've shown that there's enough growth in a lot of these areas that we need to think outside maybe the countries that we have direct experience with. And so the question comes up of, how do I actually reach these users? And as mentioned before, one of the really critical things when you're building for any user is to understand who your user is, what are the challenges they face, what are the conditions they face, and make sure that you're taking that into consideration when you build your experiences. So with a quick show of hands, how many of you guys remember the first time that you accessed the internet? OK, it looks like the majority of folks in the room remember that. So keep your hand up if that was on a smartphone. OK, no hands. So most of us access the internet, I assume, on a desktop or a laptop machine for the very first time. And last year, I spent a lot of time talking to users in different areas. I spent a good amount of time in India. And we were talking to users about their internet use, about how they use Chrome, how they use mobile, how they use the internet overall. And I was sitting in the living room with a woman who's sort of in her mid-40s and asked her the same question. If she remembered the first time she used the internet and how she accessed it. And her answer was yes. She used the internet earlier that year for the very first time because she had borrowed her husband's cell phone and had tried the internet out. And then a few months later, she got her own phone and was now accessing the internet on a regular basis. And this is just one example of how people are accessing the internet. And it's just fundamentally different than what we have personally experienced. And so what it really means, we've probably heard the trope mobile first a number of times. And for a lot of us, that means when we're designing and building experiences, don't just think about porting what you've built for desktop over to mobile, but actually think about the design mobile first. But in a lot of these areas, it's not really just mobile first, but it's actually mobile only. It's not that people will be accessing your experience on mobile and you want to make sure it's good. That might be the only time they see your experience. They're only interaction with it. Maybe they've never used a desktop before. And there's also a chance that they never use a desktop or a laptop. So you can't assume that they're going to be using these other platforms to access your experience. And so you really need to make sure that you're designing an experience that works for a user who is only going to be interacting with it from their smartphone. And if people are interacting with your experience on their phone, it's probably important to consider what their phone actually looks like. So a lot of us probably have a phone or several in our pocket or bags. And this is the Nexus 6P. So in terms of looking at the Nexus 6P, this was released last year in 2015. It's a pretty good size phone. It's sort of 5.7 inches, measured diagonally. It has 3 gigabytes of RAM and 32 to 128 gigabytes of storage, depending on how much you feel you need and what you purchase. Now just to give a comparison point, when we were in India, we went to store owners as well and just talked to them and asked, what devices do you recommend? What devices are people asking for? And this is just one example of a device that folks brought up. So this is a Samsung J1. This was also released in 2015. It's 4.3 inches, if you measure it diagonally. But it has 512 megabytes of RAM and 4 gigabytes of storage. So what this means is looking beyond just the size of the physical device, the actual specs of these devices can look quite different. We see that the Samsung J1 has about 1.6 for the RAM. And even if we make the closest comparison possible, 1.8 the storage capacity. This can make a really big difference when you're thinking about how you can reach your users. But the difference of context goes beyond just the physical form factor and the specs of the phone, and also has some implications just by virtue of the fact that they're using a smartphone. Now as a quick question here, so how many of you guys connect to Wi-Fi, you'd say, on a daily basis? Just another quick show of hands. OK, it looks like most folks in the room see Wi-Fi regularly. If your primary way of interacting with the internet is a smartphone and you maybe never interact with a laptop, this isn't necessarily true. First of all, you don't need to have Wi-Fi to be able to connect to the internet. And your phone's also in your pocket. So it goes where you go, which means that if you go somewhere that has bad connectivity, that's your internet access for the day or for the hours that you're in that area. And we see a growing number of people relying only on cellular data around the world. So this is a stat that recently came up, which is actually even in the United States, about 20% of households rely only on cellular data to connect to the internet. And what's really interesting is that this has actually doubled since 2013. So we see this on the rise, even in areas like the United States. And it's more pronounced than some of these areas where we see users coming online for the very first time. And the fact that people are relying on cellular data means that it's really important to consider what the quality of their connection actually looks like. We see that globally, about 60% of mobile connections are 2G connections. And this is excluding 2G-like speeds, but just explicitly 2G connections. And we see this more pronounced in a number of these areas where we're expecting to see the user growth of new internet users, with over 2 thirds of users in those areas relying primarily on 2G connections. But what's really interesting is if you actually project some of these trends over time, we do expect this to slightly go down. But even by 2020, we expect one fifth of the mobile connections globally to still be 2G connections. And this has a really big impact on the user experience when you're building things. We've seen across the numbers of studies and over time that a delay and the speed of your experience is critical to how many users engage with your experience and how happy they are with your experience. This is just one example of a study that found that a single second delay in page times led to 11% fewer page views, but also a 16% decrease in customer satisfaction. So this both has a quantitative and a very qualitative impact on the user experience and your reach. And so it's really important as we're realizing that a lot of people are accessing experiences on slower connections, that we make sure that the user experience is still as fast as it possibly can be. Because we know that if your experience is slow, that directly leads to lost customers. And we don't want that to occur. And we really want to make sure that we're planning for this and building for this. But beyond just the delay that relying on cellular connections that maybe 2G or 2G-like speeds can incur, it's also important to realize that relying on cellular data also has a cost involved. Looking at the minimum wage in India with a few simplifications, because minimum wage in India is actually quite complex. It depends on your country and your job title, et cetera. We see that, on average, 17 hours of minimum wage work is needed to pay for a 500 megabyte data plan. And that's if you spend your entire earnings from 17 hours of minimum wage work just to buy data. And so that's an incredible amount. But just to put this in context of the web, if we look at the average size of a web page, and again, make a couple simplifying assumptions, we'll see that this means that, on average, an hour of minimum wage work will load you 15 web pages. That's it. That's if you spend your entire income from that one hour of minimum wage work just on the data to afford loading web pages. So take a moment to think about maybe how many web pages you've loaded this morning. And it's about maybe 10, 15 this morning. And think of how many hours of minimum wage work you would have had to incur just to be able to afford your browsing habits. This is incredibly challenging for people who are regularly making trade-offs for whether they can spend the data on something or spend it on something else that they might need. And so these connection quality and costs can also directly lead to differences in how users are going to be interacting with their network connection. So connectivity frequency also comes up here. Because data is so expensive and because connectivity can really vary, we not only see that sometimes users just have no data plan, they've either run out or they don't purchase a new one until they feel that they need it or can afford it. We also see that when people do have data plans, they're turning it on and off quite frequently. Some users that we talked to in some of these areas mentioned that, on an average day, they think they turn airplane mode on and off about 12 to 15 times so that when they're not using their phone, their connection isn't there so that they know that they're not using data that they don't need because the data costs are so high. And so all of these together can make it seem a little bit daunting. I've just walked through how people are relying mostly on smartphones. Smartphone profiles look different than maybe what we're used to. Connectivity can be limited. It can be 2G speeds and it can cost a whole lot. So you might be sitting there and be like, great. So how do I actually develop for these users? This sounds challenging. And there are a number of challenges. One of the big things here is that installs are hard. If data costs money and takes a lot of time, convincing a user to install your experience can be really challenging because they haven't necessarily interacted with it. You're putting it forward and you're asking them to not only spend the money that it might take to download the megabytes that your experience or app might be, but you're also asking them to take the time. On 2G speeds, apps can take a fairly long time to actually download. But assuming you can convince a user that they need to install your app even without having tried it, you also have this lovely challenge of the APK size. If you're looking at a device with 4 gigabytes of storage, that's just a different condition under which your user has to make the decision if they want your app or not. And so having a very small APK size becomes really critical because you don't want them to have to delete photos or videos or other apps they might have just to get your experience on their phone. And beyond that, even if you do get it on your phone, you're probably continuing to improve your experience and make it better and better over time. And you want your users to have the latest and greatest product that you've built. And so you need to make sure your users are up to date. And this too can be challenging because, again, I have to have the connection and the data plan and be able to incur that cost and be willing to incur that cost to actually update your experience. And these constraints can be a little bit daunting when you're just trying to reach out to your users. But luckily, there's actually an app for that. And this may have been spoiled by the title of my talk. But it's the mobile web. So inherent to the mobile web, we actually remove a lot of these constraints. The mobile web is accessible without an install. If you're building a web experience, when users navigate to it, they see the experience immediately. And they can use it right out of the gate. You don't need to convince them to install it just to try it. They try it just by virtue of having gone there. What's more is that means that storage constraints are not an issue for that initial interaction with your experience. They don't need to worry about deleting videos or photos or apps that they might really care about just to see if they want to interact with your experience. And you don't have to worry about keeping users up to date. When they navigate to your website, they are up to date. Because as you make improvements, the users are always getting the latest. And beyond this, we've seen that removing these barriers has a real impact on the reach that experiences can have. Some stats that we pulled last year saw that, on average, mobile users use about 25 apps a month. But in comparison, we've seen that on Chrome on Android, users are actually navigating past over 100 websites per month. And so we see that, in short, users have about four times the number of sites that they're looking at over each month compared to native apps. And this also has a pretty direct impact on how many users are interacting with a given experience. So an analysis of the top 1,000 mobile apps versus the top 1,000 mobile web properties found that, on average, we see two and a half times more monthly unique visitors on the mobile web compared to the top native app experiences. And so what this really means is that removing those barriers directly relates to the reach and the possibility of user base that you can have with just that initial experience. But beyond that, we're also seeing that these trends are growing over time. And so we see that, over time, there's been two times the growth in mobile web traffic compared to native app traffic for these same top 1,000 mobile web apps and native apps. And so removing these barriers is very critical to actually reaching users. But beyond just this, we also have been working hard on the Chrome team and with other browsers to make sure that web has the capabilities that you and as a developer need to build good experiences. So some of you may have already heard the term progressive web apps. The idea here is that you can build experiences that have a lot of the features that some of us often associate with native, but with leveraging the benefits that the web has to offer. So just to walk through a little bit about what a progressive web app is and what it really has to offer. So by virtue of being a progressive web app is discoverable by all. It's a website. Users can navigate to it. Users can find it. And they're immediately in the experience. There's no friction or install barrier to try out your experience in the first time. But beyond that, with a lot of the capabilities of a progressive web app, you can start creating very fast and smooth experiences that we often associate with native. They can be full screen. They can take over. And you can really interact with this experience like you would a native app. But beyond that, we know that a lot of users are going to be accessing your experience on 2G or 2G-like speeds. And so you can also leverage new web technologies to make sure that everything loads quickly as possible, regardless of the network type. So you don't incur that one second delay and the consequences of that, regardless of the connectivity type of the user. But what's more is we do know users are sometimes offline. And with progressive web apps, you can actually make sure that your web experience works whether the user is online or offline. And what's more is we do know that installs do have a benefit. It makes it easier for users who have gone through that hurdle to get back to your experience. And the idea with progressive web apps is that it's really easy to get to your experience in the first place. But it's also really easy for users who are engaged and do want to get back to it easily to install it and add it to their home screen so that they can get back to it. And beyond that, for those users who are more engaged, we know that there are some times that it's really critical for you to re-engage with those users, because your experience can offer something exceptionally beneficial to them in a particular time. And so we've also built capabilities to make it really easy for you to re-engage with the web. And so just to give an example here, this is a Flipkart, which is a top e-commerce site in India. And what you'll see here is that they have actually built out a progressive web app experience. And so this is something that you can launch from your home screen or search for directly. It works online and offline. You'll see that it's sort of an immersive experience, and it can scroll through it, and it feels a lot like a native app. But what's really interesting here is that they've also looked at some stats of how this performed compared to their previous website and found that this had a pretty big impact in the user experience. So first they see that their progressive web app, on average, people are spending three times the amount of time on this site compared to their previous mobile web experience. They've also seen 40% higher re-engagement with their progressive web app compared to their web experience before. But what's really interesting here is for an e-commerce site, conversion is really the critical metric here. And they've seen that their progressive web app saw a 70% increase in conversion compared to their previous mobile website. And I just want to walk through some of the principles that you can keep in mind as you're working to develop progressive web apps that can really leverage the mobile web technologies in a way that can work for billions of users. So as we've talked about, there's a few things that really are important here. One is cost. We know that cost can be really prohibitive. If you're making a trade-off between, do I want to access this website or a different website or a native app, or spend my money on something else and not use my data plan right now, you really have to make sure that your app and your experience works as well for users as possible, and that they're not having to make these trade-offs unnecessarily. We also know that connectivity varies. If the majority of users globally are still accessing the internet on 2G connections, we need to make sure that our experience is load as quickly as possible on all connection types. And finally, we also want to reduce complexity. How can we make steps as easy as possible and not only leverage the benefits of the web, but leverage the benefits of re-engagement and making sure users can get back to it as easily as possible? So just to walk through these, so cost. We know this can be incredibly prohibitive. And we really want to make sure that we are taking this into considerations and not forcing the user to make unnecessary trade-offs. So on the Chrome team, we've been working to address this issue across the board. And what we've built is a feature called Data Saver. And this is a setting that a user can go in and turn on. And this will apply to all HTTP content as they use Chrome. And this is a proxy for HTTP content that has no fidelity changes, but helps the user save up to 60% of their data. And we've found that this helps a lot of users, and we've seen this even more so in a lot of the areas where users are coming online for the first time. And we know that data costs are even more prohibitive than in other areas. But what's more is we actually took a moment to think about this more. And we really want to make sure that we're pushing the boundaries on this and helping users save as much data as possible and that they stay in control of where their data use is going. So we actually launched an improvement for this so that for Data Saver users, for HTTP content, when they're on a very slow connection, we actually automatically replace most images on the page with placeholders so that the user can then choose which images they need or want to load, or they can choose to load all the images if they need to. We do try to do this in a way that keeps the page usable so that smaller images, et cetera, such as next pages or hamburger menus or whatever that might be, are still visible so the user can continue to interact with the page. And this has helped us get it to up to 70% of data savings for users. But we know that, as a developer, you often want to be in control and make sure that the optimizations you're doing work for the experience that you've built. And so we've also been working to introduce client hints that help you stay in control to make sure that you're not only taking this into consideration, but doing so in a way that works for the product that you're building. And so in M46 release of Chrome, we launched a number of different client hints, including DPR, Width, and Viewport Width. And these are things that you can all address on the server using data provided by the user agent. So what this means is that you, as a developer, can understand the context under which the user is accessing your experience and make sure that you're only sending the images sizes that users need, and making sure you're optimizing the experience and not using up their data if you don't need to. But we've also added recently a save data hint. And in Chrome, this maps directly to whether a user has that data saver feature on or off, which means that you, as a developer, know which users are the most sensitive to data. And you can take extra steps to make sure that the experience you've built works for them as well. And so what this means is, depending on your experience, you can optimize what needs to happen. You could choose not to load images that you think are less critical, and you can choose which images you feel that those are and make sure that the user stays in control. You could avoid auto-playing videos, or you could make sure that whatever sort of background fetching or things that you might want to be doing are only happening if the user really needs it. But beyond that, we know that this gives you control, but we also know that thinking about all these things can be challenging. So we actually have a module called PageSpeed Module, which is a server-side component that you can drop into your web server that will do a lot of these optimizations for you on both HTTP and HTTPS traffic. And what this means is that we actually have the single line of code that's optimized for bandwidth mode that, when on, will do all of these transformations with really no fidelity change and without breaking anything, which means you can get the data-saving benefits for your users without having to worry about any negative impact on the user experience. So we've also gone a step further for this and made sure that if the user does have that data-saver feature turned on, the PageSpeed Module will automatically take a few extra steps to save those users even more data. So just to give a quick example of this, this is a screenshot of a small sort of mock store front that we created. On the left here, you'll see a screenshot of what the page looks like with no PageSpeed Module. On the right here, you'll see a screenshot of what it looks like with PageSpeed Module turned on in the Optimize for Bandwidth for a user who has data-saver on. You may have noticed these two screenshots look quite similar. Actually, if you can point out any differences, let me know. I promise there are different screenshots. So you might be asking sort of what is actually the difference between these two. So if we actually dig into this and look at some of the numbers. On the left here, this page is relatively light looking at average size of a web page. It's 350 kilobytes. But if we simulate a 2G network and try to load it, it can take about a little bit over a minute to actually load this page on a 2G connection. Now, by just turning on the Optimize for Bandwidth mode, we already get a number of improvements here. And we can actually cut the data by about 50% and lead to 165 kilobyte page load. But if a user is data sensitive and actually has data-saver turned on, we can get even more benefits. So for a data-saver user with the Optimize for Bandwidth mode and PageSpeed, we actually see that this page goes down to 120 kilobytes. And so that's about savings about 65%. And what's more, if we simulate it again on 2G, you'll see that this actually goes to an under 30 second page load time. And this has happened with really no difference to the user experience. The fidelity is completely the same between these two. And this is just one example. Across sites, we've seen an average of about 37% data saving reductions without any sort of fidelity change for the user. And that's for users who don't have data saving on. When we turn data-saver on, we're actually seeing even more improvements. But beyond just taking steps to make sure that you're taking into consideration the cost and the data cost of your experience, there's also a number of things that you can do to make sure that your experience is as fast as possible on all network types. So looking for a moment at the different connectivity profiles, we see that the round-trip time or the time that it takes between making a request and getting a response varies quite widely between these different network types. So on Wi-Fi, we can see sort of on average a 50 millisecond round-trip time. But compare that to 2G, which is about 50 times slower. And you start getting to 2,500 millisecond round-trip times. And this can really impact the user experience and also how you want to actually implement and address some of these problems. So one thing that you can do is first know what connection a user is on. So Downlink Max, which started in Chrome M48, can tell you the maximum megabits per second of a user's connection. And while you can query this to just find out what the connection type a user is in, you can also subscribe to updates so that you know when a user is switching between different connection types. And you can make sure that if they're moving to a slower connection, you're keeping your experience as fast as possible so that you're again not incurring that one-second delay that can lead to a really detrimental impact on the user experience. But what can you actually do about it when you do identify these slower connections? So some of you may already have heard of ServiceWorker. So ServiceWorker is a client-side proxy that's written in JavaScript. And you can think about it as sort of this background process that sits between the server and the OS. And when the page is loaded, you can register your ServiceWorker. And then once it's registered, you can actually start using it to cache content and start supporting more offline situations. But you can also use ServiceWorker to actually improve the performance of your page. And so a lot of us has probably been in those situations where your phone thinks it's connected. It shows you that you're connected, whether it's Wi-Fi or cellular data. But you're trying to load something and just nothing happens. You're sort of in this Wi-Fi situation where it's telling you you're connected, but nothing is coming through. And this is incredibly painful. And this is even more so the case in areas where connectivity itself is just very intermittent. But with ServiceWorker, what you can do is you can actually implement request timeouts to address these slinky connections so that you can make sure that you're caching the content that's critical and still serving it to the user regardless of their connection types. And so this can really help bridge the gap between those sort of fully connected and flaky situations. But we also know that sometimes there's just no connection. This might be because the user has turned on airplane mode. It might be because they're out of data. It might be because you're in a tunnel or whatever situation that might be. And there's just no connection. And you've built a great experience, but you probably don't want this to be the first thing the user sees when they tap into it. Now, I love the offline dino game as much as the next person. And I know there's stickers outside with the offline dino. But perhaps not the ideal way to actually get a user to interact with your experience and see what you have to offer. And so with ServiceWorker, you can actually take this a step further and make sure that even when the user's offline, they're getting the best possible experience. So to give an example of this, this is Konga. Konga is a top e-commerce site in Africa. And they've gone beyond just enabling accessing of their experience when they're offline to actually optimize their experience for the flows that they need, whether a user's online or offline. So this here is a flow of someone doing a purchase. So they've added some items to their cart. And then we're going to go ahead and simulate what it looks like when the user's offline. And so what they've done here is when the user is actually offline, they not only let the user know that they're offline with a little thing at the bottom, but when the user goes to do the checkout flow, they actually have a call to order button instead of supporting their online flow, because the user can't complete an online flow when they're offline. And this allows you to really close the gap and make sure that your user experience for the flows that are most critical to you work regardless of whether the user's online or offline. And so for this e-commerce experience, the user can finish their purchase even if they've lost connectivity completely. And what we've also seen is that this not only helps with the user experience and making sure that they can get to your experience, but it also ties back to that cost that we talked about earlier. What Konga team has seen is that their steps to their first transaction have been drastically impacted as a result of using the service worker technology. They found that compared to their previous mobile website, this new progressive web app takes 84% less data just to get that first transaction done. But what they've also found is if you compare it to their native app experience, this first flow that is most critical to them takes 82% less data than their native app. And so this is huge. It's not only helped bridge the gap of connectivity and made the critical flows work, whether you're online or offline, but it's also helped users save that data. But beyond just addressing the cost and connectivity issues, we've also seen that this benefit helps across the board for different apps. And so Flipkart, for example, also saw three times data savings for their experience compared to their previous mobile web experience. And so these data saving benefits that you can get by addressing the offline connectivity issues can help across the board to address other issues as well. But the other thing you really want to consider here is that's great. We can make sure things load quickly. We can make sure that we're removing cost barriers. But we also want to make sure that we're removing complexity and making things as simple as possible. And when we're talking about costs, we know that every step is going to be time and money. If you're on a 2G connection, the steps both in your experience and getting to your experience can be challenging and just take extra time and ask the user to do more things that are necessary. And so one of the best ways to actually address cost and connectivity is just remove some of these steps. So with the mobile web, we have an add to home screen functionality. This is another example with Conga that has built this out. For users who have engaged more with your experience, you can actually suggest that they just add your website to their home screen. And this doesn't have storage constraints, none of that APK size barriers we had before. But users can still get back to it with a single tap, which means that getting to your experience is super easy. They don't have to navigate multiple times, go through different page loads. And so you've removed those steps, that extra time and money, to let users get to what they actually care about immediately. But beyond this and just getting to your first screen, we know that sometimes your experience needs to get to a particular part of your screen. And you can actually cut out page loads within your experience as well. So with notifications, you can actually send notifications to your users using the mobile web so that you can reach out to your users at the most sensitive or necessary times, depending on your experience, and link them back to the specific part of your experience that they care about. So they don't even have to worry about just loading your experience and navigating within it, but you've removed those steps as well. And so this makes it really easy for the users to re-engage with your experience at the times that are most critical to them. So we've talked a lot about the different situations and the different constraints that you need to consider here. But one of the things that can be really hard, circling back to the start, is we haven't lived under these conditions necessarily, right? All of us in this room first access the internet on a non-smartphone, which is just different. So one of the things that's really important is to make sure that you're trying out these experiences yourself, and you're trying them out under the conditions that are representative of your user base or your target user base. And so we have a number of tools to actually let you do this. One thing that we have is sort of a mini mobile device lab. And what this is is you can actually look it up and download it from GitHub, and it'll let you simulate what your experience looks like on these different devices. And beyond this, though, you can also simulate what the conditions are for users. So we talked about how challenging cost can be and how prohibitive it can be. And with Chrome DevTools, you can actually calculate the page weight for a given user. So looking here for a moment, you'll see that this is the network tab of Chrome DevTools, if you're familiar with it. But what I want to call out is this at the bottom here. So this says that this page took a little bit over 700 bytes to load. Now, that's pretty small, but we can actually call out a little bit of a caveat here. A lot of these loaded from cache. But you can actually refresh the page if you want to simulate what it looks like, even when users are getting to it fresh. So you can get a sense of what the experience looks like as users are interacting with it, as they're going between different pages. And you'll see that if I go ahead and refresh this page, we also have updated the sizes. So you'll see that in compared to that 700 bytes, this page actually took 211 kilobytes to load. And you can really get a sense for what this means and what this costs for your user when you're talking about data plans. But the other thing I want to call your attention to here is that you can also use this tool to understand the time and the loading experience that users are getting. So you'll see that next to that byte count. We also tell you how long it took for this page to load. So this page took about 600 milliseconds to load. And this was just using Wi-Fi that I was connected to. But you'll also see up here that you can actually have no throttling right now. And you can change this. So if I tap into this, you'll see that there's a number of different options. And if you actually go ahead and simulate the same page load on 2G, you'll see that suddenly it's a very different amount of time that it took for this page to load. So we're more at 11 seconds now. And you can actually see what this looks like and start tapping through your experience and see how it changes if you're using Service Worker and some of these other technologies so that you can make sure the experience that you are giving your users is one that you're happy about and excited about and really puts your product and your experience in the best possible light. And the users are able to access it without some of these barriers. So using all of these tools and using these technologies, you can really use progressive web apps not only to remove the barriers that the web fundamentally offers, but to address the cost and the connectivity challenges. And you can also go a step further to use some of these things to remove complexity and actually remove the steps altogether. So you're not doing unnecessary page loads if the user doesn't need it. We also have a number of other tools online, and you can read up more about them. You can read more broadly about how you can build for billions across Android and mobile. But we also have some web-specific tools that you can look up here as well. I'll also be over in the mobile web tent if anyone has other questions. But the main idea here is that using all of these different technologies, you can make sure that you're really thinking globally and making sure that things not only work for those 20% of US households that are relying solely on cellular data, but also work for users who are maybe coming online for the first time. And so using all of these tools, you can make an experience that is built to work for everyone. Thank you. Thank you. Thank you.