 How are we doing? Are we all good? Hello. Hi. Welcome to the fireside chat about progressive web apps. I'm Paul. And this is the panel that we have here. So what I'm going to do first is introduce them, and then I'll just explain what it is we're going to do. So we've got Dion Almayer right here, who's engineering director from WebDevRel. To his left, Jake Archibald, developer advocate. I could be so much ruder, but oh, it's taking so much effort. Immediately to his left, Dmitry Glaskov, who's a software engineer on Chrome. And then it's Alex Komorowski, who is group product manager on Chrome. Who's next there? Owen Campbell Moore to his left. There we are. Product manager, Adrian Portafelt, who's a software engineer on Chrome. And then last but not least, Alex Russell, also a software engineer. So we're talking progressive web apps. And if you've got any questions during this, there are microphones to either side. Please do use them. Please come up and ask your questions. But do use the microphones, because it means that they get it for the recording. So that'd be great. But we also put out questions onto Twitter and Slack and so forth, and we're going to probably start with some of those. Also, on the screen you can see URLs for pinging at Chromium Dev and the Slack and so on. So you can also ask questions during that way, and they'll make their way to me via the power of Google Docs. OK, so the first question that we got through, which is going to go to Jake, I think, how should I build a progressive web app when Safari doesn't support service workers? You should use progressive enhancement. Is that the correct answer? OK, you're looking at me like I'm somehow responsible for the question. I mean, this came in seriously, though. Come on. Yeah, so I think progressive enhancement is the right thing to do here. When you first load a page, even on a browser that supports service worker, that first load is going to happen before the service worker installs and activates. So you can make a site depend on service worker, but we designed it so you have to jump through hoops in order to do that. And if you do jump through those hoops, I might try and find you and kill you, because I'm a true believer in the whole progressive enhancement thing. Are you threatening bodily violence on a panel? No. What's on the crowd? But once a bit late, so when you start enhancing with service worker and things start loading faster in the browsers that do support service worker, which is at the moment Firefox and Chrome and Opera, then that becomes good evidence for the browsers that don't support service worker to just start implementing it or to make their implementation faster. What I'm saying is you have to control here over the future of the extensible web. But there is a sense in which a lot of the things that people look to from a progressive web app, they do rely on the service worker, right? I mean, this is what people are, it kind of feels like that, right? Well, we've survived for a long time without service workers and the web was still usable. So being able to add these features into to get more engagement, I think that's a great thing. I think, too, that progressive enhancement is so important that we made it part of the name. So that just gives an emphasis on how much we think that's central to the idea. In fact, we just published a case study yesterday, AliExpress, which is a company that is an e-commerce company. They built a progressive web app. And in doing so, they also invested in proving their mobile website. And they actually saw a lift of, I think, 82% in the conversions they saw on mobile Safari as well. So the idea is that by investing in your mobile website is always a good idea. It just so happens that in browsers that support service workers, that experience will be super charged. So I think it's really quite compatible, actually. And we saw this already with things like the Facebook website. Their website has been there for years. And then they've added service worker in as an enhancement. And now you get the push notifications, and hopefully soon some kind of offline first experience. And now they're seeing more usage grow because of that. I mean, I don't know the figures that, but I know it's definitely from one user. I use the website rather than the native app now because of that. Because it does everything I needed to do. All right, let's move it on. Oh, this is a good one. How do progressive web apps work with AMP? That'll be, I guess, Alex Russell. Without which? With AMP. AMP. Oh, yeah. So for those who haven't seen the sessions, AMP is a web component dialect for making very, very fast loading pages. Usually articles, content articles. But AMP has a validator, which means that you can't run your own scripts. You can only run AMP scripts, which is how AMP continues to stay fast. That's why AMP files generally work so well, is that the validator keeps you from running your own or third-party scripts. So this seems incompatible with service workers, which require you to register a service worker. The good news is that the AMP team has built an AMP install service worker element. And that element is something that you can use on your AMP pages. So from there, once you have the service worker installed and running on your site, you can intercept navigations like you normally would to serve up an app shell. And that can be an AMP viewer. So you can keep the same content while upgrading from a relatively bare bones, but super lightweight AMP experience on first load to getting that richer, more immersive, more engaging second, third, fourth experience out of the gates very quickly once the service worker is there. And again, it does the progressive enhancement thing, because you start with a totally valid, completely workable AMP document, which is a great way to read content. So AMP is a starting point, adding service workers and then layering in your app shell later for a custom behavior for richer stuff. Once you know that you've got that cached in the service worker and you don't have to wait on the network to get that more immersive behavior, I think is this golden path. I think that's a great way to go. In fact, you've got to talk about this tomorrow, right? I've got to talk that outlines what the Washington Post did tomorrow, and we'll be talking about this extra sort of additional opportunity at the end, yeah. Did you guys see the Washington Post progressive web app with AMP demo that was today? Yeah, so I think that really shows off the experience. And Alex, you talk about how progressive web apps are just web experiences that take their vitamins. I feel like AMP is like the prescription medicine, where it's like, hey, you guys, you've screwed up for too long. Here's a quick pill that will help you, but you may want to change your lifestyle and take some vitamins. A little bit of exercise, a little bit of healthy eating, yeah. Interesting thing that Washington Post is just the beginning of experimenting of how this stuff fits together, right? I mean, there is probably more interesting integrations that you can think of. Just a follow-on, because there is a follow-on question. Again, I guess it'd go to Alex. But is there a development strategy which allows you to have that one code base that will service both the progressive web app and AMP content? And can you reuse code and so forth? Yeah, I think what I just outlined basically is that strategy, where you catch your navigations in the service worker and serve up an app shell, which has that more advanced, more customized slicker behavior, only for the users who can support it. Once you know that it's going to be cheaper free, only when it's cached locally inside the service worker's caches and you don't have to go to the network for it. But all those URLs should load nakedly as regular AMP documents. And you can move an entire site to AMP today, have it on your origin, have it proxied out to the CDNs, have it validate. And that all works thanks to the AMP service worker element. All right, let's move on. Question, it sounds deceptively simple. When does my website start becoming a progressive web app? And the context here is, let's say I just add push messaging. Have I got a progressive web app now? Who would like to take that one? For me, and you can feel free to correct me, it's when Chrome will start offering users to add it to their home screen. So it's a set of requirements there, which is HTTPS, it's having a service worker. I think at the moment it's just having a service worker, but we're going to tighten that to offering some kind of offline capable experience and having it manifest so all the icons are in there and it's displayed standalone. So the user can add it to the home screen and it will look like a native app. And this is why we require an offline capable experience because we want users to, when they have a home screen icon and they tap it and it loads with it in Chrome, we want it to feel native for them. And if the browser has to show a default connection error message, then that breaks the native contract. A way I think of progressive web apps is actually a more general concept that you want to reach towards. Just like Ajax, it was like back on desktop web, it wasn't like, when am I Ajax, what does that mean? I mean, you can always be doing more and providing a better experience that's more in line with that golden ideal. Yeah, and I think when Jake mentioned Chrome there, that doesn't mean only when Chrome does it. Of course, lots of the browsers are supporting all of these features. Yeah, so on a technical level, Chrome implements those specific heuristics. Other browsers may implement different heuristics and you might imagine getting progressive web apps different ways. The fact that we have this one prompt that triggers at this one moment, which from a user perspective can feel a little bit arbitrary, is basically an implementation detail. All the technology is very open. It doesn't demand that browsers create any specific UI. So I expect to see a lot of evolution actually in how browsers present the ability and willingness to keep these things to the local system and how you run them. I expect that to sort of change a lot. You can imagine listing these things in stores or having persistent UIs that tell you that, hey, this thing is a progressive web app, as opposed to that occasional prompt. Those are all possible features that other browsers can explore. In fact, we're also exploring different treatments for it and seeing other ways to improve the treatment we've got today. I also want to correct one thing, though. I think a lot of people think of progressive web apps as it doesn't count until it's on your home screen. And to me, that isn't the be-all end-all that it is with, for example, a native app, where it's the same thing. And I think that users can get value out of it from push notifications or just from loading more quickly when you come back to it. And so the fact of the matter is, not everyone's going to want to add your thing to their home screen, and that's fine because you can still create a really meaningful experience and add value for them. And as you do so, maybe over time they'll say, you know what, you are pretty cool. Maybe I will add you to my home screen. De-coupling these was sort of this thing where we had to give it a name at some point because they added up to an experience, but the goal was an experience for the user and not a particular bundle of things you had to have all at once. The native app model of having to go through a particular huge transition, a big step phase change, a big step to get to the moment where you can do all this stuff because you said yes to it all at once, that's pretty tough from a user experience perspective. And so we want to make them more a la carte. And the fact that they add up to that ability, that moment where you can get out of the home screen or that moment where you can ask for push notifications, that's just the strength of the web being more a la carte. What you're talking about before, like being able to have some kind of store or place to find these, I think that's really interesting. I think that's something I would like to see Google take on is to create some kind of engine for searching content on the web somehow users can find these. That sounds really hard. It feels like a space we should get into. So Jake, since you started talking again, there is a fall on. Because you mentioned the fact that offline's a thing and actually Alex, you kind of mentioned that it's about the experience, not necessarily checking all the boxes. Why is it then that app cache isn't valid as part of the requirements list for a progressive web app? So I've had a lot of questions from internal teams in the last couple of months about why isn't app cache good enough? And so I wrote a document, which I haven't shared publicly for obvious reasons, called app caching your architecture not even once. And the TLDR of this document was basically, you start with the best of intentions and app caches design decisions cause you at every moment to contort yourself ever further away from the experience you wanted to deliver. And before you know it, you've centralized on a single URL and you've decided that you're gonna do hash navigations and not push state and that you're gonna do offline only and not reliable performance, that you're gonna give up on a bunch of the experience differences that you're really trying to affect to get to something that app cache will allow you to do. And so I think it's worth sort of understanding where the endpoint of that journey is and then deciding that that's not something we should buy into. It isn't that app caches bad technology, it's just that it's not designed to build reliable performance, it's designed to give you special case offline. And special case offline kind of isn't worth having because offline is very much a special case. You're only in an offline mode, very occasionally when you set your phone into an offline state or when a navigation finally fails. But you're on a flaky connection basically all the time. And so handling the flaky connection and getting reliable performance is the goal. That's the user experience win and confusing the two doesn't really work. It doesn't help anybody. Plus we keep finding horrible security things in the app cache spec. Oh yeah, we're taking it off of HTTP by the way. Yeah. It's just BS though. Kind of terrified. Okay, let's move on. One thing. A lot of people spend a lot of time trying to make app cache work and went through all of this pain. Jake, for instance? Yes, this guy, but lots of other people. And so we did release just the beginning of a library today or yesterday that tries to kind of say, you know, if you've done all of this work to generate these manifests and all that like, that's a lot of work. So here's a path to make that work with service workers. And then again, hopefully you then kind of move off over time. So if you do have app cache working now, we're trying to make that pain go away a little bit. And it doesn't have the security bugs that app cache does, so safe to use. Okay, the next question is a security related one, I suppose. Will we ever get signed or trusted progressive works with the same security properties and the privileged APIs of Chrome apps? I guess, Adrian, do you want to take that one? Yeah, that's actually a very interesting question. I've heard a lot of developers asking, when will we get specific APIs that I really like from the Chrome apps platform? And the answer is that we want to keep the web open so that you click on any link and you as a user don't have to be afraid of what's going to happen when you click on that link. And so for that reason, we're taking a very reasoned and measured approach when we look at the different APIs that can be adopted by the web. I don't think that signing and packaging are necessarily the distinction here, rather it's the discovery mechanism. Is that you're getting to a website just by clicking on a link, you don't necessarily know where you're going. And we wanted to just begin working immediately. So our approach has been runtime permissions for the web where we try to, first of all, design the APIs to be safe by default and then have permissions where users can opt into experiences that might potentially have some amount of security risk. Although again, our first aim is to do it through designing the APIs that there are no major security risks with any APIs. And this takes time and we have to think very carefully about which APIs we release. So in the long run, I'd like for most APIs, many of the cool things that you could do in Chrome apps to be available to the web, but it's not gonna happen overnight because we have to make sure that the security experience for each one is done correctly. I think it's a really important broader point too. The web strength is it's low friction, the ability to just tap that link and get to another experience. And that's one of the things that enables so many really cool business models and so many interesting, diverse things on the web. And it's not like we all woke up one day and said, you know what, it would be great if by tapping on a link, we could load it immediately without an interstitial. That's part of the design from the very beginning. It's been very meticulously managed and evolved and strengthened over the past 20 years. And it's something that's fundamental to why the web is so successful. Okay, we've, don't forget, you can come up to the microphones and ask your questions if you've got them, but there's an interesting one that's come in on the Twitter. Android Instant Apps brackets no need to install versus Progressive Web Apps. How, slash where, do you see each being used? Cage match. Roamed one, fight. In all seriousness, so of course at Google, I think we're a large company. We always want to make sure that developers are successful on whatever platforms they choose. The way that I think about it is the web has historically had this really low friction which I conveniently just talked about. That's very important to this awesome, diverse ecosystem, but it's also had low capabilities. And if you look at native apps, those have historically had very high capabilities, but also very high friction, in part due to those capabilities. So Progressive Web Apps has been a multi-year effort, working with standards, working with other browser vendors to design these APIs very carefully, to maintain and allow us to responsibly bring these capabilities to the web. And I think that Instant Apps is the same kind of multi-year journey to bring the lower friction to native apps as well. So I think that really cool demo that I think we all saw on the keynote is something that's like an aspirational goal to get to, and I think will be a really cool place. Now, one of the reasons I love Progressive Web Apps is because it's just web technology. We've been using this stuff for many, many years. It's been evolving all the time, and you can deploy these things today. In fact, we published seven additional case studies from businesses around the world, Indonesia, India, Africa, many other places, just yesterday, showing businesses having really, really, really strong business metrics by adopting these technologies. And that to me is one thing that's so cool about it. It's cross-browser, it's cross-platform even, because we've seen lift and conversion rates on iOS for people who invest in web. This is something that works on standards with other browser vendors as well, and you can use it today. That's why I think Progressive Web Apps is pretty cool. In terms of choosing one or the other, if I had to push you on one, on the basis that people have to make a decision often internally to their own businesses, okay? They have to kind of go, which way are we gonna go? I think the way you would choose is, do you stop at Java, or do you add the script onto the end? Okay. I think one piece of that is what is Instant Apps really gonna be like, right? A lot of people are coming up to me and they're like, oh, so I saw this demo, I tap on a link, I'm into this full experience. I can buy things right away. There's access to all of my payment information. That's amazing and really scary from a security plan point as all access to all of this background. Wait a minute, how does that work? Obviously, there wasn't enough time in the keynote to go into all of the details of here's the sandbox, here's how things will work. So I don't think it's as black and white as, oh, Instant Apps is you just do this native app that has full capabilities versus the web that has this poor sandbox is like Alex was saying, where that sandbox has been a huge advantage for us. And I think it's fair game for Android to come in and go after the things that we're awesome at. And I think it's fair game for us to go after all of the things that are good on native platforms. Super. Why is add to home screen not on desktop Chrome? It seems like a big potential market. That would be Alex Komorowski, I think. So one thing I'm actually interested in is who here would be interested in that if we were to ship it? Well, there's hands. There's definitely hands. There are definitely hands I can confirm, but interesting. So we focus primarily on the add to home screen behavior on mobile, primarily because it was so simple to reason about from the user perspective. People are very used to on mobile, you tap a thing, it goes full screen, they get how that works. It's on their home screen, that's where you find all this stuff. And frankly, by the way, we actually aren't happy with the behavior today. We see that as a first step that we're gonna constantly be trying to evolve so that users, once they add it to their home screen, they can kind of forget about the fact that it's a website because right now there's actually a number of tells. I think we had some other questions about that as well. And so if you look at desktop, it's actually much harder to imagine what precisely does that mean? When you tap it, does it load a window with no URL bar? Does it load a different thing that appears to be a different app? Is it just another tab in within Chrome? Is it a desktop icon? Does it show up in the dock? Is it in the start menu? There's a lot more questions to reason through. And we're always looking for developers to give us more, to tell us about these use cases, the things that you want to accomplish to help us design this in a way that makes sense for our users without complicating the product. Because obviously, with Chrome it's all about simplicity. One of our key tenets. We wanna make sure that we don't overcomplicate the product just for this kind of uncanny valley thing that doesn't really make any sense. But we're always looking, this is something that we definitely wanna do. We just wanna make sure we do it right. Yeah, so just to add to that, I definitely think that that's right. So if you have thoughts about this, come and chat to us, tweet at us. We'd love to talk more about it. We've been actively going out and talking to developers to find out what they would need to make this successful. I also wanna give a shout out while we're talking about it to the Electron project that the guys over at GitHub have been working on. So this is what powers the AtomText editor and a bunch of people are building desktop applications using web technology. I think it's really cool that you can actually take a progressive web app using service workers and you can wrap it in Electron, which is essentially Chromium. And you can essentially just point that at your point that at your progressive web app and give someone a little file to install. And then you can give them that experience and you have full control over the UI around the browser and you can add extra bits with additional APIs they have. So we're kind of watching what's going on there. We're looking to see how Electron evolves and what developers need evolve and trying to work out how we can handle the complexity of how to fit it into the existing product at the same time. It's been really satisfying to see with that kind of base layer there, like the Chromium, like Electron thing to be able to become a native app, to see apps being able to compete on different things than that. Like you say Atom, but there's also Visual Studio Code and to see them competing on a different feature set. But most of it's been sort of dealt with, so they're able to build that stuff really quickly. That's really satisfying to see. Aji, one last funny anecdote. I was thinking recently about why web browsers are great and why a different operating system window management is great. It's funny, because we did a little user study where we got, there's actually, interestingly, we should have mentioned this. There's a prototype of this implemented in Chrome today if you go in about flags. There's a flag. It's actually on by default in Chrome OS, I believe. It's on by default in Chrome OS, that's right. So we do have add to shelf prompting on Chrome OS and we have it supported on Windows and OS X behind a flag. So you can go in and try that out. I think it's called add to shelf in there. And so it's funny that we did some user studies recently where we brought in some users and we asked them to try this experience and got their feedback on it. And one of the things that came up was, wouldn't it be great if operating systems had tabs so I could have all of my different windows? And so anyway, so I think you have to think about the benefits. Window management is complicated and we have to think about it very carefully, so. I also always love to, when I talk to someone who is kind of anti-web or whatever and they're like, yeah, I mean, you could never use a web app. It's not good enough, the quality. So I noticed you're running Slack there. How do you like Slack? Oh, it's great, it's fantastic. No, yeah, using Adam, using visual code on them. Oh, okay, next. No, okay. The subtext there, in case anyone doesn't know, so Slack uses the Electron project and it's essentially their web version using the Electron shell. So, and you can build these things that work offline and do the native-like experiences using the same one code base that you do on the web for the native experience on desktop as well. Okay, before anybody else on this panel goes, this is one more thing, I'm just constantly twad. Sorry, I'm gonna enroll it to the next question. If San Francisco doesn't pay attention to progressive web apps and focuses solely on iOS apps, will Google abandon PWAs in four years? I like, there's a very specific timeline. And San Francisco. And yeah, it's only San Francisco. I would not like to run it to a least Silicon Valley and the rest, but I'm all the same. There is this obviously implied question, I suppose, that what is the metric for success here, I suppose? So, first of all, by any reasonable metric of success, we are blown away with all the amazing stuff we've been seeing happening. There was a last week, there was a case study for a company called Celio, I believe. I had not heard of this company before. They had a presentation talking about how they did progressive web app. Now they had amazing stats. That's amazing to see that kind of self-sustaining and organic momentum going on. I check the stats every morning. We see a very, very, very healthy growth across all these different areas. So we're very, very happy with how this is going. But I think also, at this point, we've shipped these technologies. Other browser vendors are also working to ship service workers and others. Samsung has shipped progressive web app support in their S browser entirely, including push notifications, Firefox has shipped push notifications, Microsoft is implementing service worker. So obviously we plan to continue investing a ton here. This is the first step. But even if it weren't, that's the cool thing about the web. We have always other browser vendors also pushing, also innovating, trying different UIs for this, which I think is one of the strengths of the web. Yeah, I think another thing is, sometimes people come out, oh, you've got the best job. You get to work on the web, you love the web, you can be this hippie guy that floats around San Francisco and Silicon Valley. Why do you point at me when you do that? Hippy bald guy, I mean. But then I also kind of point, I think it's actually important that people understand this and it's kind of obvious and people know it, but we make money on the web, you know? It's like, we're not just altruistic. We may be altruistic a little bit and we love the web, but Google makes money on the web. So it would be kind of weird to destroy the web. Might be bad, yeah. The other thing is the San Francisco thing really rubs me the wrong way. Because actually most of the success we see is like in India and Indonesia and like the countries that actually feel the pain of installing, of the barrier of the installing native apps because it takes a long time to download and it's much easier to just click and get something fast. Well, I think the question might be motivated between the disconnect between the success that we're seeing, specifically in emerging markets with progressive web apps and the sort of prevalent tech culture here, which sort of, it's literally privileged in every way I can think of. And that privilege sort of blinds us to the fact that for most people the dominant technology that we've shipped on mobile operating systems basically doesn't work for the next billion users. It just basically doesn't work. And as a result, we have to do something different and progressive web apps are succeeding because it is that something different. Yeah, I've been blown away. We've talked to a ton of developers in India and Indonesia and many other places and just blown away by the amazing stuff they're doing. And I think to some extent it's like, come on, Silicon Valley, get together. What are y'all doing, right? We're seeing some of the people pushing the forefront of this stuff around the world. It's really- I mean, the AliExpress team, you gotta go try this on a phone. Go try AliExpress or Celio. I mean, these are Flipkart, right? These are incredible experiences that are making people real money and they're making people real money in places where it's hard to do that. I mean, I think what you didn't mention about the Celio slide deck that was going around Twitter last week was that the number specifically that they showed, the one that got me was they had similar engagement between their native app and their progressive web app, version of the same experience, but their user acquisition costs were one-tenth with the progressive web app. That literally changes the trajectory of your business. What are you doing if you're not doing that, right? Like, how do your numbers add up if you haven't made a progressive web app that can do that for you? All right, let's- We have a question from the floor. Don't go on too long because I've got candies I can throw at you if you're- You're on the- Go for it. Progressive web apps sound like quite a unicorn. I'm wondering if there are use cases where it's maybe not the correct approach to take or do you all foresee service workers becoming as ubiquitous as JavaScript, CSS, and HTML? Terrific. Thank you. Who wants to take- Jake wants to take that one. Well, so, and if you saw my talk earlier, sorry, I'm going to repeat something. The- If you look at the IO web app and a lot of sites that sort of use service worker to work offline, they tend to show a little banner sort of saying, everything is cash, this will work offline now. And I think it's cool. I think it's great that we're, you know, these sites are bragging about that because there's not a lot of user trust there. But I hope one day that that starts looking like those little badges we used to put on our sites, like, this is made with CSS 2.1 and how ridiculous that looks now. And I hope one day when a site's like, I work offline, you're like, yeah, well done. It's the web. It's supposed to be like that. I'm going to just remove a banner from my website. So that's awkward. And so I have a secret hope here, which is, so service worker is a very powerful primitive, is how I think about it. And I actually expect that most web developers won't be using it even directly. So there's this great library called Service Worker Toolbox, which a lot of big companies are using as their abstraction because that's really what you want when interacting with a service worker. And so I would expect to see this to go further where we get to a point where if you're using like a big framework, you're using your Polymer or your React or whatever you're using, or if you're building a website, the tools that you're using have caching and they have service worker built in. So when you start building a web app with any of the systems, you start with this offline and the high performance. So building it into the tools and in open source projects, I think is going to be key. In fact, I think the Polymer team just showed this purple pattern. If you didn't see the talk earlier, I recommend you go find Taylor Savage's talk. But their pattern also comes with a CLI that does exactly this. It generates service worker assets for you based on the routes that you provide. And it gives you that pre-caching pretty immediately. So that stuff is coming very quickly and it's exciting to see. Okay, dope. Okay, let's have a look. Ooh, Dimitri, my site loads in less than a second, but then ads. What can I do about poorly performing ads? Mind you, you can just get rid of ads. No, I'm, it's, oh. What's the make on money then? Well, it's a tough question. Ads are a part of the ecosystem of the web. This is where a lot of publishers make their money and make their living. And figuring out how to fit this into a healthy website sometimes is very challenging. And most of the time, this comes together at the last moment when you built your website, polished it and it looks really good. And then you've added those script tags or things and suddenly everything goes to a terrible, terrible performance hole. And I think we as a web platform, as a Chrome browser, do have certain responsibility to protect the user and act on the user's behalf in some cases. And we're actually actively exploring this field and trying to make sure that the most egregious cases where they ads truly either don't know what they're doing or doing something that they shouldn't be doing are prevented and are not happening and so that the user still gets good experience. So one pattern we see a lot when we look at real world websites that have jank or what have you, is you look at it and it's like, why is this simple page drinking when it's scrolling? And there's like 12 analytic scripts in there. There's like four different ad tags and they're all trying to calculate viewability of different elements all at the worst possible time in scroll events. Actually, Rahul showed in his, I'm gonna call it keynote, what's it? State of the Union, State of the Union. Today, passive event response, which actually makes a really big difference because it allows you to say, hey, browser, I'm never gonna cancel this scroll. Just using it as a convenient time to run this calculation, that makes a huge difference. In a lot of cases, we're quick to blame ads and ad networks, but our outreach and just talking to them shows that they're actually actively interested in solving this problem as well. It does not make them happy that people hate ads because it does not work real well on the long run. And so, we've been working with them on some of the primitives like intersection observer and passive event listeners to effectively enable them to do some things cheaply instead of clogging up the whole system. Okay, all good? All right, yep. Let me see other progressive web apps in Google products. If progressive web apps are the answer, why isn't Google Inbox a progressive web app? Or any other Google asset for that matter with the notable exception of Air Horner? So, ah, ah, there's anyone? No, actually, people get silly about Air Horner, but actually Air Horner is really interesting to me because it does one thing and it does it really well and it's really fun. And it actually does a lot of the right things for a sort of, you just search for an Air Horner app and you find loads. Really simple user interface. And my kids love it. It's not in a Google doodle, you know? Air Horner on the Google logo, that's what's interesting about this one, though. It's a dangerous question to ask because we get to dog food the next versions of all of the Google products. So I may make a mistake and be like, I think Google Docs has shipped all of this because I've seen these push notifications. Oh, no, no, no, that's not right. That's not public yet, so we have to be a little bit careful. No comment. Spaces is a thing that's now, I mean, it's a lot. Spaces is a progressive web app, right? So they use push notifications and much more of their stuff. Amox is ship caching with service workers. Yeah, there's the TLDR is that service workers are great for performance and that you build really great things. So naturally you'll be unsurprising that Google teams love performance and making things faster. And yeah, there's lots of active investigations in this space and you will hear more about some of them. So there are a few in live for small fractions of users. So if you're a lucky user and you start getting push notifications or you start seeing the site going really fast, look for a service worker, tweet it if you find one. There are a few of these things out there. Yeah, so go looking and you'll start finding things. You can actually see them DevTools. Sort of relate to that since people are going to be looking around and being like, hey, look, it looks like a progressive web app. Wouldn't it be great apparently if we had a, I'm saying apparently because I'm actually reading somebody else's question. It's not like I made it up. Wouldn't it be great if we can have a progressive web app store similar to the Play Store? pwa.rox is there, but I'm not sure how many people know about it. Yeah, I see pwa.rox as more of a, at this point of just a cool place to go to find a bunch of great examples. So if you don't know, it's a site maintained by Opera DevRel and a bunch of awesome progressive web apps are all listed there in different categories. It's a great go-to place. And so it says, what's a progressive web app? Well, here's a whole bunch, but it's obviously not the end goal. One thing I think is really interesting about this question is the link is like the superpower of the web and the fact that you have all these different discovery mechanisms and that someone can text you a link or they can email you it or you can find it on a search engine. That's the power of the web. And in some ways, actually, app stores had to create stores because there was no other way to find them. And so although I think there is, it's definitely an interesting space. I'm interested to see what happens here and I think there might be some other stuff that we could do here. It's also one of those things of like, we don't necessarily, it's not like we're dying without it at this point. I think there's an interesting missing link here, which is that if you go to something like pwa.rox, you can't choose to keep any of these directly. There's no sort of, you go to the experience and then boom, there's a button you can press to say install or keep or whatever the action is, then the browser, like in Opera, it's the star menu or the plus menu and in Chrome, it'll be the thing that comes up from the bottom, right? So in Firefox, it'll be the thing that comes up from the bottom. So those are different experiences that you can get but there's no button you can press that you know, hey, this thing is a progressive web app. I think that's an area where browsers need to innovate a little bit. We need to make it clear to users when you're in one of these experiences and that you can do something about it. But I mean, the technology's all there. That's just a, you know, it's a mere bit of UI. UI, it's not very hard, right? That should be very straightforward. I'm not a product manager, so... Yeah. But yes, we are very, again, at this point, even the UI treatment in Chrome, we don't view it as like a V zero. Just as a first step to enable some of these things. And it's really interesting watching as people deploy these things and as they figure out what the best practices are or how to reason about how these fit with your app or with your mobile web, your desktop site, it's gonna be really interesting to see how this all evolves, I think. So, I'm excited. Kind of behind the scenes, I get a little bit of help with things that are kind of coming through, as you might have guessed. And I'm still a little bit concerned because I've just got a question that says, isn't airhorner.com the best? So I think my helper, Paul Kinlan, is finally losing it. So I'll give him a bit of a hand after this. Now, the next question is around HTTP and HTTPS. We've recently seen the deprecation of a bunch of features or deprecation, movement to HTTPS flight geolocation to get user media, that kind of thing. Should we be expecting any more wired service worker on HTTPS and all that kind of stuff? Let me start by explaining why we're doing these deprecations. The things that come with progressive web apps and other APIs like geolocation, they're all very powerful privileges that we're giving to websites. And we want to be able to trust websites with those privileges. And the bare minimum of trust is HTTPS because that means when the privilege is given to your website, it's given to your website and not your website and also all the friendly people on the network. This is also especially important for service worker where friendly people on the network could stay around for a long time after the user leaves that network. And they really are friendly people on the network looking to enhance your browsing experience. So HTTPS really is important. And we are trying to make it easier and there are also lots of other people trying to make it easier. Certificates are less expensive. There's been huge gains made in areas of performance. Many of the ad networks now support primarily HTTPS or support a lot of HTTPS. So I think there's been huge gains in this area. If you haven't seen Emily Stark's talk, which she gave yesterday, she covers a lot of this in detail, talking about dealing with HTTPS and redirects and performance and things like that. And I strongly encourage you to go see it. And I think HTTPS is the gateway to all this new stuff and it is without question the future. So if you're dragging your feet, get on it. And I forgot one part, which is we do have a few more deprecations coming. Alex alluded to AppCache earlier and also long-term we see EME moving to HTTPS only. We don't have specific timelines that are public yet. These are medium to long-term plans. But if you rely on either AppCache or EME, I do encourage you to start the transition to HTTPS now rather than after we make an announcement with a timeline, because it'll be much easier if you can start investing now when it's not an emergency or a rush. Although we will make sure that we do this responsibly. Yes. Oh, we have a live question. Hello. Okay, so my question is this. There is a recent report saying that a third, mostly a third of the Android users are browsing the web through Facebook or WebView, mostly Facebook. So that's a challenge for a pressing web app and service workers and having the app installed on it. So what's your thoughts about that? So one thing we announced is, I think was that Chrome Dev Summit or last year I can't remember, Chrome Custom Tabs is designed specifically for this. Yeah, yeah, but Facebook is not used and then I don't believe it today, but we are seeing huge adoption numbers from Chrome Custom Tabs. It's just through the roof from many, many different providers. Facebook, I believe doesn't use it at this point. Twitter does. Twitter does, many of the social media. Basically, everybody else, as far as the browser. From a user perspective, you should understand that if you don't see Chrome Custom Tabs in an in-app browser, that means that that application is fundamentally insecure and that you should go find the setting in that application to disable the in-app browser. It's not okay to be loading arbitrary content into a WebView. It wasn't designed for that. It isn't prepared to handle that. It isn't prepared to handle the TLS questions, the communication with the user about what's going on, not to mention any of the feature questions about the features that are missing. So that's bad. Just FYI. And Facebook should feel bad, actually. They should feel bad. So. There's one of the things that terrifies me in native apps is when, like, what looks like a WebView, but it might not be, I don't know, says, do you want to log in? I'm like, yeah, I want to log in and then it shows me the Google login box and I'm like, I don't know where this is. I don't know where this is going. I don't know if it's secure. I don't know if it's on evil.com or whatever. I mean, that's why we created the custom tabs. I like the term insecure because it makes me wonder if the WebView really is worried that people, that it doesn't display content properly and whether anybody actually really likes it. We have another floor question. We have not too much longer left, so let's go for it. Mine's just a short comment to add to the HTTPS. The comment is Firebase announced custom domains and HTTPS support for free, so you don't have to buy certificates or anything. Yay. Nothing good as well. Okay. I'm thinking of using Angular and or React. Please don't make that anand. And Ember and Polymer, all of them in one. Welcome home. I might have embellished. Will that work for a progressive web app? Dimitri, would you take this one? Yes. Cool. The popular web app. Well, all of them will work at once or just individually. No. Define work. They will do a lot of work. If the app is to turn your phone into a personal heating device, then it's probably the right thing to do. In all seriousness, I think a number of progressive web apps that have been shipped today, I think I've been using React. Flipkart, for example, has built React with React. It was a great talk from Chrome Dev Summit where some of the Flipkart engineers, I think we've got one tomorrow as well that you will be presenting that. So you can definitely use React. I think I've seen some Angular stuff as well that it talks about progressive web apps too. So the point is this is not about which technology you use to help you build your app. It's just about the fact that it's a web app. And there are lots of different ways of doing it. Although please make it fast. Yes. Yes. Please, please, please, test on a real device. Chrome, colon, inspect, over USB to a real device is the only way to fly. The truth is in the trace. If you didn't see it on a device, it doesn't count. Your desktop computer is lying to you. Get a phone, plug it in, do the real tracing. Everything else is just you lying to yourself. And actually it's, yeah. It's never been easier. There really is like plug it in. USB debugging, Chrome inspect, and you're fine. I love it. It's like totally one of the things I do. Anyway, we are totally out of time. So thank you very much to the folks here. And thank you for answering, asking your questions.