 It's time to go ahead and get started, so it looks like people are still kind of funneling in. Is everybody ready to go? Everybody amped up? As you can see, this is Drupal in a Google AMP world. I grayed out the Google, because technically the AMP project is an independent open source project now, and so despite the fact that it's supposed to be disassociated from Google, I've actually been to a couple of AMP summits, and it is only Google people. So yeah, it's going to be a while before they kind of shake it off. First I just want to say thank you very much to everybody here at DrupalCon, and for all you attendees, especially here in Vienna, I know that this is really going to be kind of the big banana for Europe, and so I'm glad that we're able to share this together, and I hope that you find some value in this talk. I want to let you know that I gave this talk already to the Austin Drupal user group about a week ago, with lots of direct interactions throughout. It took about 45 to 50 minutes, and so I don't expect this to take the full hour, and so if you guys want to go play afterwards, you'll have plenty of time to do it, most likely. So first I just want to kind of talk about it over you, the talk, and kind of move from there. First I really want to talk a little bit more about what is AMP, even though we're talking about it really kind of in the context of Drupal. I think it's important to understand what AMP is, so that you'll kind of have an idea of what you're getting into if you don't already know. Next I want to talk about how AMP will make things better for you. Your mileage may vary, but kind of talk about the benefits of implementing the technology and the paradigms. Afterwards, I want to talk a little bit more about what's involved with making your Drupal instance AMP ready. We'll talk about things like the theme and things like the current module, but there's a lot of other items that just implementing AMP is one thing. It's kind of what's going to happen afterwards, right? The impact it's going to have on your web properties that we want to talk a little bit about. And then after that we'll kind of open it up for questions and discussions necessary. So first really what is AMP? AMP stands for Accelerated Mobile Pages. And there's really three components, but what I think people kind of leave out is the fact that AMP is really more principles than technology. We'll talk about those principles. We'll talk about AMP HTML, which is what is ultimately assembled for an AMP page and reflects an instance. Next we'll talk about AMP.js, which is really the backbone of AMP. After that we'll talk a lot more about the AMP cache itself and what that means in terms of the AMP offering as a whole. But I highly encourage you, if you want to learn anything about AMP, to go to theampproject.org. They do a much better job than I do explaining what this stuff is and how it works. All the answers to your questions could be answered there. And they have a really handy contact us at the very bottom so you can reach directly out to the people and they will be more than happy to work with you. So principles, principles first. What they really want to focus on is how the user experience is greater than the developer experience, right? And so that's even more important than the ease of implementation. And so there are some nuances, some quirks, some difficulties behind AMP that a lot of developers feel, but ultimately it's all about user experience, right? We're talking about speed, we're talking about reliability, and sometimes you're just going to have to kind of swallow the pill to make it work. And for those of you that are involved with web optimization and web performance, oftentimes it can be a pretty hairy battle, right? Just to squeeze half a second out of your website, especially if it's the grand summary or result of years of bad practices or just kind of compromises you may have made against your better judgment. So that's really what it's all about is the user experience. Only do things if they can be made fast, and that's really what's key. You'll find that there are a lot of components, a lot of tags, a lot of facilities that are provided by the AMP project, but I want you to understand that the reason that they built those was that it was focused around the performance profile, right? And so if they implemented say like a Facebook tag or some kind of a widget like slides, right, for instance, they only did that because they could make it fast and it was, you know, in line with their principles for speed. And then once again, you know, the focus on the user experience is that, you know, that stuff should be prioritized, but you know, you can compromise when needed. Now, what's interesting about this principle is, you know, it kind of contradicts with certain aspects of AMP and we'll talk a little bit more about that in a moment here, but again, user experience, speed, that's really the goal. So AMP HTML, you know, it is HTML, but it has some restrictions. You know, you can usually identify AMP HTML pretty quickly by knowing that it's AMP, you'll usually see this really sweet little lightning bolt or the word AMP actually in the tag, but that's the number one indicator. It starts with the first thing to say like, this is AMP HTML, right? There is no external CSS in AMP HTML, which I think is really worth pointing out. You can't include a style sheet, which is, you know, where some of the pain can be felt, right? And most people are just, oh, yeah, you know, style sheet, right? No, that's not the way it works with AMP HTML. We'll talk a little bit more about that here in a moment, but you have to embed all of your CSS or custom CSS in the head of the document, and there's a limit to how much you can actually put in there to maintain performance characteristics. And then, of course, there are the full tag substitutions to make sure that everything is performant, right? So a good example of that is the AMP image tag. For brevity, I didn't put all the various attributes that are required, but for instance, on an AMP image, you have to have width and height. And that's so that when the page is rendered and it draws out, it will know the dimensions in advance so that it can build the page out correctly, and that's part of the speed requirements. So again, it's HTML, but there's some restrictions. And while I won't talk about a lot of those restrictions for the individual tags here, again, the AMP project will give you everything you need to know and a justification for it as well. So this is what an AMP document, a very minimal document, will look like. A couple of things I want to point out. You don't have the lightning bolt in this one. They decided to go with just AMP here. But some of the things that are very important to point out is how this script right here is very early in the document, right? Also notice that it's async, so even though it's early, it's still getting a certain level of priority. There's this schema, which helps for the identification of the types of content, especially when it comes to indexing and presenting that information back in search results. Stuff's pretty important, as is this viewport. It has this canonical link right here, and that stuff is all described for what it's used for. And then lastly, there's this boiler plate, which is a lot of the animation overrides to make sure that how things are rendered are somewhat normalized. There's a really interesting explanation about it on the website, if you guys want to know a little bit more about it. But after that, you kind of just go and you can start adding to the body as you normally would. So AMP.js, I want to make it very clear. It's a part of AMP. It's not a custom dev framework, right? It's not like React or Angular or jQuery or something like that. It comes back to this include right here. And so what happens is you bring it in, and it ensures that you get the fast rendering of AMP HTML pages. And it does that by loading all resources on the page asynchronously, based on the tags, the sources of the various tags that you've got. And it also carries the definitions of all those custom elements, right? So AMP image, AMP Twitter, stuff like that. It knows how to interpret those. It knows how to render those. It knows how to make it all wired together. And it all runs just by virtue of being included in the page. It implements the conventions, but what's even more important is that it implements the validation. And so just briefly, I want to talk about how AMP documents can be validated against the rules, the principles behind it. And that's amazing because show of hands, how many of you validate your HTML? About half. Do you do it automatically? Even fewer. So you guys are the few, right? And so with AMP, it's nice because validation is just really an integral part of it. It wants to make sure that you're conforming to the conventions to make sure you keep those performance characteristics. If you go and throw just big images, or you throw too much HTML, or you include render blocking components, it will yell at you. And so that validation is really critical. You can use it for your needs, but Google will validate your documents. And it will penalize you if they're not valid. So again, it's all about that include up there in the blue. You just bring it in, and you can use it. And it's just part of your standard boilerplate document. So AMP cache. That's really kind of the unsung hero of AMP, in my personal opinion. You build a document, you include the JavaScript, you make it all validate, and it's all good. But what about the speed of your page as it relates to the user's location if you're hosting it from one data center? It's still only going to be as fast as that connection. Well, AMP cache is a facility that's provided CDN, and it will deliver all valid AMP documents once it's actually been identified and indexed. And that's huge. That way, it will deliver it for you. It will deliver it instantly as part of search results. And so it sits in front, and allows for things to maintain their performance over the network as opposed to just the document itself. And that's really huge. And it guarantees your performance across the globe. For websites that I run, it's tricky trying to run a distributed application in multiple geographies and maintain a high level of performance. And so it's nice to know that you kind of have this CDN that's provided that kind of automatically keeps things fast for you. But the key is that it only will store valid documents. And so it performs validation for you, and it will kind of enforce the rules. And so that's kind of nice, but it's also kind of difficult to work with in some ways. But if you're going to use AMP, why not take advantage of the AMP cache? They built it, and they provided it for you, and it just really ensures that performance. And then in some ways, too, it also goes above and beyond because the AMP cache is all HTTP2, and it leverages the performance characteristics of HTTP2, such as compression for headers, stuff like that, where it will keep things fast, and it knows how to do so in the context of AMP documents. And so that's nice from an ops perspective, where if you have an implemented HTTP2, as long as you are delivering an AMP document, and is able to be cached by the AMP cache, you can get HTTP2 benefits without doing anything to your existing infrastructure. And here's the best part. It's free. And I know we all like free. No? Yes? OK. So how will AMP make things better for you? Well, first, as you can see about the principles, it's really all about the user experience. And I think that all of us like fast pages in as long as there is a principled discipline that allows you to have fast pages that will be relatively minimal in terms of complexity, then you're guaranteeing yourself a better user experience. It is reduced complexity. If you've got a ton of CSS on your website, that's a complex website. Not only is it going to be slow, but it's going to be difficult to maintain. I mean, who in here likes CSS and likes fighting with CSS all day? Who here has websites that's got 10,000 lines of CSS? Yeah, yeah. That's complexity, right? More consistency, I mean, I think that you're going to find that as long as you are producing reliably consistent AMP documents that are valid, you're going to get a consistent performance. If you're using AMP cache, you're going to get consistent response times. And so you're not going to be subject to the effects of response times, especially for averages, where say somebody accesses your website from a country that's got a slow internet connection. Your averages get dragged up, right? Because even though it may be fast in, say, like the United States or in Europe, it may not be all that fast in, say, like Africa or to something like Australia, right? And so you get that better consistency with something like AMP cache. Now as far as the better user experience, again, you get that mobile-first profile, the validation does improve the reliability of your pages. The better interactions with the AMP components is really important. Not only are they insured to operate quickly, but they're insured to operate, which is huge. They're going to provide you things like the slideshow or the Facebook integration or the analytics integration. And they have vetted that not only does it perform, but that it actually operates. And so instead of you writing your own custom implementation, which may be subject to break, you're using proven, reliable components. Now in terms of reduced complexity, this comes back to the limits on CSS. You only get 50K of CSS. And so you're going to really have to choose what you want to build and how complex you want things to look. And I think that's important, especially when it comes to the balance between UX and design and development, having some constraints. Because oftentimes, speaking for myself as having filled both roles, but being dominantly dev, I can get crazy requests coming in, which is tons of CSS or something that's going to require so much CSS, or just really complicated CSS to achieve something. And then it may not work in all browsers. It's just really nice to operate with some level of constraint. Only the AMP elements are supported, so it guarantees that performance. And so you're not going to have the burden of building anything, or you're not going to have the chore of, say, going out across the web and looking for some kind of turnkey component for something, like a slide show or something. At least you know that you're getting it from a pre-vetted list that's already ready to go. And then those principles and docs provide good guidance and context. And so as you've got developers, a developer team, and then they're all trying to produce an AMP document, and they're all referring to the same documentation, and they're all operating under the same principles, you're going to get a lot more understanding amongst them and agreement, which I think is really important, especially if you have, say, a distributed team. Now, again, the CDN does improve that global and device consistency. And I think that that's really important. You want to know if your website's fast no matter where you're at. So that consistency is huge, and that's a big benefit to why, what AMP does for you. That validation of documents does enforce that consistent profile. Again, it's a valid document, so I know it will be fast. And then I know it will be consistent. That consistent development, once again, is just huge. Having developers all on the same page is a big one. And being able to take away the opinions from, say, senior developers versus junior developers, and then being able to point back to this one single source of truth about how documents are supposed to be formed and operate, that's a big benefit. I mean, think about it. How many arguments have you seen? I have just semantics of CSS or HTML. I've seen lots. And then with the divide of traditional HTML versus things like HTML5, I've seen arguments about the article tag. It's time to overcome that stuff and get a little bit more consistent. So what's involved with making your Drupal instance AMP ready? So I really want to talk a little bit more about the AMP contrib module that's out there right now. I'm going to talk also briefly about the AMP contributed theme. But then I want to talk a little bit more about the analytics. And there's not really anything that's turnkey or specific to Drupal per se when it comes to the analytics. But I think that it's important to point out what's going to happen once you've got AMP pages out in the wild and how you're going to try to address those things, running them from your, not only your instance, but also the broader web property as a whole. So the AMP contrib module, there's the URL. Pretty easy to look up, but it's there for your reference. I want to point out that you need to make sure that your website is governed by a composer-based installation because it requires the Lullabot AMP library. The AMP library is really quite fascinating. What it will do is it will take HTML as an input, rewrite it into AMP HTML, and spit it out. And so there's a lot of magic that's happening there. And so that's really good for say like WYSIWYG content where you've got embedded images or whatever have you. But at the same time, I want to point out that it is rewriting your output kind of without your knowledge, right, or control, right? It's just this kind of crazy format output. It does provide all the different configurations you can have for a Drupal instance in terms of AMP readiness. It provides a variety of display modes or view modes. And it provides the different text formats that will be required to make sure you're outputting valid AMP. And that really kind of ties in these text formats in the AMP library kind of go hand in hand. And then it also handles other elements as well. Now the theme, you would think that the theme would be responsible for most of the actual HTML tag implementations, but it's not. The module does quite a bit of it. For example, the AMP analytics tag, it will embed that tag for you based on the presence of an actual configuration value. And so it does a lot of the heavy lifting for you. And because it does that, it may not necessarily provide all of the features or functionality you need. So like AMP analytics is a good example of where you might need to do something specific. But it's just got one single configuration that will embed that tag for you. And so depending on the level of complexity of your website, you might find that the AMP contrib module is helpful only to a certain extent. You might actually need to implement quite a bit on your own, depending on your needs. What will happen is you will activate the module. And then you will need to specify a theme. And then you will need to create an alternative view mode for each of your content types. And then you will need to go to each of your fields. And then you will need to apply a text format. And when it's all said and done, you will have a duplicate version of your page that should be AMP compliant. And you can access it by simply adding the AMP query parameter to the end of your document and end of your URL. And so for the idea that you actually have to have two versions of your website, there's the standard version and the AMP version, this kind of enforces that paradigm. Now I can tell you now that, in my opinion, you don't have to have two versions of your website. Now I think when it comes to Drupal, it's kind of forced if you're going to use the contrib version or the contrib solutions. But one of the principles, and I didn't really talk about it here, is that AMP shouldn't break things. And that should be the last thing it does. It's HTML with restrictions. And so for instance, my website is an AMP website. There's only one version. It's AMP. It loads great. It loads great on every browser. And I don't have any issues with it, right? But then again, it's a manually curated HTML. It's not an actual Drupal site. And so I'm able to get away with that. So I want to point out that once again, that the AMP URLs go to the AMP view mode for a content type. And so if you've got two dozen content types, you're going to have two dozen view modes that you're going to have to go configure. And that could be a bit of a chore, right? Hopefully, depending on the complexity of your website, only some content types would be in scope. I would hate to think that you would have to go do this for all of your content types, right? And it can be tricky, especially if some of your content types already have multiple view modes, say like a teaser versus the default, right? Well, then would you need an AMP teaser and an AMP default? And then so at that point, it almost forces like doubling up. And again, that library can rewrite the HTML via the field format. And that's, I think it's worth pointing out as a word of caution. However, we use Drupal to rewrite our output all the time. So I don't think that there's any point in being hypocritical about it, right? Token replacement's a good example. Stripping tags that are not allowed in some field. We already kind of do that, so we should feel relatively comfortable. Just know that it's not Drupal that's doing it. It's a composer package that's doing it. And so I think it's worth pointing out. So that was really the module and what you would get from the module itself. Then there's the theme. And despite the fact that you can install the module without the theme, you won't get any kind of output. So you have to install the theme. There's the URL for your reference. So it comes out of the box with a base theme. Then it comes with an example theme. The base theme cannot be set as the default for your website. It will totally explode, and I highly recommend against it. But you can also specify a theme in the module, which will be a sub theme. But you can't specify the base theme. And so it's a little tricky. And that's really kind of what this line talks about, how it can't be the default for the AMP configs. And so if you're going to actually go down this route, you have to implement a sub theme. And so there's some work there. It's not quite as turnkey as you might hope it is, where you just beep-bop-boop. Unless you want to use the example theme. And even then, that's only going to take you so far. And so understand that there is a level of commitment that's going to need to be applied if you're going to go down this route. That's the example sub theme. And the good thing about it is that it does work, and you can use it to see an example of how things will work. And it does provide guidance in terms of the actual code, what the twig files should look like, what the configurations of the sub theme should look like. So it's helpful, but it only goes so far. It's really just a base theme that you're going to be obligated to extend. Next is really going to be focused on these analytics. What happens to your analytics? What happens in the world once this is out there? First off, you have to use AMP-specific analytics and add tags, very much like you have to have AMP ready image tags or social media tags, whatever have you. That's a good thing. There are really two versions of it. There's AMP Pixel and AMP Analytics. AMP Pixel is really quite neat. If you just need to do page views, if you're not doing anything sophisticated with your analytics, AMP Pixel is great, poof. It's just this little tiny pixel. It loads up instantly, and it tracks your page views against measurement protocols. It's very lightweight. But if you need to do something a little bit more sophisticated, say like if somebody completes a form, you want to track some kind of event, you would leverage AMP Analytics and some of its protocols to perform those types of operations. E-commerce tracking is another good example of the kinds of things you would need to do with the AMP Analytics counterpart. So regardless of which implementation you use, AMP manages a client ID for your browser. And I want to point out how really awesome that is, that they did that for us. And that really comes down to the fact that if you're using an AMP cache, your website's going to be served from URLs that are not your domain. And so wouldn't those be duplicate page views? Wouldn't that be another property? Wouldn't those be other sessions? Well, AMP overcomes that by governing the client ID that's used in identifying all of your tracks and your measurement. It does that for you automatically. And that's just one of those things that you have to kind of get into the docs to figure out, but it's a huge accommodation that they just kind of baked in. And another reason why you want to make sure you conform to the different tags that they provide. So you will get the impact on URLs at the very least. If you're going to go coming out of Drupal, you're going to get the AMP query parameter. And so you would see that in measurement reports unless you have some kind of filters pulling that out. But you do have the cache URLs versus the domain URLs. So here's an example of CNN, which has AMP articles. When you do the search and you see an article and you click on it, this is the URL that will be in the URL bar. And so who gets the credit for that page view? How do you know that people are even hitting your website? They're not. They're hitting it from cache under a different URL. But if you're using the AMP analytics tags correctly, it will automatically know that it wants to use, actually wants to attribute the page view against this portion of the URL and not Google.com. How are you getting a bunch of Google.com page views? So it will overcome all that stuff for you. And again, I want to make sure everybody understands that these are the implications that you're going to be fighting once this is out in the wild. Luckily, they have a lot of baked-in solutions for you. That's really it. Again, I said this was going to be relatively quick and easy. I didn't want to overload you with too much text on the screen. But that's really it in a nutshell. Any questions? Everybody? You guys are just so alive. And please. Quick question about validation. So when you update your content, how does that get spread back to the cache, Google's cache? That's a good question. So if you update content, your server should deliver headers that indicate that it's been modified. And then the next time it tries to pull it up, it should see that there is a conflict between the last modified date. And then it should automatically update it for you. It's not really any different than the operation of, say, like Akamai or Varnish for that matter, any kind of edge kind of cache. And so it does honor those kind of conventions. And so yeah, nothing new, nothing new there. Any other questions? Has anyone implemented an app site? Yeah? Am I being truthful here, guys? You don't think so? Please. Hi. For an AMP implementation, how do you handle pages for which an AMP version exists, but they have been accessed directly from the browser or from some through the navigation of the website and not through the Google search results? Are you kind of forcing the AMP version to the user? Or you will serve, let's say, a responsive version, a responsive mobile version to the mobile device? That's a good question. So let's go look at this area over here. If we go into the guides, let's see here, there's a section that really covers like the, let's see here. Here we go. Discovery. So you'll have the AMP HTML version described in a link, and then you'll have the canonical version. And so what will happen is your search results will see that you've got these alternative versions linked in your document, and it will want to present the AMP version for you. But the canonical that you've specified is always the original document. And so unless folks are going directly to that URL or you are linking to that URL, it should be just the same website. Does that answer your question? So I'll rephrase it. In our context, we are only enabling a subset of the website for AMP, not everything. So let's say a user from a mobile device would go into the home page of the website. And then through the navigation of the website, it will land onto a page for which AMP exists. So right now, there is no mechanism for the browser to understand that that page is also AMP enabled and to get the AMP version instead. So unless you're coming from the Google search results or some other websites like LinkedIn or whatever, they are fetching from the Google CDN, there is no automatic mechanism to say, OK, there is an AMP version for this page, take the AMP version instead. So that was my question. I understand. To me, that sounds kind of like a specific use case, because it's a subset of your pages and you've got a menu. I would look at maybe just off the top of my head, something like a device, interpreting the user's device to see if they are a mobile user and if they are a mobile user use context to provide an alternative version of the menu that picks up the links for the pages where that is an option, something like that. It could be that it's either the user's device where it also could be the viewport width, which would just kind of imply that it was an AMP document. But that sounds like it's kind of an individual use case overall, because the devices themselves aren't looking for mobile page options. Now, that may not be true in the future. I could see that if a user, say on an Android device, is using the Chrome mobile browser, it could very easily interpret these link tags. And then automatically, you wouldn't have to modify your menu. The theory is that if you went to a page and as it was loading, it encountered the link tag early in the head. And it saw that an AMP HTML counterpart existed, it could then redirect temporarily to load that page. And I think that that would be a fair feature. I don't know that I would want it to be something I could disable, I don't know that forcing it would be a good idea, especially if, say, because it's a separate version, it's not beyond the realm of reason for somebody with an existing website to want to be adapting it for AMP compatibility, but it's not official yet. And then if it started going to AMP pages that are not fully fleshed out yet, and they're kind of broken, it could be problematic. And you would want to make sure that you hobbled that kind of functionality at word out there. Does that answer your question a little bit better? Great. Any other questions? Any stories? Yes, my question would be, well, this is for anonymous users to cache all the sites anonymous users can see. But what happens if a user is logged in with a Chrome browser and is coming to Google searching for something, finding the AMP, what version will be a display for him? That's a good question. So it needs to be a valid document. And so as long as you are telling, you are making the pages discoverable to Google, you're indicating to Google, I want you to see these alternative versions. Does that make sense? Maybe I didn't. Maybe there's a little example. Yeah, please. No, if you have an example. Oh, well, so let's see here to repeat the questions so I understand completely. How is it that if a user goes to search results, that you can indicate to Google to serve AMP as the results? No? Right. All right, so I'm never logged in with the AMP and I see the cached one from Google. Right, yes, Google won't give it to you unless you're on a mobile device. But you also have to have this discoverability, right? Google has to also know that it can give you an AMP alternative if you're on the right kind of device. All right. That's interesting. But I don't think that Google would be involved with the personalization. But if we were to use, if there were dynamic content, let's go in here and let's go look at the reference, for example, like dynamic content. So if it were like a web push or some kind of user notification, just as an example, that would still be part of the device session, right? I mean, the default page that's delivered by AMP cache or by your site is still going to be generic, right? Unless you actually have Drupal doing the assembly of the personalized content. Like if that content's loading asynchronously on the client based on some kind of reverse IP lookup, which I would recommend, right? Then it wouldn't matter which version you're loading. But if it's Drupal that's doing, if it's a server side perspective, then that would be tricky because you wouldn't want it to cache, right? Because it would be personalized, right, out of cache. Yeah, that would be how it's loading from that one URL. Yeah, if it's coming, even if you're logged into the website, if you do a search result for the same website and you're getting an AMP search result that's valid in the cache, yeah, it's not going to hit your website whatsoever. It's going to load it all straight out of the cache and not just the page, but all of the components as well. So images and all that. Another question. How is it about other search engines like being how did they implement it already, maybe? I'm not sure if being is honoring the AMP project. I would assume that they're not. I mean, it's Microsoft. They always kind of go their own way, right? But to my knowledge, being does not deliver from search results that are in the AMP caches or anything like that. But that's just to my knowledge. I haven't spent that much time on it, to be completely honest. Thank you. Well, thank you so much for the question. Hi, I'm Daniel. I work with InSales in a company in Norway. We focus on the media. So this is more of a sales question, I guess. First of all, do you have any good numbers in terms of the results on the other side for the customer? Do you have any very satisfied customers that you can show to? Yeah, I mean, customers, it's very anecdotal, right? But as long as it feels fast to them, that's the real big one. But not from my own personal stories, but I can at least refer to the recent incident where AMP ads were having problems and they were a lot slower than the non-AM counterparts. And so some major websites that were leveraging AMP pulled out because of the impacts in advertising revenues. And Google had to directly make some changes and work with the AMP project to overcome those. Yeah, I think that was covered in yesterday. Yeah, he had mentioned it about that. Yeah, so those would be the areas where that would make sense. But I mean, the justifications for the speed, right, I was actually recommend maybe looking at some of these use cases or these case studies here, like Washington Post, and they'll give you a little bit more concrete aspects. Cool, second question. So now, once you did it a couple of times, I guess, how much time does your team have to spend on it to implement one site? It depends on the implementation, right? So, and I'm sorry to dodge on that, but if you're going to have two versions of the website and you're going to do it through Drupal, it might take longer than if you're just building an AMP only version of a website. And so it just really depends on the scope and what the desired outcome is. And the schema stuff, and this was covered in the one yesterday, that the schema only covers news articles, recipes, and jeez, I forget the last one. But as long as it's a really like a news-centric article, kind of a website, then you're going to get even more benefits, right? Versus if it's just using AMP technology to ensure a certain performance profile, but it's more of a traditional website, this brochure website, or whatever have you. I mean, you're just going to really get the speed benefits, but you're not necessarily going to get indexed articles. And so it's really, it just depends on the context and the level of complexity, right? If you're really trying to leverage the max functionality, it's going to take a little bit longer. But once you've done it a few times, you know what's going on, it's not too bad. But are we talking a couple of hours, or are we talking a couple of days, or a couple of weeks? Well, here's a good example, on my personal website, I converted it to AMP HTML in like 90 minutes. Yeah, yeah, it didn't take very long at all. But then again, I had a simple website, right? So mileage may vary, right? It just depends on the size of the site and what it is that you're building. If it's using a content management framework, if it's Drupal, it could be a little bit more hairy. Yeah, definitely. Great, thank you. Hi, where do you stand in terms of the objections that people have in terms of intellectual property because you're just giving away your website to Google? Are there options to take it down if you want to take it down? Does Google always do the updates whenever you instruct the updates to happen? Where do you stand on that, what's your personal opinion? Because I get a lot of backlash. I just took a picture and tweeted it, your slide deck, and I'm awaiting backlash as we speak. You know, I gotta be completely honest. I give up, you know, really take it. There's no fighting it, right? I mean, you know, I'm from the States. The NSA inspects everything I do and there's just no way around it. And so it's not... But in practical terms, right, like getting changes to happen, taking your own website down because you want to shut something down? Yeah, versus what's cash. Removing a page, yeah, removing a page that might not be the one you want it there. Yeah, I say if you put it on the internet, you do so at your own risk, you know. And then wanting to take it down, I mean, that's tricky. If you're implementing something and you're gonna leverage AMP cash, it seems, in my opinion, you are voluntarily coding it out there, right? You've kind of made that decision in advance and if you want to take it down. Well, personally, I fell for the hype and I installed the plug-in and I have my AMP working for me, but I hadn't really thought it through, so we'll see what happens. But then Google is promoting another kind of similar websites, which is progressive web apps, which share a lot of the same ideas. Or web amps, yeah, yeah. Again, prudence goes a long way, right? I think it's worth taking advantage of it and just kind of living with it. But if you can implement AMP without the AMP cash, right? And so if there's any doubt about wanting to pull something down or deal with the repercussions, then maybe you might just want to avoid discoverability and cashability in general. And just go for the best practices in terms of performance. Yeah, exactly. And so that way, if they are hitting your back end, at least you're just giving a very minimal response that's gonna have a performance profile. That's my stance. We can talk more about it afterwards. Okay. Yeah, you got it. So, well, we've got, let's see here, it's been about 50 minutes, which is almost exactly as long as it took when I was in Austin, which is awesome. But yeah, I mean, that's really all it. So thank you all so much for your time today. And I hope you all have a fantastic rest of the con. I had, this is a really quick plug. If any of you really like breakfast or cakes or teas, there is an amazing little cafe that's a short walk from here called Little Britain. That is just awesome. They have afternoon tea with sandwiches. I mean, they got all kinds of cool stuff, right? And so just my little recommendation for kind of some of the local fare is also another place called Ickies. Now I don't know how often I recommend a place called Ickies, right? But it's right around the corner and apparently they bring you a plate of meat that's grilled and that's it. It's just like this overwhelming amount of meat. And it's supposed to be really good and it's just like right over there. So, guys are looking for some fun local lunch action. Those are my recommendations to you. So, thanks again guys.