 Let's get our panelists onto the stage. We have Tao Tran, who is the partner development manager. Dion Alma, engineering director. Yeah, come on. Yeah, go and take a seat. Yeah, so Dion Alma, engineering director. We've got Parisa Tabriz, who is down as browser boss in her work bio, so I'm going to go with that. Darren Fisher, VP of engineering, who you met earlier. Greg Simon, engineering director. Alex Komorowski, product manager. Dmitri Glaskov, engineering lead. And Grace Klobber, principal engineer. So let's see what question. I haven't really looked at these yet, so I hope they're good. We haven't either. Right, so question one, how many HTML tags are in the HTML spec? No, this is the wrong question list once in a while. You can figure this out. Too many. Maybe. Probably. OK, as you say, we have some microphones set up. We've got one here, and we've got one over here. If you want to ask a question live for our panelists here, that is something you can do. I mean, we've got someone being very brave, so I'm not going to ignore that. Should we take a question from the audience straight away? This is going to be very target. Can we get that microphone on so we can hear the question? Give us a question. There you go. And this is going to be a very specific one for such a big panel, but it hits close to home. It has to do with messaging across Google as a whole, in particular, how it affects Chrome. Hangouts, I use it personally. I use it in business. And the app versus extensions has been shifting and fluxing. And recently, the extension has broken entirely. We were pulling it off of GitHub because of a feature that was pulled out of Chrome, the docking feature. It seems like a decision that had to have come from a lot of different places that would have affected a lot of users and doesn't seem like it needed to happen as a breaking change. And I'm wondering if you can tell me anything about the process and how something like that comes to be on the Chrome ecosystem. So I mean, there's no one here on the panel who works specifically on Hangouts, but does anyone want to take a stab at that? We can talk about the API in question a bit. Anyone else, feel free to jump in too. But in this particular case, there was an API developed specifically for Hangouts. And oftentimes, when you build an API like that that's specifically only for a one-first-party application, it's a lot harder to build an API that's going to stand the test of time and really hold up and, in fact, be implemented well on all platforms. And in this particular case, we were left with the question of, do we try to really make this thing work well, even though it was really only built for a specific application? Or do we move beyond it? And the decision was to move beyond it because it wasn't something we felt like we could actually build in a solid fashion. So I want to lead on from that question a little bit more. So the things we promote here, things like being progressive, accessibility, working in all browsers, that is something that we don't see happening across the websites that Google actually produces. Is there something that we can do there? Are there other efforts there? Is that something we can change? Dimitri, do you want to say this one is from a Polymer standpoint? Is that something that we can do there? I would love to see that changed. I think Google does need to play a larger role in the Progressive Web Apps ecosystem, and it does need to kind of get on the strain. The strain is moving. Tau was telling us all about it. I'm doing all I can to make that happen. And Yal can help me with that, too. So that's also a call for help. So if anyone has a, oh god, we'll do the live ones, because we don't have many of these. This question is about promises. I know you have been very happy about promises, but personally, I find it horrible. In the next few sentences, are you going to say the word observables? Just a prediction. Actually, I think it's kind of stuck between two different promises, one being trying to become simpler, like not having nested callbacks, and the other one trying to have parallel execution, like promise all, and ended up being neither. It's kind of really, really complex this given point in them. Why is it these two different objectives taken in one single thing and complicated? I mean, is it my personal experience? I don't know, but I think it has two objectives, and it has not met both. Well, I mean, have you used async awaits, where you feel like you're writing a synchronous function, but you're using promises? Have you found that's helped the problem at all? You're saying from nested callbacks because you have, then it makes it easier. It doesn't necessarily, right? I think the problem seems to be that if you really try and build that, you're having a sequential execution. But you really don't have the if then kind of structure that you would normally do in the sequential execution. And also, most of the time, when you're having multiple execution, you suggest doing promise all, like building that structure. And anyway, you have lost the whole structure anyway. You have to rethink the whole thing, right? I think so. Tomorrow, we have Seth Thompson speaking from V8. But we also have Alex Russell, who's on TC39. I think speaking to him about that would probably be better than anyone here, if anyone's got anything to say about that. Yeah, Alex Russell, who spoke earlier, he's around this evening. He's a good one to talk to about that. I think, personally, as a developer, if I don't find it useful, it's easy. I think that is what you should look at it as an end result. Maybe it's still easier for you guys, because you're designing the system. But that's the thing. It's a really great feedback. So one of the questions I have here, which I think has popped up on every time we've done this panel thing, is that are there plans or discussions taking place around making progressive web apps discoverable in the Play Store alongside native apps? And it's interesting that that gets a round of applause, because I always think, like, if only there was some kind of discovery platform on the web for things, if only one company would step forward and make such a thing. But people like their Play Stores. By the way, there was not enough clapping, I think. There was a round of applause at that point. Don't pity me. But in all seriousness, I think, to some extent, is you can look at AppStores, to some extent, as almost a failure that the web already had that piece. AppStores were necessary because there was no other way to get these things. And yes, it has become something on mobile that I think some users expected to be there. But what users also expect is that when you tap a link into anything, it will load up that experience. And so I think it is an interesting other source. I'd like to see how, as we evolve these things, what we can do in that space. But ultimately, I think it kind of underplays the strength of URLs on the web that are like it's super power. At the same time, I could totally see the point that if you are in an app ecosystem today, it is important for you to quack like a duck, right? You need to behave like other players in that app ecosystem. So I can totally see it. I think especially as with the improved Add to Home screen that we're talking, the day I was talking about earlier today, I think as these things become more and more, so they fit in more and more like apps, I think users might bring over more and more of those conceptions. Yeah, and I was talking to someone who had like a games portal that that was their app, so to speak, and then they wanted to mint other apps. So you're in their thing, and you want to grab an app. Well, wouldn't it be nice to have the flexibility for use cases like that that makes sense to be able to do that, to have a meta app that can mint other apps. And they're like, when we have these nice things with being able to put paths and scopes and URLs and sub-domains, so we could actually look at being able to deliver those types of things. Like a PWA that delivers a set of other PWAs, and then you can go to them, and then you can add those to your home screen. That sounds like a pretty good idea. Maybe a search book then. Get Yahoo to build one, yeah. Tau, do you hear this a lot from partners wanting this feature, and what do you think makes people really want to be in the store? I think it's more about just discovery overall, right? So why not have both platforms be at your disposal, I mean at your disposal in terms of discovery, right? So I don't think, I think for most people, they understand that the web is great and has the superpower of reach, but at the same time, having another place to have your Progressive Web App be available is just additive in terms of discovery. And especially if people are in a mindset that the first thing they do is click on the Play Store icon or the app store in order to discover content, right? It's just about giving people as many opportunities to actually find your stuff. And so on mobile device, it's the Play Store or the App Store. I think to some extent, too, like what we shipped for the add to home screen first, that wasn't the final thing. We've been evolving that as kind of been a journey. And I think we aren't done yet, I guess. We'll take another question from the audience. Friendly face, hello? Yeah. Seeing Jake, should I talk about streams? Oh, sure. My question is a two-part or one. I've been seeing throughout the day that Google is not just building for a single browser but building for the web. What's stopping it from influencing Chrome and iOS to have service worker or Safari to have service worker? And the second part is extending the add to home screen part. Would it be possible to have a direct link saying add to home screen when we search for, say, some web apps? And we know that we have a manifest file already. So it would be nicer to say add to home screen directly from the link. Is it technically challenging and ways that are not happening? OK, so the first part of that is, what can we do about Chrome and iOS? What more can we do there? Grace, do you want to take this one? I think for the iOS is for the service worker, we're in. Yeah, so. Yeah, I think it's like, we have to be using the WK WebView, right? So we don't really have a lot of choices. And what we can do is try to influence Apple to put the service worker into the WK WebView. So which means all the apps, like a browser-based app on iOS can enjoy it. And part of things, I think, for us to demonstrate how it works well in Android, and then we need you guys to building the app using the service worker. And the user can see the difference, benefit, and then hope that can influence Apple to changing, adding the service worker into the WK. Yeah, you go make your web experiences much, much faster on Android because you're using the service worker. And so if you're an iPhone user, the web is slow. And if you're an Android user, the web is fast. Yeah, and there's actually Apple representatives here. It's been really great for them to show up at the event, as well as Mozilla and Opera and all these other folks. So I feel like, I don't know if we have a Polymon for them so you can't catch them. If you can find them, like, talk about what you want from Safari. Yeah, this actually came up last year as Chrome Dev Summit on the talk about benchmarks. And really, that's the ultimate benchmark, right? It is like, well, my website runs much faster for users on this browser versus another. That beats any synthetic benchmark out there. I'm going to do one more question from here before coming back to people on microphones. How might users like? You had a problem, too. Oh, yeah, you did ask. You did ask two parts. Yeah. It was about at home screen from the search base directly, because we know that these apps would have manifest JSON in them. Yes. That's a great idea. Yeah, things like for the search result page, right? So yeah, we actually are definitely looking into that with the search team. Hoping to see it soon. Thank you. Thank you. So how might users' expectations of the security model change when a web app is launched from the home screen? Parisa, do you want to take this one? So it feels like a native app. So should it be able to do all of the stuff a native app can do? Feels like a native app. I worry about this, actually. There is a different security model for native applications, or whether it's on a phone or any computer, and the web. And there's great, I think that we have an opportunity to merge that experience and actually make it more immersive between native applications and websites, especially on the phone. But most users don't understand the security model differences. You shouldn't need to. Most developers don't necessarily need to. And now we have kind of native apps asking for permissions and websites asking for permissions. And users don't necessarily know which is which, especially as we kind of evolve the UI between these two things. Was the question specifically asking what? Yeah, is there any things we would grant if the app was added to the home screen that we wouldn't if it was a website? Is there anything that we would infer? Well, one thing we do is full screen. So we will hide the army box. That is already happening today, that you do get durable storage for a smartphone, things like this. So there is a lot of things that are already happening that at the home screen is such a strong signal from the user that they want to engage with the site that we sort of do have some affordances. But there is, like you pointed out, a really interesting line to walk. Yeah, and I think I don't think of it as like this is less secure. But I mean, you're getting more capabilities. And with those capabilities come risk of abuse. I think I mentioned earlier today that we were looking at auto-granting the notification permission when the user goes to the add to home screen flow. And part of that, too, is as these with the improved add to home screen, it feels much more like an app in many other ways. And so on Android, for example, you native apps get that permission to push notifications by default. Yeah, and I think this, I don't think you always want to ask. I think there's a tendency to say, well, we should always ask for permissions. But people get desensitized to constantly being asked to grant permissions. And then you've lost any security benefit. But that question was going to be asked. So I think there's a lot of work we're doing into finding out the balance for any capability. And the more powerful it is, I think the more thought we put into where that balance is. I think there's a non-security aspect, too, of just like, when you tap on this, what should show up? Should it feel like a web page? Should it feel like an app? And someone actually in the audience, or was definitely earlier in the audience, showed me they'd taken a native app, an Android app, and they'd put it to a PWA. And they were going through how it was basically perfect fidelity, other than the fact that they couldn't affect the screen brightness for this one scanner piece. And as I was sitting there, I remember a couple of years ago, we'd be going, oh, the web can't do this. It can't do this. Until I'd be talking about the screen brightness, there's like the one thing left that it can't do. It was kind of like, pinch me, pinch me, you know? And so thank you guys so much for building these great experiences that they actually really do feel like. When my kid goes up and taps on this icon, he really doesn't know what technology, and definitely shouldn't care what's going on. I mean, a lot of people don't know. And I think that's awesome, right? You just want to enjoy. I mean, yeah, you shouldn't need to care. And I think, well, I think what you said before about people not understanding the security model, I think that's true. One of the things that sort of terrifies me about native apps is the power they have just over making web requests. I mean, I think as developers, we complain about cause quite a lot. It's a bit of a pain. But it also terrifies me that native apps, like if you've got anything in your house or in your company that you kind of think, well, I don't need to put this behind a password because it's internal only. Any native apps on people's phones on the same network are just able to read and write from that. Yes. The web's security model is somewhat paranoid almost. But that paranoia is a strong word, but is what allows us to have that really low friction. It's no accident that when you tap a link, it goes right to it, even if it's a different domain. That's part of the 25 years of the security model we've been developing and maintaining and strengthening. We start to feel like security model is a trigger word for this panel, because we've been discussing this question for a little while. Let's take a couple more questions from the audience. So you guys touched on it a little bit already. But it seems like you guys are kind of encouraging developers to go more towards, obviously, PWAs versus something like Chrome package apps, which is what my company has been developing for several years now. Kind of jumped on it right when you introduced that. So the question was, I see that there's like this migration strategy. And not all the APIs that we need are there yet. And so I was actually talking to Darren. It sounds like there's definitely hope for that. But there's still something in the education area, which is that these are usually Chromebooks or some kind of device that is managed. So what is the strategy for, let's say, a school district to be able to push these applications to a set of devices that are strictly managed? Where are we going with Chrome apps, then? Who wants to take that one? So I think as we look through this, like this was not an easy decision, obviously. And ultimately, we care a lot about the open web and what we call the linkable web, the ability for people to be exposed to lots of different diverse experiences relatively easily. I think we definitely, there's a number of gaps between what was possible in Chrome apps. It was a quite different security model in progressive web apps. For that particular case, I mean, I can imagine how that would work, about how we could push an icon. And then maybe that icon is pushed. We fetch and boot up the service worker in an off-screen tab to give it a chance to sort of fetch the things it needs. We really want to hear feedback from people like you about the gaps like that that are in place that we can work to address them and make sure that we offer the best solutions we can for that. For what it's worth, it does not seem like anything but a technical problem that we probably should tackle. This problem is probably also relevant in many other applications. For example, for next billion users where you might have offline a lot and you actually might have to resort to some peer-to-peer swapping of progressive web applications, I can imagine a world like this. And how is that different from what you described, except yours is a slightly different application of the same type of technology? So I totally see this as a possible thing. At the end of the day, progressive web apps work really great on desktop as well. And there's really nothing stopping us from fleshing out those details so that the enterprise management features of Chrome OS and so on work well for pushing PWAs. Is there, I just want one more thing tonight. Where's, how can we give feedback to Chrome team for things like this? Because for a lot of shopping sites and stuff like that, it seems like there's a lot of people who are in that space that you can feed off of. But for education, it's a very different market and it's very narrow. So we love getting feedback from all developers. Almost everything we do is fully an open source and there's a reason for that. We love when people come on the various mailing lists and give us feedback. It's very specifically on this issue when we announced this change on the Chromium blog, there's a link to either a feedback form or a mailing list. And we really encourage you to engage there because this is a great example of a thing that we should just do, right? So, great. Thank you. Good evening. As the modern web applications goal is to make the user experience better and make the web applications native, right? So in that case, if the user uses the web application for the most of the time, the memory consumption of the web application is also matters. So I'm glad that we have debugging tools to identify where the memory leakages are in Chrome. But what are the suggestions do you give to the developers to prevent the memory leakages or what are the areas that developers should concentrate to prevent the memory consumption? That's one of the things that I found the most difficult thing to debug on web pages despite the DevTools we've got. Who's gonna fix it? We are gonna fix it. Yeah, this is actually a huge pain point for us. We've invested a bunch of effort into trying to understand memory usage ourselves inside of Chrome this year. And I think, I don't know if you are feeling it, but we definitely know our graphs are all going down in terms of memory consumption. And I think the actual developer experience is next. It's very hard to do your right. Greg is actually one of the pioneers of this back in the day where he went and engaged with the Gmail team and built them a little bot that runs Gmail for what, 72 hours? We ran Gmail for many, many days. Right, and caught their leaks. I expect it to be flat. Right, and it's hard. I agree it's hard. And we are sorry that this is not working today, but we will get there. And this is one of our focus areas. So a lot of effort being put onto the low end devices too. Yeah, and also I think in the past year, we did a lot of work in the DevTools. And then we actually can capture some of the memory you can like using the DevTools today when run your website and then try to capture the memory snapshot and then to see where the memory, what part, at least like relative to Chrome, may not be relative to exactly what part of your code. But you can see where the memory goes, yeah. You should also, I mean also just like any good programmer, pay attention to how many references that you're keeping. It's easy to understand in the code that you write yourself, but if you bring in a bunch of frameworks that you don't understand how they work, you can, all it takes is one reference, right, to pull the whole world with you or you know, keep it around and it's hard. Well, the way this can definitely get better. Sorry, where we tackle a lot of this on the server side is you run a pool of like five workers and once memory gets so high on one of them, you just kill it and restart it. And I'm kind of pushing my own agenda a bit here, but like, can we have, I really want us to look at navigation transitions again. And I think we're starting to do that because in something like Gmail, if you're clicking on emails, you know, we could do full page reloads and if we could do that fast and we could do that in a way that, you know, you can still have a fancy transition, then you've got that sort of tear down. Because you're already killing it constantly. Yeah, exactly. Can we get agreement on that now? This next question, this is a really, this is a good one. It's quite spiky. I've got some unease about Polymer. It seems weird to have browser folks advocating a specific framework. Is it, you know, is the idea that it should just shim new APIs and sort of eventually become redundant or does it make sense for a browser to push a framework? I don't think a Polymer is a framework. I think of it more as like a mix-in, right? Because it uses the platform. I mean, that's the trendy thing to do now is to claim your framework is not a framework. So I'm glad we're on board with that. In all seriousness, I think tomorrow, Adi's money, I think is going to give a talk about how to build progressive web apps and many of the popular frameworks. And ultimately, like there's a million different ways to build progressive web apps well. We're excited to see a lot of stuff that React community is doing and the Ember community and other communities. The way I think of Polymer, actually, is there's this gulf between browser vendors and web developers, browser engineers and web developers. And it's kind of weird, actually. When I first joined the team, it was kind of surprising to me because I came- It's two plus plus coders. Yes, it's very different, right? And so actually one of the reasons that we think the Polymer team is part of Chrome is it helps us test out all these new features and, you know, HTTP to push and web components and a number of these new features and give some feeling of what it would look like to do something that's as idiomatically as close to the platform as possible. And so to me, it almost feels a little bit like a... Well, it's just like a way for us to explore what you could do if you try to keep this thermo layer as possible. But of course, frameworks add a ton of value, right? I mean, frameworks are in user land, they're able to explore concepts way, way, way faster than we can in browsers and in standards. And they absolutely have an important place in this whole ecosystem, I think. So I'm going to take a couple of questions from the audience right after this one, because this one's been... The font size has been made very big on this one, so I think maybe a lot of people have been asking it. A lot of people use Chrome on desktop. Oh, we released Chrome on desktop as well. What plans are there for installing PWAs on desktop Chrome, like, add to the home screen? I mean, it already works, right? You can go under... Oh, that was easy. It's done, yeah, it's something we want to do. In all seriousness, this is actually... We get this request a lot. It's on mobile, it's actually easier to imagine exactly what it operates like, because on mobile, you tap an icon on the home screen and then it goes full screen. That's just how it works. Like, that's what users expect. And there's not really that many sort of weird edge cases. On desktop, we have multiple operating systems. We have task bars and desktop launchers. We have full screen things. We have tabs within existing windows. Does this thing pretend to be a totally separate application or within Chrome? There's a lot of other interesting questions to reason through, and we definitely want to do it. But it's a lot more stuff, interesting questions. I'm really excited that Microsoft, a few months ago, announced in a blog post that they're going to be exploring progressive web apps on desktop. I think it's really awesome. It's going to be really cool to see. But how far can we get down, like, a letter on, like, how far can we get down that route? Launching without tabs, launching without Chrome? For example, today you can go and you can say, like, if you're on a Chromebook, you can say, add to shelf. And your website now is on the shelf, and it launches in its own window. On windows, you can say, add to desktop, and so on. This doesn't work quite as well on OS 10. I mean, that was even true when we were doing Chrome package apps, because the OS doesn't quite give us the flexibility to present these experiences as distinct from the browser. But on windows, it works really well, and so too on Chromebooks. And I think the other thing is I wrote an ode to the desktop, because I think we talk about mobile all the time, and that's great. But one of the great things about the web is that it can stretch and do this responsive design and give us access to all of these different things. And I've seen certain productivity-type companies that go all in on mobile, and then they leave behind their desktop applications. This is what I live in all day. I use this for work. Like, it may make sense to actually fix up the desktop side. So I'm excited to see as we kind of grow out, I think, the PWA story actually works really well, much beyond mobile. It's definitely what we want to do. Let's take some questions from the audience. Let's go over there. OK. We spoke a minute ago about the gap between what was available in Chrome package steps, and you specifically addressed sort of the distribution model. But there was also other APIs, of course. And some of them were very important in the educational space, so my companies, as well as others, have built things for education using some of those APIs. Those APIs are not likely to have web standards implemented before the end of life of the Chrome Web Store. What do you guys think about a compromise of getting some of those APIs into just standard Chrome extensions that we can message, as opposed to they were only ever in Chrome package steps, Chrome Serial, ChromeNet, things like that? So there are a lot of things that are difficult to bring to the web platform, given its paradigm security model. But that seems like an approach that could work for some of those kinds of APIs. Again, it's really we love this feedback and to get thoughts on the APIs and use cases are really important to you. Yeah, I would just plus one that. And I work with the extensions team who build the Chrome extensions platform, and they expect that there's probably going to be increasing needs for extension APIs to solve some of these things. I mean, just the existing ones removed over with that same security model would be awesome. Solves it problems. The same security model. You do the same thing. Well, what would be helpful is it's a small team. So what would be helpful is to know what the most important things are. And that's I can't remember who would give the talk on it. But yeah, via feedback is so we can know how to prioritize things. OK. Thank you. We have some of the product managers working on that stuff here today and walking around. Yeah, I mean, I picked some of them already, but I'm going to bring it up. Yeah, I mean, we would like to ship those APIs on the other way as fast as we can, right? But we have to be very careful like we can. It's very difficult to unship things from browsers. Sure. You guys just realize that that gap of functionality means that there's going to be no functionality until the, when the Chrome Web Store goes away and the APIs don't show up as standard APIs, right? And we're aware that the timescales are different. That's one of the reasons we want to hear this feedback so we can see how much things prioritize that transition. Thank you. Second, I've already asked a question. My question is about HTML imports. They were mentioned a couple of times today. And maybe it's just me, but I sense less optimism than I have from you in the past. Do you still think, are you still hopeful that HTML imports will be supported by the browsers the way they are today? Dimitri, we've locked horns. Me and you have locked horns over HTML imports and what they should do, so you can take this one. As the proud father of HTML imports. Yeah. That's your map, Brad. No, I think it's still a pretty cool primitive. And it did advance a field of how do you do modularity on the web pretty far. I do believe that there is interest among browsers to implement something like imports. And the latest proposal that I have so far is called HTML modules, which is effectively taking the semantics of ES6 modules and transplanting them to something that looks like HTML imports. And folks have been receptive so far. But right now, our biggest blocker is actually shipping and getting ES modules out in the wild and trying to understand how this will actually work. One of the saddest things ever, I think, is that this is the first time we're actually going to be. This week, you're going to say something that's the saddest week ever. I'm looking forward to this. Let me roll this back. Rebase. One of the saddest things in the last 30 minutes is that we actually are not sure what the performance characteristics of ES6 modules will be once they're available because they are a new, brand new primitive. And even though ES6 modules are used pretty widely in the developers' build systems and environments, nobody actually has done a good performance characteristic analysis of ES6 modules. And until we actually have a running code in the browser, we won't know. So that's step one. And once we have something good and we'll understand what is the next steps, we will start thinking about the HTML modules. And the precise timing of all the things that are loading across the wire when they're ready and when other things that are blocking on them. Some of the things that's been, when I joined the team, just crazy complicated. A lot of this was intuition in the beginning. And I think right now we're really like, if you look at what Sam was talking about, Alex was talking about, we actually understand the space a lot better. So in a way, my answer today would be no, HTML imports will not survive the way they are. But yes, there will be something like it that is better. Thanks. Who's next? So a few years ago at Google Iow, it was showed off that Chrome tabs in the app switcher are treated like every other app. Now that's no longer the case, what happened to that is that ever going to come back? Or is that permanently gone? Or what is going to be replaced? Great, so. Yeah. So we tried that model as a back then. It's in the Android time is when they introduced called a document mode, it led the app to go into the system. And we adopted that. We are first adopter from the app perspective. But when we start to get it to the wild and then we realize it's not a lot of other apps adopting that model. And for Android, also some of major devices, like Samsung devices, they don't have the quick affordance. The reasons button is not available there. So that make a lot of user cannot find in their tabs. So based on that feedback, it is a decision because we actually run this in the wild for over a year. But we're collecting a lot of feedback coming back. We change back, but we are going to re-evaluate. If you're looking at today's Chrome, I think we actually run the new. It's like if a tab is opened by another app, we actually will put in a similar as in the Android reasons. So we'll try to introduce this. If your user using Chrome as a Chrome browser, and the other tab will stay in Chrome. But if they're using a haven't spoke model, that's what we call it. They're using, say, Twitter, and click the link, just to view the content. And then that will show up as an individual document. And then when they head it back, and then that will just go disappear. I think ultimate is about user expectations. And with that model, every single site you visited, even if it was accidental or that celebrity gossip site that you aren't very proud of, that one time is kind of there in the same mix. I'm proud of it, man. I'm proud. And I think the model that we're at now is, in many cases, users are just tapping around to a couple places they don't intend to come back to. And that still feels like a website, to some extent. But now as you grow a stronger and stronger connection to this, when you add to the home screen, that's more of a strong signal of like, no, please promote this to be like a thing that is treated like an app. So I think, to some extent, this is like us exploring this space, figuring out what works for users, what works for developers, trying to figure out the right mix for all of that. There was another factor if I could pile on. We introduced a feature called Chrome Custom Tabs a little while ago, which has seen really rapid adoption. And prior to that, some folks were flirting with using WebView for tracking content in their experience. What we found with Chrome Custom Tabs is that people really like to, they didn't want to intent out of their app into the browser because then users sort of got lost and didn't know how to get back to that app. But with Chrome Custom Tabs, they had that X in the top left corner. It's really easy to pop back to the app you're at. So it works really well for this hub and spoke style of browsing. But once you start to have a lot of folks going in that direction and adopting Chrome Custom Tabs, and I don't know about you, but I've seen that more and more, no longer do you have that experience where you sort of the segregation between the browsing that happens outside of Chrome and the browsing that happens inside of Chrome. And so then we sort of led us back to this model of, well, if I launch Chrome, I want to be able to find all my tabs. I want to be able to find the activities and the tasks that I was doing there. And then we thought, well, maybe we can even evolve the task management within Chrome around that notion. Because it's actually really hard. We can't evolve the task management of the OS. In many ways, we're just saddled with whatever old versions of Android implemented for that. And as Grace said, some old hardware didn't even provide a convenient approach. Anyways, look for us to do some explorations in the task management space. I'm going to be able to use voice. Just be like, show me that celebrity side that you poked on on my computer. Just have it come back. You know how they come back. This is a genuinely sorry. When I started Google, I just realized that every story I tell involves a bathroom and a toilet. But this one does as well. I started and went to the urinal. And I saw that the person standing next to me was wearing Google Glass. And I just went, OK, Glass, take a photo. And I just went, dude. Works. This is a question from the audience. My question is about page performance. Earlier, we talked about PWA and mobile performance and the need for having less JavaScript and less parsing. A lot of websites have this one megabyte of DOM size. But the rest of the megabyte comes from the advertisements. So the biggest challenge that we face on many websites is page performance. Yeah, I can go PWA. I can go offline. But also, we have users 2G, 3G. What are your guidelines? And how can we bring it out of the clear guidelines from the FP that allow us to say, we don't really recommend you to put heavy ads. Or you have the AMP ad. That's excellent. You only allow certain types of ads to work. So AMP pages are faster. So what are your guidelines to make sure the ads somehow don't affect the main page flow and faster. And it doesn't impact the user. So yeah. This is a very complex area. There's a lot of moving parts. And we're focusing on digging into it on a number of levels. So in particular, we're looking at ways to isolate third-party iframe performance from the rest of the page and making sure that they reduce the amount they can jank the page. We've also implemented a few APIs that design a few new web standards, like Intersection Observer, that makes some of the things that many of these ads do, like viewability calculations that many other sites do, much, much, much more efficient. But depending on the ads to go and do the right thing. The ad networks. The ad networks. The ad networks. There's usually a countably few. In the case of the Intersection Observer, a lot of them are using Flash on desktop to measure position. And so for example, we've changed our plug-in power saver heuristics to also target some of those. Now that you can do Intersection Observer just very, very efficiently, we're actually changing the heuristics for plug-in power saver to disallow small Flash plug-ins, which is one of the things you see on desktop that needs some performance problems. The other thing we're looking at, in many ways, we're looking at making some targeted interventions. Roll back the clock. Remember pop-up blocking? Yes. This was browsers intervening to try to help, right? Move the ecosystem to a better model. You could argue whether that worked. But the point is that things like what we're talking about here are ways where we get involved, right? And another example that we've been talking about is in the standards group, Susan, is around blocking synchronous script that's injected through DocumentRite. A lot of times, these analytics packages or ads will go in DocumentRite one script and then another one and another when you get this awful soft-tooth pattern. So we're exploring ways to kind of like say, hey, that's not OK. You don't need to do it that way. How about we just start breaking that? Is that one in particular we're shipping? I think, right as we assume on 2G connections, we'll basically kind of ignore, won't wait for that Document.written script. And actually, if you as a developer open-dev tools on a page that does that behavior, even if you're on 2G, we'll warn you, by the way, this behavior we might intervene in certain character conditions to change this behavior. There's a lot of other work happening in this space. This is obviously a really complex situation because just like Rick and Robert came on stage and said, we want this to be predictable. And we're with our interventions coming in and saying, hey, we're going to break your randomly. It's going to be great. Only if you do the bad things. But if you don't know what the bad things are, it does look random. So it's a hard problem, but we are really interested in solving it. We hear this loud and clear. This is a really hard problem. There's an exploration of GitHub as well, like looking at a spec where you can have an attribute on an iframe to kind of set some limits on it. It's very early days and sort of how to attribute usage to a particular iframe or to a particular origin is not easy, but we are looking at it because you're right. It's so important. Yeah, so you can imagine saying this iframe can load no more than three megabytes or whatever. Exactly. So a page can go, one day it can be loading in five seconds, the next day is 15 seconds. So there's no telling and there's no way to monitor what comes in and what goes on. Absolutely. So thank you. Well, I'm going to take the last question from the audience. Go for it. I'm just kind of curious for some inside perspective on kind of the seeming contrast between Android Instant Apps and kind of that side of the house versus the Chrome team. I realize that I'm asking half the group here. But I am curious kind of what your perception is of kind of the internal dynamics there. Because as you said, I think that it's no surprise that the Android team is investing in Instant Apps, right? We talked a lot about low friction and how that's so valuable or friction and how that's such a problem. And so they're on a path to try to figure out how to bring instant loading native apps to become a reality. There's a lot of challenges there. Security model, somebody said, yes. Size. The reality is that we're all sort of thinking about the same sort of ideal model, one where you can happen on an experience very easily, discover an experience, and then as a user, choose to retain that experience and reengage with it easily. And that active retaining grants additional powers and things like in the case of PWAs. Today it's full screen. Tomorrow maybe it's notifications and perhaps other things. But the point is, as a user, you discover content within the context of the browser or in the case of Instant Apps. And similarly within the browser, because you're following URLs. And then you might, as a user, retain it. And that makes that transition to being a thing that you're keeping on your device. So in a sense, we're all kind of converging on a similar model for computing. But there are some fundamental differences between web and Android. I was a betting woman. I would bet on PWA. Well, so that takes us quite nicely to a good last question. And that's, what's the best way to convince my management to jump on PWAs, because it's management that has the money? It just makes sense. It just makes sense. I think cost wise, if you think about just iteration and updating, I imagine that developers can capture the cost of being able to update and evolve whatever product or service they have and how challenging that is on native apps. Probably one of the best reason examples of that was the big quiz, right? No one had to reinstall an app when you guys ran backstage, right? Just sort of like, if I would have had the same problems that we had today, I just want to stress that. Play with me, Aaron. In seriousness, we have a number of case days, number of them are new today, the towel covered in her talk. We're going to have a blog post a couple of days. It summarizes it as well. A lot of these things, like that stat about the user acquisition cost, for example, these are very powerful to people who are making the business decisions in this. The other thing to remember is I'm starting to see progressive web apps as a term. It's coming up in press articles. It's coming up at conferences, at marketing conferences, at other places. Imagine at some point, if you already know these technologies, have built a prototype, know what it would look like for your company. Someone from business in your company is going to come to you and say, what's this progressive web app thing? And say, oh, well, actually, here's an example of how our thing would look like. Yeah, I mean, I think the best thing you can do is probably. I mean, today, people aren't experiencing progressive web apps on a daily basis yet. And I think, and sometimes it's really hard to imagine your site inside or what your site should look and feel like and how it could be instantly better. I mean, West Elm is such a great example. I mean, they built a demo first, got signed off, and then now they're going to do, they did an early beta, going to move public beta and then move their site over. Because once you see something so amazing, you don't want to go back. I mean, I think that's the, and so I think you sometimes you just need that visceral demo. You don't have to take your entire site, take a couple of APIs, just put it together and just make it beautiful and immersive and engaging. And I think it's hard to say no once people all see that on their device. And so if you can take somebody 20% and build a demo or a prototype, I think that's the way to go. Make it real, make it very concrete. Because abstractly, people are like, home screen icons and offline. But when they see it for real, it feels very different. I think that's a good note to end on. Can we have a huge round of applause for the panel? Thank you.