 All right. Welcome, everyone, to today's Google Webmaster Central Office Hours Hangouts. Today, we have a special topic, AMP and PWA, and a AMP team member, Paul, who's here to tell us a bit more about how this works together, short presentation to start off with, and then time for questions and answers, whatever comes up. Take it away, Paul. All right, thank you. I'm just going to share my screen, and then we're ready to go. Does that look good? Anyone can see my slides? I can't see your slides. Just the Hangouts. Yeah, just the Hangouts. My bar, it is written while you're sharing your screen. So probably it's working, but not with slides. But you see your screen. OK, one second. Let me try another thing. How about now? Now we see a black screen. A black screen. Black screen? It works now. Yeah, but that's the, OK, let's actually try to do it, and if we can't get it to work. Sorry about that. We'll just let this work instead. Just a second. No problem. OK, this is the best I can do. But this seems fine, right? Yeah, it looks good. OK, all right. Now I have no way to navigate. That's so amazing. OK, one second. Maybe I have to do it this way. OK, so let's talk about progressive web apps. And that's not a typo. That's the combination of progressive web apps and AMP. So let's start it. Yes, I'm Paul. I work on the web developer advocacy team. But I also work full-time on AMP, trying to make the web much faster than before and much more user-friendly. Now, you may have heard about progressive web apps. And the benefits of progressive web apps bring you. They're generally fast, pretty reliable, and engaging. So they come with features like a service worker. And the service worker is a technology that allows you to pre-warm on cache and make available offline any kind of assets. So it's a client-side proxy that you can use to actually cache away everything and build an app shell model for your page, for your site, just like a native app. What this means, though, is that it's sort of an install process, right? What this means, though, is on the first site load, your site will still load normally. So it will still be relatively slow. And then after your first site load, the service worker activates. And on the second load, you will then get a fast result. Because at the second load, you will have cached away all of those resources. But unfortunately, it's that first hop that really counts. And it turns out that 53% of all people abandon a website that takes more than three seconds to load. And in another kind of statistic to rephrase this, there's a 7% reduction in conversions for every one second delay and load in time. So if you build an e-commerce site, that's very detrimental. Now, what can happen in three seconds? So to give you an idea, in three seconds, your phone has to do all sorts of things to actually load the page in the first place. For instance, the connection to the cell tower might not be established. That's the RSC negotiation. It can take on a 3G connection. It can take up to two seconds or something. And so then you have a DNS lookup, a TCP uncheck, and so on, until you actually get to the point where any kind of data arrives at your phone. And so that's the situation that means that you end up with just a few very small window of opportunity to actually do any work that you need to do to build your site, to set up your site. And in the real performance model that the Chrome team came up a year ago or so too, we actually argued for a one second load time. The reason for that is that one second, the sort of the threshold that Jacob Nielsen and a book on usability defines as context switch threshold. So if something looks less than one second, you're not making a mental context switch. And it actually feels fast. Now, this all sounds pretty drastic. And it turns out that it is, because the current state of the web looks fairly different. If you look at the current situation, you get a much worse picture painted. In fact, the average mobile page load time is 19 seconds. And 77% of those mobile sites take more than 10 seconds to load. Now, 10 seconds is not an arbitrary number. It turns out that at 10 seconds, the drop off rate is at 100%. So imagine that 100%. That means that, yes, in 77% of all cases for all mobile sites, people will just never, ever see the site and abandon the site completely. And that's essentially the problem that we have on the mobile web today. So yes, pretty unfortunate. This is my team member, Sam, who is not very happy about that. So we had this issue on the mobile web with slow loading pages, non-responsive content, and really content shifting around, just not being a great user experience and at loading where it shouldn't, shifting your paragraph that you just started reading. Just a generic user unfriendly web. And what we did in order to battle that is come up with AMP. And just a quick recap. So with AMP, you're building a kind of special HTML flavor called mHTML, which is really just HTML, but has a couple of new web components and also some replacement components. For instance, the image tag is replaced with an AMP image tag. And the reason for that is that AMP prioritizes the load pipeline quite efficiently on its own. So it needs to be able to control every asset on the page. And then you can either build just one AMP page and be happy, or you can build a separate full website to your AMP website and connect those two, which means that on platforms that support AMP, they will show the AMP site. And further on, speed it up with an AMP cache and preloading it, et cetera. And then on the other hand, if a platform does not support AMP, it would show the canonical site, which in your case will be the full site. Worth mentioning that you don't have to build another site. For instance, my own blog, or mproject.org, completely AMP, just one AMP page. So we're just using it like a library. And it works fine for us. So you're not sure? May I ask something about this? Sorry? May I ask something about what you said in the previous slide? Maybe we can leave the Q&A to afterwards. That works? Sure. All right, thank you. So basically, in a nutshell, it allows you to build portable, beautiful, high-performance web pages, again, with a growing library of components. And yes, the AMP cache on top means that your content is accelerated with automatic in-manage optimizations, pre-rendering, and all sorts of other optimizations, like HTTP too. And this pre-rendering is extremely important to AMP. It's that instant feel that you get when clicking on AMP links. So the fact that we can only pre-render the first viewport in AMP is highly important, because AMP knows where each page element is positioned. And no third-party JavaScript is executed at that stage. And this is something that not a lot of people know. There's also one less privacy issue, because the preloaded page won't ever know about the preload. So that's extremely important. So in the end, AMP pages are just HTML and CSS. There's no user-authored JavaScript. Instead, custom elements, sandbox, AMP iFrames can contain everything if you need more than that. And then there's the AMP open-source.js library. That one is highly cacheable, because everyone includes it from the same path. And it defines the behaviors for those custom elements. Manages the rendering and resource loading to optimize performance. So then if PWAs give you that, further more engagement with the service worker, being able to go offline, and then also push notifications, et cetera, web payments coming up. If PWAs give you that, but then AMP gives you the fast loading thing, the question that we get a lot is, well, what should I do? And so of course, if you think about AMP, you have certain constraints that you need to live with. Again, you can't use any of your own user-authored JavaScript. You cannot use a custom service worker, push notifications, web app manifest. If you serve the AMP page from a cache, that means, for instance, if you click on AMP page on google.com, it will be searched from the Google AMP cache. And it could use different caches on different platforms. And in this case, it doesn't run on your own origin, meaning that your own service worker doesn't have an opportunity to run at this point. So AMP gives you instant delivery, optimized discovery, but no user scripts, and mostly for static content. And then Progressive Web App gives you really advanced platform features. It's highly dynamic, so you can build basically everything you want with it. But the first delivery will be slower. And it's not very easily embedded in third-party platforms because the pre-rendering technique is fairly new to AMP. So let's go one step back, though. What is the kind of ideal experience that we want? The ideal experience that we want is, and this is in the case of a sort of fake e-commerce site, you start with a search, and then you end up clicking on the result. It will be instantly loaded because it's AMP. So allowing you to explore the category, you pick your favorite, et cetera. And then if you click on one of those items and go to a checkout, again, instantly you get redirected to the checkout flow. So that, in our opinion, is sort of the ideal user experience that we're aiming for. Now, one way to go about this is just to use AMP as a Progressive Web App. And I want to spend too much time on this, but I mentioned this before, ampproject.org and my own blog and ampbyexample.com are both AMP pages and a Progressive Web App, meaning that this page has a service worker for offline and caching, and it has a web app manifest to install. So what this means is if you start from search and then you click on ampbyexample, it opens a cached version inline, so which means that at this point the service worker is not running yet. But then on the next click on any link on that site, it opens ampbyexample on the origin instead. And at that point, the service worker takes over and you can install the thing to your home screen, send push notifications, et cetera. So you're building one site that is AMP-enabled that is also a PWA. And if we have this technique, we can actually go one step further. And in the service worker now, of course, we have to be able to just return the cached websites, the cached pages. But you can also theoretically insert any additional content to the AMP page. And this is kind of interesting because we can insert additional content that the AMP validator doesn't actually like. So for instance, in this example here, I found this really nice DHML mouse cursor that makes me very nostalgic of the 90s. And this is a script that obviously would never be allowed in AMP. But what I can do is I can insert it dynamically with the service worker. And so if you look at this result, now that the service worker is activated, I have the mouse cursor running on the site. I have a crazy animating background. And it's just my AMP page. And so first of all, please never do this at home. This was just a stupid example. Second, this is kind of an interesting technique because what this means is that on the AMP cached version, you just get a normal AMP website. And the validator still passes because it doesn't have the concept of the service worker. It doesn't know about the service worker. But as soon as you click out from the first page, the service worker takes over. And yeah, it can do everything they want, transform the page into anything you want. So now moving on, we come to AMP 2 Progressive Web App. And now there's basically two patterns that I call AMP up and AMP down. But what this really means is that one is leading from an AMP page to a PWA. And the other one is embedding AMP pages within your PWA. So let's start with the first one. So first flow that we want is you get to an instant inline version by the AMP cache, just like normal. And then some magic happens. And then you end up with the Instant Progressive Web App. So this is what I call AMP up. And in fact, the Washington Post does this today. If you learn an article from the Washington Post, there's a thing called AMP install service worker that runs even on the AMP cached version of the page and can preload and warm up the service worker for your actual origin. So that means every time you now click out from that page or click on a banner that says, try our Progressive Web App, the service worker has already installed, which means that every important asset for your site has already installed. And so that means that the click, the experience, will almost be instant. So as soon as you click on it, you will get redirected to the Progressive Web App in an instant. And it's something that our colleague, Alex Russell, called Start Fast, Stay Fast. So now with this pattern, it means that you can transition from AMP to a PWA very quickly and efficiently. However, now in this structure, you have two different backend structures. So on one side, you have a backend that generates AMP pages. And so they turn AMP HTML. They have to spit out AMP HTML and generate a lot of AMP pages. On the other hand, you have your PWA, which has a different backend. Probably has some JSON-based API. And so the Progressive Web App has to do all its templating itself, et cetera. But if you think about this, AMP pages are not just websites. They're ultra-portable content units. They're data-format, in fact. So if you notice, how about using AMP as a data format and just drive our PWA? We can actually do this. So this means that we have dramatically simplified our backend. So our backend generates AMP pages. And then the Progressive Web App embeds those AMP pages as a data source. So it uses those AMP pages as a data source instead of just using JSON or XML or anything else. And this is what I call AMP down. So embedding AMP within your PWA. So of course, one way to do this would be by using iframes. But iframes are pretty slow and really detrimental to the user experience. The 2016 way of doing this would be ShadowDom. So we took AMP into the shadows. Now, in the past, we had one window, one AMP library instance per window, and then one document. So pretty easy world view for a browser. In this new setup, we have multiple documents, but still one AMP library instance. And so this AMP library instance is compiled just once in the browser for all documents, which means that the individual load for each additional document, each embedded AMP document, is going to be way, way faster than before. And we have built a React-based demo to a, and this is really hard to show in this view. I don't know why this doesn't run. So we have built a React-based demo that will show you this pattern. So step by step, the PWA hijacks navigation clicks. Actually, I think I have a video afterwards. PWA hijacks navigation clicks, and then the XMACP request fetches the requested AMP page, puts that content into a new shadow root, and then calls attachShadowDoc on the actual AMP library, on the AMP instance. And you can check out that code on the AMP React demo, AMP PWA React demo. But even better, we make it very easy to build this pattern because we're adding you some convenience methods. For instance, there's the AMP shadow class that can be used to automatically hide header and footer from an AMP page when it's embedded. Because usually on an AMP page, you would have a header and a footer, and then in embedded format, you don't want to show them. Now, of course, the other way to do this is just to regex away things you don't need or replace them with AMP incompatible stuff in the source code. So remember, you're doing an XMACP request to pull in that AMP page. So you can do any kind of string transformations that you want to that code that comes back. And then finally, there's something I call AMP economic code, up, down, left, right, and so on. So it's basically the end result, the final bit that brings the pattern all together. And what you do, and the problem that we have, remaining, is that if you copy an URL in the Progressive Web App, so you're already in the Progressive Web App, and then you shared a send it to a friend, it means that on your friend's computer or phone, it opens that Progressive Web App without a warm cache, because they didn't come from Bing or from Google, and they don't have a warmed up AMP cache. So they don't come from AMP to Progressive Web App. So they don't have that warming up scenario with AMP install service worker. So how can we solve this problem? But traditionally, we have a subdomain for all of our AMP pages, probably, and then we have another subdomain for the Progressive Web App. But in this new scenario, we just reuse the same URL space. And in fact, then the service worker intercepts the request. And when the service worker takes over, for the same URL, just delivers the PWA instead. So here's an example of how to actually do this. So in the service worker, you have a fetch event. And what's interesting is that the fetch event so handles all incoming and outgoing requests in this client-side proxy called service worker. And it doesn't just handle ongoing requests on the current page, but it also handles navigation. So the actual navigation request meant to fetch the whole site. So if the event request mode is navigate, we just respond with a completely different page. We respond with the PWA, and then immediately start fetching the request URL so that the load will be sped up even more. So in this scenario, you end up with one AMP, one Progressive Web App, and just one request to transition between those. And best of all, it's progressively enhanced. So without service worker and for browser that don't support service worker, you're just going to the AMP page. So you still have a pretty fast experience. And then if the service worker is available or is installed, you get the Progressive Web App on top of the AMP documents. And then we also have something called fallback URL rewriting, which means that if you want to have, so for instance, in Safari, you don't get service worker function 90 yet. What this means that in Safari, with this pattern, you would mostly always see AMP websites, AMP pages. However, we have a thing called fallback URL rewriting that allows you to rewrite URLs on the page to a fallback URL if it detects, if AMP detects that the service worker is not available. So this means that if the service worker is available, if not, it rewrites all URLs on the page to a provided fallback URL that you define. And so you arrive on something like a PWA, not with the service worker, but still with some advanced functionality without service worker, which might be better in your scenario than nothing at all. And so demo time, I'm going to actually show you not this, but another demo, which is, so this is actually, this is the React-based Viewer demo. There's actually a video here that I showed you, yes. So it's very smooth, probably not in this hangout because I'm streaming it. But you can check it out later if you go to the URL that I just provided you. And you can check out the code too. It's pretty straightforward. Comes with a smooth transition, super fast cache loading. But more importantly, I want to show you a live version of this, an actual live demo. And this is bidder.mic.com. So let me switch out the screen share right now. One second. OK, here we go. And now, I hope this actually works. Here we go. Yes. Can you all see that? Does it look fine? Yep, absolutely. OK, thank you. So this is the app that mic.com is built. And right now, you're looking at the progressive web app. But let's actually start at an article. So here's an article. I'm going to shift-reload this article. And that means that the service worker is ignored and that we're starting at an AMP page. So as you can see now, this is the full article. There's everything in there. However, if you look at the source code on the side here, you see that there's an install service worker and other AMP components for our page. So we're looking at an actual AMP page. So this page will be loaded very, very quickly if coming from Google Search. But the crazy thing is that if we go to the application tab here and click on Service Workers, we can see that a service worker has been installed and is activated and running. So now, if we, and they have some very cool integration, we can now obviously click on any link on that page and it will take over from the service worker. But what's even cooler is the integration they've built with the hamburger menu. So as soon as I click this hamburger menu, check out what happens. Here we go. So if you look very closely, you see that the page was actually reloaded. And it was reloaded very, very, very quickly because everything was already preloaded in the service worker. And in this new state, the menu is already open. So it looks like I just opened the menu. But instead, I navigated from AMP to PWA. And so now I'm in the install PWA and I can go back to the other section. It looks really quickly. I can browse those pages. Again, super fast page transitions. And I'm in this full PWA experience. I can enable push notifications if I want to over here. And it's a very slick experience. So this is the whole pattern in action. It looks very simple. And that's because it is very simple to implement. So let me go back to the deck. OK. So the crazy thing about this is that it was built by just three engineers in two weeks. And they really didn't have any previous PWA experience. So it was just very, very easy because they didn't have to do any templating in the PWA. They didn't have to do any kind of their own JSON formulating, et cetera. They could just connect and embed their AMP documents in their page. And it just makes the whole work much less complex. So to wrap up, PUAMP is a really nice pattern. Or if you want to call it long form, progressive web AMP. It's always fast, no matter what. There's great distribution built in through the power of AMP and the platforms that support it. It's progressively enhanced. You just have one backend to rule them all. You get less client complexity because, again, you don't have to focus on templating, et cetera. And it really reduces the overall investment because of that. What's important is that this pattern will not work for everyone. It will work for every site that has lots of static content on individual pages. It will not work for something like Gmail or the next mobile Photoshop, an app that is focused on content creation and doesn't really have a lot of static content pages. It also works really well if you have constrained engineering resources or want to reduce your infrastructure complexity. And if your content monetize, it works fine within the AMP ecosystem, which is something you have to try out for yourself. We've heard a lot of good things from publishers, but you just need to try it out. And here's a couple of links for you that you can follow, bit.mic.com, of course, for trying out the whole pattern in a production app. And then you have to React Sample app. You have developers.google.com. Slash web to learn more about PWAs. And then, of course, AMP project.org to learn more about AMP in general and how to build great AMP pages. And if nothing else, the other URL that I want you to write down and check out later is this one. And it's an article that I released on Smashing Magazine a few days back called Progressive Web Amps. It's essentially what we just talked about with a little bit more detail and in textual form. So you can read through it at your own pace again and really get a feel for the whole pattern. So please note down that URL and check it out later. And with that, I am at the end of the presentation. And now I guess we're opening up for Q&A. Thank you. Thanks a lot, Paul. That was great. Good to see some of those sample URLs as well to let people try things out on their side. We have a bunch of questions or not tons of questions, but a bunch of them that were submitted already. But maybe if there are any of you here who are in this Hangout Live who have a specific question around this topic, feel free to jump on in as the first ones. If you'll let me, John, I have two or three questions. They're very simple because I have to say I never worked with AMP before. So we are at the basic level, but I think it will be good for start because I imagine a lot of people in my shoes not having a lot of experience and maybe will be useful for them too. And then I will shut up and I will listen to more elaborated questions. So my two questions are the first one is one thing you say that the main merit of AMP pages start with they are much faster. One thing that worries me and which always worries me with CDN networks too was that on my site, 95% of these that come from my country, they are not global. So I'm afraid that the distributed content, which so it will not help me, but it may slow. Actually slow my page because I am confident that my server is really fast and confident. It is located in Romania. It has great peer connections with most of the internet servers. OK. So that's a good question. What's all that it may slow in this case or not? It's a good question. The answer is that, well, first of all, we hope it's not going to slow your page down because we're reusing the same Edge infrastructure that Google Search uses, meaning that it's very, very likely that we're using a server in Romania if your site is in Romania. Because, again, it's the same server infrastructure that is used for you to be able to access Google very quickly. That's the first thing. The second thing is that we've seen in rare cases that the AMP cache was actually a few milliseconds slower than the origin in certain countries. So fairly, to be completely transparent, that's true. However, the AMP cache, being searched through the AMP cache can do things that, from your own origin, you will never be able to do. What it means is that we can safely preload the first viewport. So in fact, on Google.com, if you look at the search carousel or even on the organic search results, we will preload a number of those pages right after you enter the page. So when you click on the result, Chinese sites already loaded. So that means even though the cache, in the worst case, might be a few milliseconds slower, you will still get a site that loads at least one second faster through the preload. So I think the benefits here outweigh the downsides. OK, thank you for this. And the second one, you said that it works on a certain browser. It doesn't work on our browser. Can you detail a bit more about this? Which browser supported at this moment? We trans-downed. Sure. Because AMP also now, what browser our visitors use. And we could all make a better decision if we have to implement that now. It's not different for us. Yeah. So AMP is actually supported across all browsers. And the last two, basically, generally you support the last two versions of all browsers. But really any browser was with a region of a market share. And then with ServiceWorker and other PWA features, it's a different story. So ServiceWorker is not yet supported in Firefox, supported in Chrome, in Opera as well, and the Android counterparts. However, it is not yet supported in Safari and not yet supported in Edge. Now, it's on the roadmap for Edge, as far as I know. So it's definitely coming to Edge. We don't know when it's coming to Safari. Because Apple is usually very secretive about this. So the way to make it happen is to annoy Apple as much as you can. So please, because we're annoying them already. But please just, if you want that feature to happen, just tell them that you need it. Go to the WebKit bug tracker and let them know that you need it. OK, and really, really last one. You said there were cases of pages where it is really recommended to use this method, which would benefit most. Can you give one or two more examples of very dynamic sites, which where it may not be so good? Or other dynamic sites, it would be good for any site? So basically, it's going to be good for any content site, meaning that if you have content, if you have static content on your website, it's going to be good for you. To rephrase this, it's going to be great if your site gets most of their traffic through search discovery or sharing. So if you get most of your traffic through Google Search, or Facebook, or Pinterest, or Bing, et cetera, or just chat up sharing, as opposed to people navigating directly to the URL, typing in cnn.com directly, then chances are that this pattern is for you. This is probably the right pattern for you. If you're building an app, a pure app that doesn't have any content, for instance, I don't know, a color picker. So you're building a color picker app, any kind of app, or you're building a flashlight app, so any kind of app that offers just pure functionality and not really has content, sub-sites, sub-pages, those pages really should only be a progressive web app or a web app in general. And they really don't have, there's no point in adding AMP to that site. So I hope that answers it better. OK. Thank you a lot. And once again, sorry if my questions are very random. No, no, OK, questions. Thank you. OK, thank you a lot again for the presentation. Next question. All right. If nobody wants to jump in here live, I'll go through some of the questions that were submitted for the Google Plus page. And we can see there. So the top one, not really a question, Google should invent a new product, a CMS, that implements PWA and AMP. What do you think? A CMS that implements PWA and AMP. Yeah, I mean, sure, we can always reinvent the wheel. But I would much rather see existing CMSs jump on the PWA and AMP train. And in fact, we're doing that. We're working with existing CMSs to support AMP and PWA. For instance, there's first-class support for AMP in WordPress and also in Drupal. So we work with both of those teams to implement AMP plugins. In fact, even if you're on a hosted WordPress site, you can enable AMP for your page. There are still ways to go. There are some trickiness involved modifying the template for your AMP page in that case. But it's definitely happening. Now, in regard to completing new CMSs, I don't know if that's in scope. But I would encourage you to check out what solutions exist with the current CMS space. That sounds great. Yeah, it's always good to get suggestions. But starting at the current state, it's good to start somewhere at least. Another one here is we're one of the leading sports media houses in India. How important is it to have our live blogs on AMP? Well, again, it really depends where your traffic comes from. So that's the answer. If your traffic comes from organic traffic or traffic from sharing, then I think it will be quite beneficial to implement AMP. Because again, your pages coming from those sources, coming from platform to support AMP, will load a lot quicker than without AMP. And again, you're looking at a 50% dropout after three seconds. So again, if you get a lot of traffic from Google Search, AMP is probably a very good idea. And this is actually important to say, too. We have live blog functionality in AMP. And we actually just recently released a tutorial on amproger.org that talks about how to implement a live blog. So that might help. Fantastic. Here's a multi-part question that has some topics around advertising. Will AMP have a new ad format in PPC or digital advertising? A new ad format? Yes. Well, actually, so my guess is the answer. I'm not really sure what that person is getting at. But if I interpreted correctly, then the answer is yes. We're doing something called AMP for Ads, which is born out of the need to also level up ads. Because with very fast loading AMP pages, usually on a normal mobile website, most ads are render-blocking, which means that content, piece of content loads, then the ad loads, then the next piece of the content loads. And so the user gets a very strong experience. But it also means that the user will not see the rest of the content before seeing the ad. Now with AMP pages, the content is always prioritized. So what you see is the content first, and then the ads kind of trickle in afterwards. And this means that a lot of the time, the ads are just never going to be seen if they're going to load slowly. So we're trying to also bring AMP to ad tech providers and ad vendors, allowing them to use AMP to actually build the ads, and so benefit from the same kind of pre-rendering strategies, et cetera. That means that the ads will be much more lightweight, and will also appear much quicker on those pages. So it will be a win-win, both for the user and the battery of the device, and the actual provider and demand utilization. I think that question came up because of the Wall Street Journal article about how publishers were seeing a decline in ad revenue or stuff like that. OK. Yeah, so again, this is probably the reason. So most of the times, I don't think, OK, so this is a symptom. So AMP is basically showing the problem that ads have today by making itself fast and leaving the ads behind right now. So and this is a scenario that's not really helpful if you want to monetize your pages. So this is why now with AMP for ads, we're trying to level up the anti-ecosystem so that it evens out again, so that you can get the same kind of monetization, actually hopefully better monetization than before with Photoshop ads. Yeah. All right. What's the user agent that's used for the AMP cache? Good question. Imagine it's documented somewhere, right? I'm pretty sure it's documented. I don't know it at the top of my head. Sorry. Are you required to use AMP experiments when doing A-B testing? Are you required to use AMP experiments when doing A-B testing? I don't think so. No. But I think A-B testing itself is still an experiment right now. I could be wrong about this. I have not used it yet. So please ignore my ignorance, yes. But yeah, A-B testing is a recent feature that we added to AMP. I'm not sure if it's out of experiment yet. In general, you don't have to use AMP experiments for that. OK. There are a bunch of more similar questions from the same person. What I would recommend in this case is maybe post these in the help forum, and then we can follow up with you in the forum there. Because sometimes these things are like answers that we have to look up and check with other people on the team to figure out what the actual current answer is. But if you post in the forum, we can follow up on you with that there. That'd be great, yeah. Can you explain more about AMP and sites that sort of hosted videos? Is that something that's possible? For example, would YouTube maybe move to AMP as well? Mm. That's an interesting question. That's certainly a possibility, but it's not clear how it would work. My guess is that in the case of YouTube, for instance, there's an actual AMP YouTube component. So YouTube itself could use the AMP YouTube component to build their own pages. This sounds kind of weird, but I think that's probably the pattern they want, because in the actual AMP YouTube component, they can use any kind of JavaScript. So that would probably be the way to build those pages, which means that for any new video website, they would probably do the same if they want to have fully customized player. However, there's also a tag called AMP video. And so if you just want to build straightforward HTML5 video, then you can do that with the AMP video tag. Unfortunately, that doesn't give you the ability to do adaptive streaming or things like that. So it's a story that's work in progress. We're very much focused on the video use case. And if you want to build a site like that, please let us know what you need in order to make it happen, what kind of restrictions you need to have lifted, because we want to support your use case. Awesome. Here's a question that probably goes more into the search side of things. Should we use the hreflang tag on AMP pages? If yes, what if the alternate language page doesn't have an AMP version, should we indicate the non-AMP version on the hreflang reference? So I guess what would happen here is you would refer to the canonical web page anyway, and that's where you would have all of these search-based indexing and serving meta tags like the hreflang tag. So that's something you wouldn't have on the AMP version, but rather on the normal web version. Yeah, perfect answer. I have a question. I've been looking at AMP specifically in the search console and specifically looking at the search analytics side, looking at click-through rates compared. And nobody really looks at this stuff, and I keep asking. It would be great to click-through rate is very important, like how many people are clicking from the search results to your site. And it seems, and I really appreciate you guys breaking out the AMP articles rich results versus AMP articles not rich results. Because it seems like the rich results articles, I guess the top stories, carousel, has incredibly low click-through rate compared to anything else. So when I filter click-through rates, when I filter by desktop as a pretty high click-through rate, but I go down to mobile, it drops about half. I guess that makes sense from Google to the web page. I don't know why, because it's less, I guess, real but then when I go to AMP rich results, it's like a tidy fraction compared to not rich results. So the good thing is AMP not rich results has a pretty same click-through rate than the desktop results. But I'm curious is why are the rich results, I guess the top stories, the click-through rate way lower? So obviously the impressions are way higher than the top stories for me. It's probably sevenfold, but the click-through rate drops drastically. I don't know if that's just me, if you guys were looking at that or you have no idea what I'm talking about, but have you seen that? That's an interesting observation. Unfortunately, I don't have any answers for you because I only work on the AMP open source project and not on the Google search side of things. So I just, I don't know. That would probably be a good question for the webmaster forums or something like that. Right, John's here. Yeah, I don't know the specifics there. That sounds like something probably worth looking at some of the screenshots to see what you're actually seeing. Hard to see. All right, here's a question about the AMP cache. Is this proprietary to Google? Is Google going to allow other CDNs into this technologies? If Google has access to AMP data, will Google use this in the future to directly embed things in its search rather than pushing people to the web servers? Okay, so the first part of the question is relatively easy to answer. First part of the question is, yes, we are opening the cache function ID and we actually already did. We released the spec for the AMP cache and the guidelines for the AMP cache on the AMP HTML repo a while back. And so we invite every other company to build an AMP cache and just conform to the guidelines. And the most important guideline is that whatever is served from the AMP cache needs to be visually intact. So they can't really modify how your page looks like. That's really important. So inserting ads is something I would never find. So the important bit is that it's up for the platform, the platform that embeds the AMP pages to decide what kind of cache to use or whether to use a cache at all. So for instance, Bing right now does not use the cache. We would of course like platforms to use one cache but building AMP integration without a cache works. It's just not going to be as fast as with a cache. And in the future, Bing or Pinterest or any of the other sites could decide to use a completely different cache that is not Google. No announcement right now, but I think there's going to be more caches coming. The second part of the question. So can you tell me that again? Good question. Let me see where it was. So many questions. Don't have it here at the moment, yeah. Okay, yeah, I don't think it was a question I could answer anyway. Okay. All right. So it was about AMP data or something. Yeah, again, I can't. If Google is going to use the cache in other places as well. I can answer that question. I don't know. All right. Do you know anything about combining PWAs with app indexing? So. PWAs with app indexing. Well, PWAs are already websites. So there's no point to app indexing them. Maybe the question set us around when a PWA is prepared with this app indexing. And that's kind of an interesting question that so far doesn't have a good answer, I think. In the case of AMP, if you're publishing AMP pages, then it will overwrite app indexing. So that's important to note. So if there's an AMP test result, it will not use app indexing. Yeah, and for PWAs in general, we recently, like, I don't know, maybe a month ago, did a blog post on how to make indexable PWAs or how to make sure that your PWAs are indexable as normal web content. So I would check that out on the Webmaster Central blog if you're looking into making PWAs and you want to make sure that everything that you're putting together there works for search automatically. So that's the possibility. You don't need to do anything special like with app indexing if you're using a PWA. And I guess the last one that I see here is a bit more philosophical. What strategies are you using to make AMP more popular among developers? Interesting. Well, I'm trying to go to a lot as many conferences as possible, trying to be accessible as possible. Also make sure that AMP itself is an open source project and that everyone can participate. And inviting more people to become contributors to AMP. So it's not just seen as a Google thing. I think that's really important. Right now, it's true that everyone on the team is on the core team as a Google employee, but that's not necessarily what we want. We want others to step up and contribute. So I think doing that, then also trying to be more involved in creating specs out of AMP, driving standard specifications, all of those things are important for the future in order to see more approachable and to really make people feel that they have influence over what AMP can do and what AMP should do. OK. That sounds fantastic, yeah. And just a word of warning, my computer battery is at 6%. I'm really glad I lost it that far, but I can't find a black. It looks like we only have two minutes left anyway, so that's good. Yeah, perfect. So I guess with that, let's wrap up here. Thank you so much, Paul, for all of your time, your presentation, all of those links to try out. I'm sure this will give some of the developers out there some inspiration and ideas to look at over the holidays. And maybe we'll see some more combined P2A and AMP setups in the new year as you've been able to try things out and see how things work. And please, if you have any follow-up questions, ping me on Twitter or reach out to me any other way. I'm always open for discussions and questions. Fantastic, great. And if you have general search questions, of course, dropped by the Webmaster Help forums. We'll try to help you there. We also have more of these Hangouts lined up for this week and for next week as well. But let's take a break here. Thank you all for joining. Thank you all for your questions. And thanks again, Paul, for your fantastic presentation. Thank you. Bye, everyone. Thanks so much. Cheers. Cheers. Thank you.