 Thank you. Thank you, Mani. Thank you. Morning, everybody. Morning. Morning. Thanks for making time to show up on a Saturday morning at 9.30 to come and listen to me speak. Given it's like I have two versions of this deck, actually. One which is used when people are at a good time of day. One which is used in the beginning of the day or if it's the end of the day. So because it's the beginning of the day, I'm going to use one which has as little words as possible and as little code as possible. I don't think I actually have a snippet of code, but I'll talk about these things. Also, I'd like to have you guys try these things out as opposed to me talking about it, which I think is more fun. So before I get started, I just want to get a sense, show of hands, how many of you are developers in the room? Yes, OK, good. Everyone's a developer is what I thought, great. How many of you are Android developers? Web developers? All right, fantastic. iOS developers? Lovely. Cool. So actually just to introduce myself a little bit more, I'm on a team at Google that's called Product Partnerships. And what that actually does is Google comes up with new things every day. We have a lot of new technologies and platforms we come up with. My team is the one that these engineers first come to and say, we've come up with this crazy new thing. Now, what do we do next? How do we figure out a way to see is there value for this in the market? Are developers going to like this? Is the ecosystem going to adopt this? How is it going to grow? What's going to happen? That's really what my team tries to figure out. So I really enjoy that because I get to work on the latest technology that comes out. And in particular, over the last year, year and a half, I've been working a lot on the web. And I've given this talk a couple of times. Actually, I like to use this title more and more nowadays because I think it brings about some interesting discussions. I actually went around downstairs and in the room earlier and said hello to a few folks and said, oh, are you guys going to the Google sessions? And they're like, yeah. Oh, did you see this talk on the future of the web? I didn't say I was giving the talk. I was just like, this is talking. What do you think of that talk? And I tried to get a few comments from people. Like, what do you think of this? And I actually put them on screen when I picked up some of these comments. So my first slide, I was making it while I was sitting there in the last session. And I thought I'd show that to you. And this is kind of what I was hearing is like, is there really even a future? What are you talking about? The world today is all about apps. Everyone's making an app. Android's an amazing platform that's growing. Especially in Asia, everyone loves to use apps. And all the things I was hearing was the web is dead. It's all there. I met a few guys who said, I'm a web developer, but my company, all they care about is apps. Like, we're like these neglected developers. We're not the cool kids. The cool kids are all the Android developers. So I was like, OK, it's interesting. I also heard people telling me that, yeah, my whole business is just app. What's the point of the web even nowadays? So I said, well, if you have the time, maybe we should go for this session. I'm hopefully you guys know. I'm not going to name and shame these people. But hopefully you find this session hopefully inspiring, hopefully interesting, food for thought, if nothing else. So let's see how we go there. I'm going to start off with a little bit of history. How many of you have one of these? Half the room had one of these. Yeah, I used to have one of these. And this is, by the way, not that long ago. I used to sit on my little white computer. I'd connect a dial-up connection. You'd go, t-t-t-t-t. You'd connect to the internet. And that was it. That was me consuming the internet, right? Well, today it looks a lot more like this. It's connected devices. It's internet on your phones. It's on your TV. It's on your tablets. It's in your car. It's everywhere. And if you look at the stats, like just going back to this one, back then it was a 100% web. And there was no apps. If you did any kind of market research study of any kind. And only in about 10 years or maybe 15 years, it's gone from that to looking more like this. You pick up any industry report out there on what we talk about, the digital, consumer, the internet. You'll always see these numbers. You'll see engagement, and time spent, and conversion, and transactions. It's about 80-20 app versus web. 80-20, 70-30. This is roughly what you always see. So really, what happened? It's not that long ago. What happened? How did we end up with that radical shift? This is what happened. The primary consumption device of the internet switched to a mobile phone, to a smartphone. How many of you have one of these right now with you? Anybody doesn't have one of these with you right now? No. It's pretty cool if you actually don't. If you can get away from your phone on the weekend, it's not a bad thing. So not only did the device change, but three things in particular changed that were pivotal. Connectivity changed. Back in the desktop days, you didn't have issues like, oh, I'm now on a 4G connection, and I'm suddenly offline. Or I went from 4G to 3G to 2G, and I went back up. Degradation in networks and intermittent connections, that was not a problem that people experienced in the desktop days, not necessarily. But in mobile, that is a real issue, especially in emerging markets, especially in impact. That's a very real issue. Secondly, interaction changed. You're not typing on a big keyboard. You're swiping. You're tapping. You're pinching. You're scrolling. That's what you're doing on these phones. That's a very different UI, UX model. And thirdly, consumption patterns are very different. Gone are the days where you'd go sit in an internet cafe for an hour, and then consume the internet. You now take out these things. I believe this recent stat is about 250 to 300 times a day, people take these things out. They like a photo on Facebook. They reply to a WhatsApp message. They check the time. They go write an email. They check out a YouTube clip. This is what happens. So all of these things changed. And user consumption, user patterns, evolved tremendously. But the web just didn't evolve fast enough. And so a lot of people's experience of the web today looks a lot like this. The web is not optimized. Website doesn't fit on my screen. God forbid I go offline. I end up on a white screen. If I'm on Chrome, it's a little black dinosaur. Yeah, it's cute, but it's really annoying because I really want connectivity. Things don't load. You can't swipe. You can't scroll. These things are jaggy. They're laggy. That is what happens with the web. And so technology industry, all of us in the technology industry, what did we do? We saw a problem. We innovated, and we found a solution. APKs, bite-sized pieces of content that serve a specific purpose built for Android and iOS that just work on these devices really, really well. They have features that make sense, like an icon on a screen that you can tap to get to something. They have things like push notifications that makes a lot of sense on these devices. They work offline. They are inherently built for this screen. You don't have to think about mobile optimization. They're built for these things. That made a lot of sense. Hence why we ended up in this world. So all that is cool. I'm sure all of you know this. Why is this guy standing in front and telling us this history lesson, which we already knew about? It's because of this. How many of you follow Google I.O.? Anyone who follows Google I.O.? Anyone attended Google I.O. 2016? Cool, yes. One person there. Lovely. So in 2016, at the keynote at I.O., Sundar went up on stage, our CEO, and talked about remaking the mobile web. An entire community in the press was like, what are you talking about? The web has been there for ages. This is like this old archaic dinosaur. What is so special and new that's happening this year? Why do you talk about remaking it? Rahul Roy, who's the VP of Chrome, called it relaunching the mobile web. And the web is ready for business. What's going on? So what I'm going to do is I'm actually going to play a little game. You guys are all developers, right? So I am going to show you two versions of an app. And I want you guys, as developers, imagine that you're product managers or chief product officers of a company to look at the performance, the look, and feel the user experience of these two versions. And tell me which you prefer, OK? Ready? Let me try to now, hopefully this will work, I'm going to try and get my phone projected on the screen. By the way, I like to do a lot of live demos. And whenever you see a green screen, something live is going to happen. It don't always work, because they're not staged demos. So forgive me if it fails. Let's try this. Oh, yeah. Hang on one second. All righty. Do you guys all see my screen? Do you see my phone screen? Is that? Yeah. Is that visible? OK, let's try this. So do you see these two green icons up there? Wego, it says Wego up there. That's two versions of the Wego app. Some of you might know this company, it's a travel app. I'm going to show you two versions of it. We're going to go through it very quickly, so pay attention. Remember, you're product managers or heads of product. Focus on the performance, look, and feel. Don't worry about the content. So I'm going to open up version one. I tap that, flights and hotels. Let's try to make a flight search. Let's say I want to go to Singapore to Bangkok. Let's pick some dates, 31st, let's do 38th to, let's say, the 6th, and hit Search. I'm searching. I got some results. I can browse. Let's pick that one. That's the deal I'm done. You guys saw that? Let's do version two. I'm going to tap the second icon. Opens up flights and hotels. Let's go into flights. Yeah, let's go to Singapore to Bangkok again. Let's do the same dates, again, 38th to the 6th. Hit Search. I'm searching. I got some results. I found something I liked, and I'm done. How many of you preferred version one? How many preferred version two? How many of you actually think they're the same? I couldn't really decide. Be honest. So 10% liked one. 10% liked two, and 80% really don't know. Those who liked one, could you tell me why? There's a few hands. Could you tell me why you thought one? Response was faster. The result was faster. Good observation. That's a good observation. Response was faster. Those who preferred two, anyone? Could you tell me why it was more than? It was responsive. The first one or the second one? Second one. Better individuals with flights, better people with flights. And for the rest of you who are undecided, you think pretty much the same, like you can't really tell. Now, what if I told you one of these is actually a mobile site, and one of these is actually a native Android app? Who thinks the first one's the website? Who thinks the second one's the website? More people. For the people who think the second one's the website, anyone? In fact, guys, the first one's the website. And in this case, Weego's built a mobile. This is their latest mobile experience. You can check this out. Go to weego.com, and you will get this experience. And it's faster than the native Android app. If you don't believe me, I'll prove it to you. I'll tap on that first icon again. Let's go all the way back to the first screen. I'm going to scroll down. You see that? If I had the app, you wouldn't put, like, go download. I mean, I've already downloaded it. It's a website. This is what excites me about what's possible with the web today. So let's go dig into this a little bit more. Clearly, 80% of you thought the web and the apps were the same. Most of you couldn't really tell which was better or not. And that's really why this space has become very exciting just in the last year or so. All right, back to my slides. So if you were to, like, in a very simple world, draw out apps and web, this is what things look like. Blue is web, red is apps. And really what you find is from a discovery and reach perspective, the web has always been really, really good. If you want to get to a lot of users, this is the easiest way to get to a lot of users. It's very low friction, no discovery issues, very, very quick and simple. The challenge is, however, always been an engagement. That's where apps win. So you have this world where apps are up there, or higher engagement, tough on discovery because you need to get able to download apps, discoverability in Play Store, the other stores, all of that. The web's always had this. So what we've done, and what actually as a community, as an open source community we've done in the last 12 to 18 months, is really bring some capabilities and fundamental frameworks and ideas to the web that really help to do this. We're trying to boost the capabilities of what's possible on the web so that we can bring it on par with apps. And if not, in some ways, actually better than apps. And if you can really do that, you're going to do a really, really interesting space with the web. So let's talk about that a little bit more. What I'm going to show you is this is a quote actually from Larry. Larry always says this in Google. He says, focus on the user and everything else will follow. So why don't we try to focus on the user? I'm going to show you what a best in class future mobile web experience could look like. And I want you guys to tell me what you guys think. So we'll step through it one by one. For most people, your journey on the web starts somewhere like this. You go to search. You look for something. In this case, I'm looking for a fleece hoodie. I found a link, some website, e-commerce site. I click on that link. And the content just loaded instantly, absolutely instantly, as if it was already there on my device. Mobile optimized by default. Doesn't always happen every day. But I had that. I was like, oh, that's cool. It's just happened. Very good. I clicked on this green one that I liked. I got to that product page. And then I realized there's no stock. But the website had a little thing at the bottom that said notify me if there's stock. So I'm like, sure, I'll tap that. I opt into notifications from the site. And now I can stay up to date. I then leave my home. Am I going to the underground or somewhere? And I have no connectivity. This is a common scenario. I can continue to browse this site. The green ones are a stock. But I'm able to look at other products that are there, maybe like this other black hoodie. All when I'm completely offline. Ultimately, I decide not to buy those other ones. I'm sitting at home on the weekend. And I get a notification on my phone. It says, hey, that green hoodie is back in stock. I tap that notification. I'm right back to that product page from this website. I can hit Place Order. Go to Checkout. And then I get magically signed in. I didn't have no user name passwords. I just got signed in to this site. Cool. Everyone hates passwords, right? So I can now go hit Place Order. I got a UI flow that just comes up. That's already got my name. It's got address information. It's got credit cards or debit cards I might have used before. I just tap through it. And I can hit Pay. Done. Transaction completed. I now get another thing that slides up from the bottom of my screen that says, do you want to add this to home screen? I'm like, OK, I actually enjoyed buying from this site. Maybe I'll buy again. I say yes. Now an icon shows up on my screen instantly. And anytime in the future, I can tap that icon. It opens up in full screen mode. And I can re-engage on the go anytime. That is what the future of the mobile web experience could look like. Cool. Interesting. So this puts together lots of different APIs and different frameworks and things that are out there. I'm going to talk about two of them in particular that sort of make this experience happen. And I also share more about some of the successes we're seeing with this. All this is really, really new. The very first one being AMP, Accelerated Mobile Pages. Who's heard of AMP? Maybe 10% of people. Green screen. So why don't we see this in action? Now for this one, I want all of you to get your phones out. I'm going to go do something on my phone. And I want you guys to follow along with me. Let's see if I can get. Oh, it's not again. Sorry? OK. Cool. My phone's working. You guys have your phones out? Let's go to Search and make a search. OK. We're going to do this live. I have no idea what to show up because it's Search Live. Hopefully this will work. I'm going to search for Trump. There's always something interesting on Trump. Go ahead. Search for Trump. And I'm going to browse around and look around some articles. So notice you found maybe some of you saw this. There's an independent article that says AMP with a lightning bolt next to it. Do not tap on that. Go further down. There's another one that doesn't have a lightning bolt on it. This is a neutralized for network connection. We're going to try and open up this typical web link. Let's click on that. I'm going to click on this independent article. It's loading up. Still a screen. The article's there. We have pixels. It's still waiting a little bit. And now it's fully loaded. Not bad. I'm on Wi-Fi, so it should be decent. Not bad. But it was an instant. Not like that first experience we saw. Now let me try AMP. Go try clicking on the AMP link. When you tap that, instant. This entire page is now in fully loaded under one second. Do you guys see that? Let's try something else. You can go further down. Let me see if I can find any other AMP links. I can go to the next page. There you go. There's a New Yorker article. That one says AMP next to it. Let's try tapping that one. Again, fully loaded. Pretty much instant. Any device? Just go to Search. Any device? Any OS? It's in Search. By the way, this is not just news. Let's try something else. Let's go and try iPhone 7 in India. You want to try to search with me? Really popular search. You'll see two links here now. This is cool. This is exactly what I want to hopefully get. There's an Amazon India link and there's a SnapD link. Let's go try to click on the Amazon India link. I'm going to tap that. This page is loading up. Got some pixels. You can see the loading bar is still there. It's done. That is not bad for e-commerce. There's a lot of stuff that needs to be loaded when it's an e-commerce page. That's not too bad. But not necessarily instant. It's not only, right? Nope. Nope. I'm going to try and tap on the SnapD link. Let's try that. Did you see that? Anybody miss that? You can try again. I'm going to try on SnapD link instead, where it says AMP next to it. Oh, where's it going? Tap that. Fully load. Their load time on product pages, they, by the way, done AMP for every product page that they have. Their load time on search now with AMP is 400 milliseconds every time. This is the power of AMP. Remember that user flow we talked about at the start, where we were looking for a hoodie and clicked and the content just loaded? That's where AMP comes into play. So I'm going to switch back into my deck. And we'll talk a little bit more about this. All right. Now, AMP is something we launched about a year ago. AMP is about making individual web pages fast. And since then, since about 12 months ago, we've seen 860k domains making AMP. We've seen 1.7 billion AMP pages already out there in the world. And there's 35 million of these coming out every week. The story with AMP is we had a bunch of folks in product who said the web is just slow, but we've optimized the hell out of search to make search fast. Regardless of the network that the user is on, the device they're on, Google.com works. And in fact, you make a search and we still make that search page work. But after that, when you click on a blue link, the experience completely goes off the rails. So AMP is actually trying to do that. It's trying to make individual web pages. If you make a web page in the AMP HTML format, I'll tell you more about that. And it's valid. We have a public validator. You can stick any AMP URL through it. It will check and tell you if it's valid. If it's a valid AMP page, you will be guaranteed instant loading. That was the promise of AMP. We've actually seen lots of uptake in AMP. This is just a selection of some websites, some e-commerce sites, some other publishers who've taken up AMP and started to experiment with AMP. And what's cool is to share these results. Across all of these 1.7 billion pages, the median load time is under one second. That was exactly what we were shooting for. And in fact, AMP pages are four times faster than regular web pages. And they consume 10 times less data. That is really, really exciting to hear. Now, why is that? What's happening in AMP that makes it so cool and makes it so fast? I'm going to talk a little bit more about this. If you look at the top flow, that's basically what's happening right now. And this is an example of a news publisher where you have a CMS, like a content management system. You are pumping out news articles. You normally pump these out in HTML, and it goes to the client. You can optimize that in line CSS, minify your JavaScript, try and optimize reduced trackers, all of these things, lazy loading, to try and make this better and faster. That's what people have been doing for ages. What we did with AMP is we said, let's put all of those maps together into an AMP library that anyone can just access and make a page with it. AMP is a component-based format. The format itself, it's async, and it's optimized by default. What do I mean by that? What I mean is that if you make an AMP page, the way this works is a bit like LEGO blocks. I want to put an image. I use the AMP image tag. It's like the IMG image tag, but it's AMP-image. It's just slightly different. I want to go put like a little carousel. I use the AMP carousel component. I take these individual components, which are each of them individually optimized, and put them together in an AMP page, and you will guarantee that this page will always load instantly. So that format makes it super fast. Second thing that happens with an AMP page is because it's written in AMP HTML. When you put it out there and Google crawls there, so any platform, actually, you can pick up these pages and it gets cached in something called the Google AMP cache. There's actually an open cache. There's no cost to it. You just do this with all the content that comes up in AMP, and then you can load that locally for a user. You can imagine this is obviously going to make things much, much faster. And the third thing is actually you can do pre-rendering. So Search is a platform where AMP shows up. It can start pre-rendering some of this content. And also, it knows a lot more about what's going to happen on that page. For example, like reflows, if you load a normal web page, I don't know how many of you are familiar with this concept of reflows. Like an image would load, then something else would load, and you'd drag one thing down, then some text would come up, or a code, and then something else would move. That leads to like six or seven different cycles. With AMP, there's no reflow. You know from the start exactly where things are, and boom, it loads all at the same time. So these kind of optimizations happen as well. When you put those three things together, you get instant loading. That's what AMP's trying to do. Now, AMP is not just about Search. I gave you the example of Search, but anyone can support AMP. These are just a handful of names of people who are supporting AMP. What does that mean? That means if you, let's say, make an AMP page, it's an article, and you share that on Twitter, and someone clicks on it, you get that same instant loading experience with that lightning bolt and everything, and loading instantly under a second. Same thing on LinkedIn. You share something on LinkedIn, people click on it, that same experience happens. Bing, Pinterest, Hike, like a messaging app, where you show a web content might be shared, same thing happens. What's good about this model is, you as a developer or you as a content owner doesn't have to build for individual platforms separately. You make one format, and it's a standard format that anyone can then support. In fact, what's really exciting is, we just had our global AMP conference last week, and we announced three new platforms, all from APAC, that support AMP. You might see the slightest change with three logos. Baidu, Sogo, and Yahoo Japan have all now started to support AMP. That is the top one and two search engines in China, and one of the biggest ones from Japan. That's a billion more users that can now see the benefits of AMP through those search engines that they use. This is really all about community. I can't stress more about this point. The number of stories we've had about AMP and how people have come together to make the format, it's really, really important. Everyone has to play a role in this. I'll give you a classic example. When AMP first came out, the CNN started doing AMP, and then they use BrightCove. Some of you might know BrightCove, it's a video player, and they were like, wait, wait, BrightCove videos embeds aren't working in the AMP format. It's very simple. BrightCove just made a component, that was an AMP BrightCove component, submitted it on Git. It went into the repository, it became live, now anyone can just use that, and BrightCove works on AMP. This is how AMP works, and this is how AMP evolves. Similarly, when we first, when the engineers in our, and first came up with AMP, they came to us and said, we've managed to figure out how to make a webpage fast, like, okay, what can you do? It's like, text and static images. It's like, okay, I was like, well, let's try to go to news. Who else would have text and static images content that makes sense? What about e-commerce? How do you do that? Components needed to get formed. A lot of e-commerce players actually came together to make some of these components, submitted it, and got added into the AMP community, and now you can start making rich AMP pages in e-commerce, just like Snapdeal has. In fact, there's about 9,600 engaged developers on GitHub on AMP. Just go to AMP project on Git, you'll see this there, and there are 300 contributors. We are really, really excited about this. We'd love all of you to take a look at AMP, try to make AMP pages, try to show us what's not possible, and not just that, figure out a component that you can make and submit it. Anyone can do this. Now, switching gears, I'm gonna talk about another piece of interesting technology. It's called Progressive Web Apps. How many of you have heard of this one? PWA? Few more folks, few more folks. PWA is trying to raise the bar for user experience. That WeGo example you saw at the start where I talked about two apps, their mobile site, that was a Progressive Web App. They are really fast, as I'm sure some of you pointed out. They're very reliable, they actually can work offline, and they're very, very engaging, as you could see in that example. PWAs also bring a bunch of interesting things to the web, through a very core underlying technology called Service Worker. Some of you may have heard of this. It's gonna just outline exactly what a Service Worker does, and why this makes it pretty cool. It actually breaks the model of how the web currently works. So this is basically how the web currently engages with clients. You have a web server, and you have a client, and every time it unloads something, you go to the server, and you load that content. What a Service Worker does, is essentially it sits right in between that. It's a client-side JavaScript library that's registered on a client's device, and it has one singular purpose, to intercept a network request. And to intercept it, and either use a on-device cache with a Service Worker comes with, or then do something else with it. Now you can see how this is a much better model of how to do things. Android always had this benefit. If you were like, for example, loading a web page, and I can give you a good example of this, we talk about the App Shell model. Think about this page, where you've got, essentially what you call a shell of an app. This is a website. If you think about this menu item that comes up, and stuff at the top, that's all a shell. That stuff doesn't change from page to page. So only the content that's sitting right in between that changes. That's dynamic, and live. In the previous world of the web, what was happening is when I'm on page one, I load everything. When I go to page two, I get rid of all this stuff. I reload it from the server with the content. What you can do with a Service Worker is you can have this App Shell loading on the first instance, on first load, stick it in the Service Worker cache on the client's device, and when the user makes a transition to the second page, because the Service Worker plays in between the network request, you could say, load the App Shell from the cache, because that's not updating, and nothing's changed in that, and only go to the server for dynamic content. You can see how that is inherently just a much better model of how to do things. Now we had things like App Cache, Browser Cache that tried to attempt doing some of this, but it was never possible to do it in a very fine-tuned manner, in a very controlled manner. Service Worker is the way to do that. This is why these things are super fast. This is also why these things can work offline. You can put stuff in a Service Worker so that when you go and try to go to the network and there's no connection, you don't have any server to connect to, you can load from cache and show meaningful content to a user. Again, apps could always do this. You had an APK, there was content on the device, they could load that. Web didn't really have that option. It also brings in three features that are really, really been missing from the web for a long time. Through a Service Worker, as a push API, you can send push notifications. Remember that example at the start where the user would just get a push notification? I don't need to have a browser open. I don't need to have the site open. I just needed to have visited the site and then opted in to push. This will work in the background because the Service Worker sits silently and starts working there. You have add to home screen. This is an icon on the screen. That's another reason why I could trick you with that Vigo example. That was an icon. I didn't go to a browser and go to a URL. I just tapped an icon. It loaded in full screen mode. That's now possible. It's through something called a web app manifest. And you can have an offline experience as we talked about with Service Worker. These are all things that apps really, really benefited from. In fact, it breaks my heart sometimes. I see apps which are essentially a website running inside an app in a web view. Like you open up these apps and the whole thing is a web view running a website. I'm like, this is a website inside an app. And there's companies out there that actually do this as a business. And the reason they do it is I want to get an icon on the screen. I want to have push notifications. That was the only workaround. Fortunately now you don't need to do that anymore. So what's really the big deal? Do these things really work? You've talked about these things. They sound interesting. Is anyone actually building these things? And are people actually having benefit? So I'm going to run through a couple of examples in this space. Alibaba, everyone knows who these guys are pretty much. These guys made a PWA. Their mobile site right now is a PWA. They saw a 76% increase in conversion. Now anyone here who understands e-commerce would know that conversion is this like holy grail metric in e-commerce. It's what everyone drives towards. And people get really excited when you can get a five or a 10% increase in conversion. Because it's really, really hard to move conversion. When you see numbers like this, it's really staggering. They also saw a 30% increase in Android active users happening. People are just coming back to this thing much more frequently because it's a better web experience. I'll show you another example. Make my trip. Anyone know these guys? Travel site. It's the biggest travel site in India actually. Their website in the past, when I first spoke to these guys was you go to makemytrip.com on your mobile. You could not book a ticket. It's flights and hotels. You couldn't book. You could search some deals. You could look at fares. And then I would keep getting spammed download app, download app. Every page was like download app, download app. And they were using their website as a channel to drive app installs. Spoke to them about web. I spoke to my PWA. Tried to see if this actually made sense for them. The reason they weren't doing it is because the web just didn't work for them then. Now, if you go to makemytrip.com, it's actually a PWA. Beautiful experience, full transaction, totally like a native app. And they started seeing some very interesting results. They were telling us that they saw half of their bookings that are actually happening on the PWA are same-day reservations. That is not what they see on the native app. And I was kind of scratching my head thinking why, like what's happening. And they said actually what's interesting is, people in India like they fly from a city to another city and then they look for like a hotel for that night. At that point of need, when I'm looking for a room tonight, I am not going to go find an app, download an app, install, set it up, and then find something. I'm looking for it now, I want it now. I will make a search for it. If I see a link, I click and I book. That is instant gratification and a just-in-time need. PWA actually addresses that just-in-time need really, really well. They also saw this other interesting metric on first-time bookings. So the comparison here is, if you compare a user that comes to the PWA for the first time, versus a user who opens the Android app for the first time, the PWA user is three times more likely to actually make a transaction. And again, it goes back to this thing. They open up a PWA when it's a just-in-time need. But an Android app, a lot of people download apps and then they don't even open them. And then you might send a push notification some other day and then they open it, but you don't need it at that point. That's a fairly common scenario that happens. Let's talk about another guy, Flipkart. You guys know who these guys are? E-commerce, biggest E-commerce player in India. They were the first progressive web app globally. And the story with them is really interesting. In mid-2015, they shut down their mobile site. They had a strategy to go app-only. Because they said the web doesn't work, conversions bad, engagements bad, we're shutting it down, it's not worth the resource. Around about that time I went and had a chat with these guys and said, we're working on a bunch of stuff, like we didn't have this PWA terminology figured out then. We just had a bunch of Chrome folks and some web folks coming up with some interesting stuff. Service Worker was just getting formed at that time. I said, do you want to try some of this with us? Like, you know, we're trying to build something that could really be interesting. And they said, well, we fired a whole web team. We've got three or four guys sitting around and there's no website. So sure, like let's put them on a research project. They worked with us over time and then eventually developed something called Flipkart Lite, which was the first PWA globally. These are some of the metrics they were seeing. A 70% increase in conversion. But what's really interesting is this bottom one. This is why they shut their site down. People were not spending time on their site. If you are, what's interesting with someone like Flipkart is it's not necessarily just about transaction and buying, people use a site like Flipkart for market research. Like when I'm thinking about what fridge to get next or what phone to buy, I go to Flipkart to do research. And they actually value that time because that user information is really valuable. So even if people don't buy, they want people to spend time. People are only spending a minute on average on their site. That's gone up three times. That's what they're really happy about. Last example I'm gonna share these guys. People know Lyft, by the way. It's a competitor to Uber in the US. Taxi company, ride sharing. So they said, look, Uber's doing really well. They're a big global player. We need to differentiate. We're gonna try and use technology to differentiate. Here's what they did. They built a PWA for Lyft. And they built full feature parity with native app. You go in there, you put your phone number, you do an OTP, you hit next, you put in some of your details there. This is on lyft.com. Just go to the website, ride.lyft.com. And you get a full map screen view, request the taxi. This is exactly how this thing works. You go there, you've got your destination and everything put in. You pick your location where you wanna go and you can request the cab just there and then. You'll get a push notification when the taxi's arriving. All of that will just happen all on the web. What's interesting is, A, they managed to build full native parity, but not just that. Look at this. I'm gonna talk about download size. This is how big their Android app is, 17 megs. This is how big their iOS app is, 75 megs. This is their PWA, with full map API integration all built in there, under one meg. What makes this really interesting is, if you think about a country like India here, this is actually Lyft did this, but the story makes a lot of sense here. Think about place like India, we actually put a stat out from Google Play. 90% of apps that are downloaded in India are uninstalled within six to 12 months, 90%. The reason for that is people are on low end phones and when they run out of space because they're taking too many selfies, they're not gonna go delete WhatsApp or Facebook, they're gonna delete transactional apps. One-off use case apps. Those are the ones that go. So this uninstalled phenomena is a real phenomena. If you can shrink the size down like this, that issue goes away. Okay, so that's all very interesting, very exciting, like how do I get started? If I'm a developer, what do I do? I'm gonna talk actually about three approaches to how you can actually build a PWN, what people have taken. From the ground up, there's building a simple version, there's going for a feature. All of these are possible. Let's talk about building from the ground up. This is where you basically say, I'm gonna get rid of my entire code base and I'm gonna build from scratch. So what Flipkart did. In some cases, that's actually easier because if you have a legacy code base, you haven't touched for like 10 years, it's easier to just get rid of it and just build again from scratch. An example I'm gonna share on this one is actually Konga. They did this. They completely got it on their site and they rebuilt it from scratch. It's an e-commerce player in Africa. If you think Asia cares about data, these guys really, really care about data. It's really expensive to use data in Africa. They care about it so much, they measure a metric called bytes to first transaction for a user. And when they rebuilt that PWA, they focused just on that and this is the numbers they saw. PWA now consumes 92% less data on initial load and 82% less data to complete a transaction. They're very happy about that. Let's talk about building a simple version. You don't need to go overhaul your entire site. I'll give you the example of Air Berlin. It's a travel company, right? So this airline came to us and they were saying, look, nobody wants to have an airline app. Let's be honest, nobody wants it. But when I'm in the airport, I want my boarding pass, I want to know my gate information. God forbid something changes, you tell me that my flight is delayed or my gate's changed, that's what I want. So what they did is they didn't rebuild their whole site, they didn't rebuild their native app again. All they did is they built an experience that works just in the airport. You open up m.airbilling.com, you put in your ticket number, your boarding pass shows up, you know your gate information, if something changes you get a push notification and the entire thing will work offline. And load in under one second. Very light, very simple, amazing experience. I give another example, Walgreens in the US. They said the same thing, nobody wants a Walgreens app. But when a user walks into a Walgreens, if I can show them like just tap on this QR code or even from a beacon, ping them a URL, that's a store locator, you tap that, you essentially know where every aisle is and you can navigate to where different things are kept and where the stock is available, helps you go and buy what you need and then you check out and you leave and that's it. It's just for that. It's a PWA just to do that. Also another option you could take. You could also take your existing site and piece by piece then that into a PWA. This is where we talk about focusing on a feature. So I give you the example of a other company. These guys said, look, we don't have the time to re-haul our entire site. We can't do that. But what I really want is push notification. Like if there's an earthquake happening or a cyclone coming, I want to be able to tell people that's happening. You can do that. Take the push API, put a service worker in place and add push notifications to your existing site. Totally possible that's exactly what they did all over the world. You could also say actually, let's say I have a big site and I want to, for a particular city, I think that let's say Indonesia or India, my site works really badly because of connections. Add a service worker, do some caching, make performance and speed better just for that piece of your site. Just for that end of your site. Leave the rest of it untouched. Absolutely possible. This is all open tech. You can reuse in the way you want. Cool thing about PWAs and service worker. A, we could have done this in a way where we made service worker and it's a Chrome thing and it makes Chrome better and it's a factor that helps Chrome grow. We didn't do that. We turned it into something that any browser can support. So this is a selection of some of the browsers that are currently supporting service worker and working on it. And in fact, folks from Oprah and folks from Firefox actually helped improve service worker and made it better. So we're all working together to make this thing better. We're all working together to add APIs to service worker. When we first launched it, you could cache and then we were like, hey, it would be cool if you could do a push notification. Somebody worked with us, helped create the push API so you can add that on as a feature. Similarly, add to home screen came. More things are coming. The most recent thing is background sync API. That is where you could actually like, let's say you wanna try and push some data onto your server and you lose connection. It can just sit there and keep retrying every now and then. Whenever a connection comes up, you reconnect and go. It's like what WhatsApp does, like you're trying to send a message and there's no, you get a little timer symbol when a message can't go and when it can, it goes. That was not possible. But now with this API, you can do that. So things are improving, things are growing every day. Again, because of the community and people adding to service workers. The last thing I'm gonna talk about is this. You might think a little bit like this at this point in time. This guy is spoken about AMP and he's spoken about PWA, like what do I do? Like is it like choosing between the red pill and the blue pill? Answer actually is pretty simple. You can really do both. These things work great together. I'm gonna show you one quick example of how these things work together. We get back into this where I can get my demo up. All right, this is my screen up. No, give me one second. All right, so I'm gonna show you how these things actually can tie nicely together and there's a component called AMP install service worker which really makes this happen. Let's go make a search. I'm gonna try Forbes investment guide. You can do this with me as well by the way. This whole thing works for you guys. So I see some links, they're AMP links, right? We've looked at this before. Let's tap on this AMP link here from Forbes. Loaded instantly as we expected. So this web page, just this individual page made in AMP, worked really fast and loaded. Happens to be our trump again. I'm gonna scroll down and I'm gonna get to somewhere at the bottom of the page they have this thing, trending. So they've got more articles they've linked to. This is common, right? You suggest other articles from Forbes that are there that could be interesting. Now at this point, if I click on one of these things, you wanna take them into my experience, into my domain and my site. So when I tap actually one of these articles, now what's happening is I'm going from search to the AMP page into what is now the Forbes PWA. And this whole thing also loaded pretty much instantly. I can swipe across, get the next article there, or the next one I can swipe up if I wanna read. I go back, I can go back to this one. If I wanna read this one, I just swipe up. All of this is already there. This is the Forbes Progressive Web App. So you've taken a user from search instantly into AMP, instantly into PWA. And the reason you could do that is when I was actually on that AMP page, there's a component called AMP Install Service Worker where the service worker for the PWA is already registering on my device when I'm on the AMP page. And that service worker you can activate and start pulling in CSS JavaScript, things that you need to get this page and get this PWA going before the user has clicked. That's how you go from an instant experience on first load and then an instant experience on second load. And now I'm in an immersive experience, completely app-like that works offline and you can browse and read all these articles. Very cool pattern that you can use. You can tie both of these things together. I'm running out of time, so I'm gonna quickly wrap this up. I wanna show you some stats. Wego has actually done this. They use AMP and they use PWA. Look at what their old load times were and look at what their new load times look like now. These static pages, these are those pages that show up in search. That's where they used AMP. Just for those pages, they use the AMP format because it makes those much faster. These core app pages, the website itself, this is their actual site which they turn into a PWA. And with this combination, they managed to go from 11 or 12 second load times to under one second with AMP. And their PWA with that combination of AMP as a service worker and service worker in general gets to 1.6 second load time or 0.36 on second load. Like if I've come to that site and I go back the second time, it's even faster. That is an incredible shift of performance. It's, we're not talking about incremental anymore. We're not talking about I've gone from 10 to nine. We're talking step change from 11 seconds to under one second. And the numbers speak for themselves. Every metric they could measure is up. Visits are up, searches are up, conversions are up. And overall conversion, if you combine all of these things together in the funnel is 95% increase in conversion. Pretty phenomenal. We're seeing lots of success with PWAs. There's many, many sites out there doing PWAs. This is just a selection of them. Again, it's across lots of different verticals. What's particularly interesting is APAC is actually ahead of the curve in terms of PWAs. This is a technology that came out and APAC really embraced it before anyone else. The most PWAs launches globally are actually in APAC. Some of the best PWAs, best in class tech implementations are also from APAC. And like people come and ask me then as the guy who runs APAC, what's going on? Why is this thing taking off in Asia? And I normally leave them with this slide. Which is where I'm gonna leave you guys today as well. And then it says, essentially in Asia, if you think about emerging markets, there's a bunch of challenges that are very particular to our markets that people in North America will never experience. Affordability is a challenge. Intermittent connectivity is a big challenge. Low end smartphones is a reality. That's what people are on. And for these people and on these devices and situations, it's really simple. Impact, I put this equation and for the mathematician, it's not actually an equation. Impact is essentially a factor of time and money. Simple as that. If you can save people time, things like AMP saves people time, it loads quickly. And if you can save people money, in this case, I mean data is equal to money, which is a reality. And with PWAs, whether they install and the fact they can lower that data use time, you're saving people money, good things start happening. That's why this thing takes off in our markets. That's why I was excited to speak to you about it today. Thank you so much. I think we can take one question at a match. So we talked that Google has an AMP cache that crawls the websites that are implementing AMP and stores them in the cache. Yeah, so is there any upper limit? So is the cache maintained on the user end or it's maintained by Google? Or is there any upper limit on the cache? So all the websites have started using AMP. So what will be the impact? What will the low time be? Cache is completely open. There's no limit on the cache. Every AMP page that is out there that is valid will get picked up in the AMP cache. And not only that, it's not just Google. Like for example, when Baidu's gonna do this in China, Baidu's gonna open up their cache for AMP. So AMP pages that show up, Baidu will cache it on their caches, which they're calling AMP caches. It's also easier because these things are just much lighter and simpler. So you don't have huge data issues with these things. Yeah. Why do you introduce this AMP syntax to HTML and not just extend HTML itself? It's a good question. Yeah, so I'll just repeat the question. The question was, why did Google introduce this new syntax, AMP HTML? Why not just extend HTML? Part of HTML5 for example. Actually the reason for this, we didn't start with that part. We started by talking to lots of publishers, lots of technology companies, analytics vendors, everyone who plays in the web ecosystem. And the first thing we did was realize why are things slow? And the reason things were slow is there's a lot of stuff that sits on web pages. And actually optimizing these things is science that people build through brute force and pain. People who are looking for something that's simpler. Like can I just follow something? Give me all the flexibility, but can I follow something where if I do like these 10 things in the right way and then everything else I control, things will work fine. That's what they were kind of looking for. So it's not really that we've created a new language per se. Like AMP HTML is just HTML. It's just a library you have to load up. And it works totally fine. Like anywhere HTML can load, anywhere HTML works and renders, AMP will work. The idea was to just make it really, really simpler. Like if you really broke down everything and said, let me start from scratch essentially, putting a web page together. What are the components I need? How do I add them together in a fashion that is optimized specifically for speed and build it up that way? That is what we were trying to do. Hence why we have this concept of valid and invalid. Like you can make a page by the way, that's an invalid AMP page. You can do whatever you want to do with it, not follow the rules of AMP, et cetera. That page won't die. It's not like the page won't work. It just won't have in places like search, you won't get that treatment of AMP with a lightning bolt. It won't end up in the cache. You won't get the pre-rendering benefits and you won't get all of the optimizations that AMP gives. And hence it can still be a decent page, just not as fast as what we were saying. If you make it valid, that's when you get instant loading. That's kind of what we're going with. Any other questions? All right, I think we're gonna take a more questions offline. Okay, sure. But let's give a round of applause for Anurvath. Thank you. Thank you.