 Right, so today, just as a quick introduction about myself, I'm Sovik. I run Mirange, which is a strategic web design and development studio in New Delhi. This is the content web series, which is a series of freewheeling chats for people who create or maintain content-based websites. With content-based websites, I mean typically publishing heavy CMS-driven, could be a marketing site, media site, e-commerce site, any of such websites that are there. And in this space, we want to cover topics from all different practices, which who get together to build such content sites. Primarily, this means people who are working in the content teams, content strategists, writers, people who are designing the websites and developing the websites, both front-end and back-end. So I want to have conversations from all these three practices. And also, in some way, bring in our website owners as well, who could be individuals, businesses, publishers, and any such background. So today, I have two guests, which is a little atypical in content web, and which is great. So I'd like both of them to introduce themselves. So first, there's Puneet and Vimal. So first, Puneet, could you just introduce yourself briefly? Sure. Hey, everyone. I am Puneet. I essentially work as a website speed consultant with a lot of e-commerce and B2C sites across India. So while working primarily on speed and scalability, I tend to get involved in a lot of digital strategy, implementation, and those kind of aspects. And that's where my AMP experience has been coming from. So I've been involved with AMP implementation at a few of my clients. And we've explored like every AMP journey goes. We've explored the pros and cons and things like that. All right. And Vimal. Hey, I am Vimal. I work with six-word technologies. We are a digital agency running in the past 14 years. And we're primarily focusing on Drupal. So recently we started a digital consultation practice here. And I had that vision. All right. So welcome, Puneet and Vimal. Thanks a lot for giving your time. What we are speaking today about and discussing today about is AMP. And if for people who have been following us a couple of weeks back, we had someone from the Google AMP team. Or I should probably say just AMP team or just Google, because at some point they want to keep a gap between AMP and Google as well. So who had come in and told us, what is AMP? How does it benefit us? And in this conversation, we want to take the conversation further from an implementer point of view rather than people who are building those specs or building the technology and building the framework itself. People who are implementing the frameworks, what are the challenges they go through? And how does it fare as an alternative to HTML, which has been there for a much longer time, or other technologies that might be there around? There could be other things that Puneet and Vimal have explored. So this is largely going to be a discussion. And I think today's conversation is going to primarily benefit developers because there will be a little bit of technical aspects that we will be discussing about. There will be a little bit of technical background everything that we probably discussed. And I think it will also affect businesses and website owners a bit because if there is an impact on how websites are implemented, if there are cost implications around it, if there are other impact around it after implementation of the website itself in terms of business, ads, revenue, and other things, then these conversations also interest them a lot to take the right tech decisions with their CTOs. Few basic instructions for everyone who's joining in. This session is going to be slightly different than the previous ones. We are going to have a free-wheeling Q&A conversation with Puneet and Vimal for the next about 30, 35 minutes or so. And during this time, if any of you want to ask any questions, feel free to use the Q&A tab that is there in Zoom. Or if you are on YouTube, you can put in a question on YouTube and it will be forwarded to us. I will take in those questions if they are very relevant in the flow of the conversation that we are in. And in case they are not immediately relevant, we'll take it at the end. So after about 30, 35 minutes of conversation, after that, we will try to take more audience questions. That's the flow that will be there. And if you're on Zoom, you can always come in, raise your hand, and ask the questions at that point of time yourself and have a direct conversation with us. All right, so let's start with just knowing what kind of AMP experience do both of you have had. That just to lay a groundwork around what have you seen, what have you observed, what have you tried and tested. So let me first start with Puneet. And I'm going to go Puneet and then Vimal just simply because on my Zoom, Ty is Puneet is on the left and Vimal is on the right. And that's all and nothing, no other reason. So Puneet. OK, so my experience with AMP has been coming from a few of my clients who have content on one end of their site to bring in the traffic. And essentially whatever the offering may be in terms of them being some sort of platform or selling some courses, whatever, on the other end. So we have gone ahead and explored AMP for the content part of the sites because that is where we see AMP playing a role. So just a bit of pre-think to this understanding has been for us to understand where AMP traffic is actually exposed, where are those additional benefits of AMP are coming from. So what we see is that it is essentially the mobile web search displaying that AMP icon and doing something called pre-caching of search results and thus making the speed experience a lot faster. We'll go into a bit more detail of this. Yeah, in a bit. We're going to that in a bit. Yeah, I'll not go there. But yeah, so that has been one of the pushes. And secondly, the Google Discover thing. So those are the two things that we've actively looked at at a lot of places when we start the AMP discussion. Before we go into this bit, what was your motivation to go in and you're slowly going into that answer and I'll soon come to that question. But just want to know a background of the website in a way. What does the website do? Is it a publishing oriented? Is it an e-commerce? What is it? If you can give us a little bit of background and what was the implementing? And were you playing a role in advising? Were you playing a role in evaluating? Were you playing a role in implementing? OK, so I'll pick one of these. So these guys are essentially into selling digital courses around financial advices, or stock trading investment and those kinds of aspects. So that is their core selling product. Now, they obviously have a lot of content that drives their traffic in, content that is around the financial news, content that is around what's happening in the stock markets and then a lot of soft training kind of content that primarily would drive the funds that they have. Makes sense. Yeah, so now most of this traffic is essentially coming from news kind of destinations on mobile or search kind of destinations. So it is essentially that part of the traffic that we were looking at in terms of seeing whether we can increase what I should say, the share or the number of people who visit our site. My role there was primarily from helping in evaluating the effort versus benefit aspect of it. Because to understand the effort part of the equation, you need to know technically what you need to do to achieve whatever you're trying. And then there's their primary digital marketing team who's kind of trying to analyze the benefit aspect of it. Correct. Yeah, so that's the role to begin with that I was playing there. And later as we went ahead and took a call of doing an implementation or then the role changes into how would we minimize the effort and yet they get the biggest bang of the buck in terms of getting insights to begin with, whether this is benefiting us so on and so forth. And then obviously participating in the implementation cycle for AMP. So yeah, that was my role. Got it. So it looks like you've seen right from evaluating till to implementation to also seeing whether how much impact it has got. So you've seen a little bit of all of it. And a lot of, more importantly, a lot of if there are any pains later on, like six months a year down the line. Down the line. So how old is that implementation? This should be at least a year. About a year old. Okay. So I'll move on to Vimal. So what kind of work have you been involved in AMP so far? Yeah, so AMP, the first implementation of AMP we did is for a news portal. That was a time where all the news portals were adapting AMP and if you see in the web, almost everyone. So if it is a news portal, if it is a media portal, then this kind of a de facto standard that nobody should use AMP. Okay. Especially targeting the Google search and the news feeds. Okay. The Google, so earlier it was called Google feeds, right? And now it is renamed as Google Discover. So to get the content there in Google Discover, it is essential that there should be a valid AMP page. Again, without going into the motivation behind this. So if you can tell us what was your role and all in these projects, that will be a good point. So my role was primarily into whether we need to go with AMP or if we can, what are pages that need to be or what kind of pages that should use AMP. And how we should go with it. So luckily, so Drupal is the primary CMS we are using and is ready to use AMP module available. So it is a matter of using that and just doing the styles around it. But we came across many limitations during that implementation and we understand that. We'll discuss that in a bit. I'm sure. And other than the news, you said that was one now. Is there anything else you wanted to add to that? No, mostly. So we have not tried AMP in any other sites other than media, media related portal work. This Google Discover is something important. There's a critical bit over there. Okay. And how old are these implementations of yours? So I guess I started using AMP in say two years back or maybe before that. Yeah. About two years. The earlier versions of AMP itself, if we were actually implementing that. So this media portal for the early adopters of the app. Absolutely. Absolutely. Which brings me to the question that we have all been quickly jumping onto. What was the motivation to adopt it? And I'll start with you, Vimal, because you had started off in that flow and you had already mentioned Google Discover as well as the SEO benefit. But really, what was the conversation inside the room in the sense that everyone else is doing it so we should or were you in that set of people that, okay, there is this new opportunity. No one else is doing it. Let's be the early adopters. Yeah. So it was something kind of that. So as media portals, they always look around and what is happening there in the key players, right? So New York Times is someone who is always looking for. So they are one of the early adopters of many of these latest things and BBC. So these two are the examples that I use at that time. Whether we should go for AMP or whether we should spend this much time just implementing a separate code base. So the entire look and feel is already defined but implementing an AMP page which definitely require more time, right? So we need to create a new layout or new design that will fit within the AMP framework. So definitely it is a cost, added cost. So my first question was whether that added cost will be, is it possible to get benefits out of it? It's kind of, yes, so the things... What were the factors or the input did you have while taking the decision? Other than, so one thing I know that New York Times has done it, BBC has done it. And was there anything like they are seeing benefits or they are getting something out or our traffic is going down? What was the thing that prompted? That time the traffic going down was not an issue but now it is. So now we have not implemented AMP. There will clearly be a dip in the traffic on Google Discover. So most of the news portals leveraging on this Google Discover service to reach out to the people, right? So if you use an Android mobile phone or maybe I'm not sure about iPhone but Android definitely people are using this Google Discover service really. For the benefit of people who are not clear about Google Discover, can you quickly tell what is Google Discover as well? And who is it relevant for? So for users who Google Discover is a personalized push service based on your preference or your browsing pattern, Google will push content to your phone, right? So if you go to the Google app in your browser, you can see a Discover icon where you see all the latest content that is relevant to you. It is kind of a personalized push of content to you. All right, got it. So that is one. And only AMP pages make it to that or other non-AM pages also make it to that? But I am not very sure whether only AMP pages make it to it but definitely there's a preference. So if there is no AMP then chances that your content getting this Google Discover are pretty less. Okay, so other than Discover, you also said so one is Google Discover, one is other sites doing it and search, you had pointed out that people. So one more point, I just want to highlight one thing. It is not just about Google Discover, it is about how the page performs, right? So the Google Discover service, if they want to show some content, it should meet certain standards on a performance friend, I guess. So AMP, if you use AMP, that will provide you that advantage that now you do not have to worry about performance in other way. You just implement the AMP but you have to be within that AMP framework. So you do not have much flexibility around it but performance wise, it is kind of guaranteed. Guaranteed to you that the performance will be good. So Puneet, what was your motivation or the factors that you were considering? At the point of time, Puneet, you were taking a decision for should we actually start at Optic? Yeah, so one of the things that we were constantly observing at this plant of mine was that the mobile percent of the traffic was increasing every month compared to the desktop. So this is a relatively old site when the desktop used to dominate the internet traffic. So they were obviously month on month, they were seeing an increase in mobile but the bounds or users interaction matrices when you compare mobile versus desktop was really off. So I'm just, these are not actual numbers but if you would see a 40% bounce on desktop, the mobile would be somewhere in the 70s, that kind of large difference. Let's just explain what is bounce as well for us. It will be easy to understand for everyone. So it comes to your site, looks at the page but doesn't go to any other page and just moves on. Then you consider that user as a bounced user. So if 100 people come to your site and 70 of them do not go to any other page or whatever your objective is, then you can say your bounce rate is 70%. So one of the things that we were kind of focused on even before AMP was to try to reduce that bounce rate for mobile users because that percentage was obviously rising all along and not surprising. So that was one thing. And I peculiarly remember the head of digital marketing there who has access to their Google webmaster tool or the Google search console as it is called now, getting some sort of prompts about the discover traffic. So he essentially kind of had these initial curiosities. He said, I'm getting a lot of folks around us building for the discover traffic and things like that. And obviously we were kind of trying to solve this problem of trying to reduce the bounce so that one plus one and then he would go and look at the discover feed and see everyone's AMP there. So, hey, what exactly is this? And does started the exploration path of, can it bring us, can it help us achieve these two goals that we are kind of trying to do there? All right, so in your case, it was mostly mobile to reduce the bounce rate and Google discover and also to increase the amount of traffic in a way. And you got a hint that if you get AMP, then this, it might affect these metrics because in Google discover, you were seeing most AMP pages. And for the mobile bit, how did you draw the correlation that mobile traffic is going to get a positive impact whether through bounce or new users with AMP? How did you draw that correlation? We did not, to be honest. And that's where the big question was and thus we would go to the next part of how do we just try this out and validate that? So we were in an assumption world. Very validation oriented, but that's good. So about one or two years have passed between the two of you. So there are certain valid things that have been validated or invalidated which we can benefit from in our conversation. Yeah, I learned from other people's mistakes, right? So, or successes, yeah. So the next thing that I have on my list of things that I wanted to discuss beyond motivation is what are the practical benefits or advantages that you have actually observed? So I'll also remind the audience of three things that AMP kind of initially promised, has promised in a way as an AMP project that pages load slowly so your performance will be better. Experience feel unresponsive so that part can be tackled using AMP. Content gets unexpectedly shifting especially when ad loads coming in all and that's a bad user experience and that's something that can be impacted by AMP and all these things together will actually lead into a greater traffic or a greater set of users coming onto your site and overall give you business benefits. So my question, I'll start with Puneet in this case is are you actually observing these performance, responsiveness and as they say, user experience benefits by using AMP and is it actually giving you any positive business driving any positive metrics for the business as an impact of implementation of AMP? Okay. So in terms of the speed benefit for a real user we definitely see a speed benefit in a real user experience when the user is coming from AMP. So we are tracking it through all the analytics stuff and we want to kind of make sure that we kind of do a good comparison of what's happening here. So I would say yes, it does do well on the speed benefits that it kind of promises. There's no good doubts. What speed benefit is it like the back end, the server load or the page rendering? What part of it? We were primarily looking at improvement in our page loading experience matrices and that was our pain point, server side load or scalability. What tools were you using? Just if you can give us some hints. So this was custom CMS driven off all the ASP.NET No, no, no, for tools for measuring the measuring the speed and moments. So we have been measuring everything through analytics but we would write custom scripts to kind of be able to measure whatever. So there's this custom user measurement that you can do fairly comfortably with Google Analytics. So we would send our custom matrices for every hit and those kind of things. But yeah, so it was all through carry on, carry on. Carry on Google Analytics, okay. Yes, so in terms of speed, it definitely made our pages interactive a lot more earlier. It would show up our content a lot more earlier. There's no two doubts about it. In terms of engagement, we did not see a substantial difference between the two. And by between the two, I mean non-AMP versus AMP traffic that was coming. So we may have seen a very small uptake when it comes to AMP. We did not see the kind of numbers that I've seen in some of the case studies listed on the AMP side. So when you say engagement, you mean initial traffic as well as bounce. Is that right? So to be honest, what we were trying to track here is our CTS, like, you know, we wanted people to go to our, whatever landing page was, essentially. That was the goal of, you know, so we were, yeah, so we were very closely trying to track what percent of AMP traffic eventually reached Yeah, versus the other. But that's one step away, right? In my understanding, because AMP can only initially help, or at least from what they promise and all is like, the page which is actually rendered in AMP or which is actually built out in AMP, that page would most likely be pushed or given a higher emphasis by Google with whatever algorithms they're using and whatever preferences they're using. And therefore you'll get a higher share of traffic and whether you're able to convert that into a final thing or not, that's up to you. But did you see an increased number of visitors coming to the site because of AMP? Would that be a fair? Yes, we may have seen a small increase. Again, this wasn't a very massive increase. And like I said, we were already seeing a mobile versus desktop shift happening. So one of the challenges around analytics world is how do you objectively measure this increase or justify this increase, attribute this increase to something, right? There's always a number of things that are playing up all the time. For example, right now, right? COVID has affected a lot of what I should say, marketing matrices. Now there are a lot of experiments that you may be running. So we weren't able to clearly attribute the increase to AMP but we did see an increase in mobile traffic. But like I said, we were already seeing it happen even before AMP. And a quick question. Do you have both AMP and non-AMP versions of the pages? We have been maintaining both AMP and non-AMP. And was the ratio of traffic in AMP versus non-AMP? Do you have any idea about? I do not recall the exact numbers but the moment we had AMP, most of the mobile web was going to AMP. Got it. The moment you have AMP, most of the mobile was going to AMP. Okay. And that is because most of our mobile web traffic was coming from Google search. From Google search. Yeah. Eventually it boils down to that. So, right. So I'll move on to Avimal now, Avimal. So what are the practical advantages or the impact that you have observed in this? Were you seeing performance improvements? Were you seeing experience improvements? Are people giving more positive feedback after you have implemented AMP? And does it translate into positive numbers in business metrics or analytics? Yeah. So since we have implemented AMP when mostly news, news portals, I clearly see an impact were say if some, so occasionally the AMP validation errors occur, right? So in pages due to some additional tax or something added in the content. So whenever that happens, we clearly see a dip in traffic, say about 20, 25% immediately. And when we clear that issue and we again started serving the validated AMP content, we know the traffic went back to normal. So that clearly an indicator for us that AMP is really important for news portal. But that may be the case, but what we really want to give to the user is a very good experience, right? In mobile because everyone accessing websites through mobile. So most of the sites we are maintaining, about 90% of traffic is from mobile only. And so people access mobile in different conditions like the bandwidth might be limited. The device processing might not be that good. The graphics can be good or not, it may not be that good, right? But for providing a seamless experience for all these kinds of different devices is always a challenge. And if you want to implement or if you want to cater all these kinds of use cases, you have to put a lot of effort in optimizing your HTML, JavaScript, CSS and all. And I will say that putting that effort is definitely worth that because you can have full control of your site with whatever framework you are using. And at the same time, you build a site that is optimized for the end user. But when you consider cost as a factor, performance, whatever performance optimization we need to make, there is a cost implication, right? So not everyone can benchmark systems, not everyone can optimize code or write JavaScript that are optimized for the specific machine. So in that sense, AMP definitely provides an advantage. It provides a ready to use system which we can plug and play and get all these benefits immediately. On the implementation bit, I'll just jump into in a bit and I'll carry on from the things that you have just shared. But I do want to ask in the metrics that you just shared, that to me seems like a difference, 20, 25% immediate drop versus going back up seems to be born out of whether you are implementing AMP right, a valid AMP or an invalid AMP, right? That's what I connected to, that if the AMP is valid versus invalid, there can be a big jump in your traffic. But what about AMP versus HTML? Do you have both implementations? Yeah, so we have AMP page and the HTML page have a meta tag that is connecting to the corresponding AMP page, right? But both pages are available and both AMP and non-AMP will be getting traffic in a way. Only valid AMP pages get into the discover quickly, right? And only valid AMP pages will come up on the top of the search results. Got it, absolutely, yes. Also to me, it sounds like having a valid AMP page is a very challenging thing in itself because that seems like a very fixed factor. It was like only in the XML days, you would say valid HTML and all people have started forgetting because browsers have been correcting them so much. But that aside, any impact on, is it fair to say that when you're saying you're running a news portal, the revenue model is through ads? Yeah, okay, so if the revenue model is through ads, is that something that is getting a positive implication as a result of AMP? Or in my case, I have heard about and read about because of the restrictions of AMP that may or may not get and can also not get the actual benefit you are thinking. But though in user terms, you might get a benefit, the number of visitors. That is something that we definitely need to discuss because to implement an ad that ad provider should support AMP. So there is a specific AMP tag for ads and there's a set of ad providers. So if you are using a small ad provider or if you are using your own ad system for serving ads, which doesn't have a AMP support, then things will get a bit difficult because... But in your experience, what was the thing for the sites you were working in? Was it stable? Did it get better or did it get worse? It did get definitely better. So most of our cases, we use ad providers that support AMP. So that was not a big issue for us because only the revenue get going down if there is an invalid AMP page. That was the only problem we were facing. But definitely, if you check the website and the AMP version, the number of ads that they have in their website and the main page, non-AMP page and the AMP page, there is a significant difference. And from a user point of view, it is beneficial for the user because the pages are not cluttered with ads and all, but from a monetization point of view or from a business point of view, they want to make maximum out of the pages that they are serving. Yes. But there is some compromise need to be done, right? Right, absolutely. Absolutely get it. So I had two questions. I was thinking of flipping them over, but I'll continue in the same direction I had initially planned. I do want to know at this point of time, in what ways and because you were talking about restrictions on which ads you can put in or not. But largely, when you started implementing AMP and I want to separately take and the reason I got confused between the next two questions is I want to separately tackle two bits. One is what are the practical challenges in implementing AMP as what are the team structure changes you might have to do? What are the code-based changes you might have to do? What are the technical things that you might have to, hurdles you might have to overcome? And separately, and this is completely your own internal build process related changes that you are having to build. And separately, I want to also discuss in what ways does the AMP's own restriction, AMP frameworks on restriction affect either in content or in design or in technical kind of implementations. There is a slight overlap between the two because one feeds into the other, but I want to discuss both of them separately. So let me start with the second one first over here because you were pointing out in the ad, you have to go now selectively go for ad vendors or ad providers who support AMP. And you cannot go with any ad provider that you had earlier thought that they're giving you a better earnings or a better revenue. Aside from that restriction, what are the other restrictions that you have encountered in AMP which from the AMP framework point of view and not your own development workflow point of view? Yeah, so for me, it was kind of, so the restrictions are all for providing a better performance. So for me, so for a developer to build something on AMP need a more thoughtful creation of CSS and other components as well. So for example, if you have an interactive component on your page, which doesn't have a corresponding AMP component, you cannot use that, right? So if you have a flipbook kind of thing which you custom made specifically for your portal, which doesn't have an AMP component, then it will be kind of difficult to use the AMP framework by default, but you can- And the designer will be unhappy that I put in so much effort and now you are not carrying it forward. So the thing I should always think about what are the ready to use components available within AMP? And if you want to build something custom, there is definitely this AMP script is there, which you can use to build, but there are restrictions like you have to use web worker and you have to run that script in a sandbox or something of that sort. Also some things like, let me add a few things that I am aware of which might help you answer, things like limiting the CSS sizes, things like you can't allow third party JavaScripts to come in in certain cases. Then fonts, font related restrictions, which one you can load, how you can, you have to load it and things like that. Layout related, you need to know things prior to doing things. So some of these things, and there will be probably others, also in a way curtain the creativity slash developers or the technologists or the designers own thought process about how they want to go about doing things. So how about that? Did that actually impact things anyways? So the question is whether you want a performing page or you want the UI or the message that you want exactly in the way you want to put, right? So if you want to make that kind of write, you do not have to go to AMP. So I would say AMP is for those who do not have the budget to spend on performance. So when I say budget, it is very easy to create a performing page using AMP, but definitely there is the other side that you cannot implement all your designs within the AMP. So if you want to implement whatever way you want to build the site exactly like what the designer envisions in or how the brand guideline says, it is possible to do that, but you have to put additional effort optimizing the JavaScript you can. The rest of the code. The rest of everything, the CSS. Got it. Before going to Puneet, I'll also share that I'm running a little slow, but I don't see much Q and A. If people have any questions and all, please do send in. Then I will time myself accordingly. Otherwise we can slowly have this conversation and complicated by the end of the session. So anyone has questions, feel free to do send in. And then accordingly I'll get an idea about how fast do I have to take this conversation. So Puneet continue on the things that Vimal was saying, AMP framework puts in a lot of restrictions on you, on the design components, on the tech part of it that you can't put in more than a certain KBs of this. You can't put in any certain JavaScripts and all. Did that create a havoc internally while implementing AMP, Puneet? Yes, totally. And it kind of continues to create the havoc. It's my time to spend time. So like I said, to begin with one of the biggest challenges we saw was the restriction on the third parties. So to give you an example, we had a chatbot widget that integrated into our customer support from the site, right? People would chat and there was actually a support team who would work and the customer support team was well versed with this particular tool that we were using. Now, here comes AMP and says that we don't support this third party. We had some sort of analytics that I think was connected to their email conversion and those kinds of aspects whom to send an email, I don't know, X number of days after whatever. So suddenly, here comes AMP and says that we don't support this email provider and now how do you solve that part of the equation? So that was a much bigger challenge. We were constantly evaluating as a result of that effort or investment of effort into AMP was one thing, but so my point is the effort isn't just a technical implementation effort, but how about reorganizing these? Process efforts in the entire workflow of the organization. Yeah. Exactly. So that was a very big challenge and as a result, what we decided was that we'd kind of subset and start with a few of the pages and we'd kind of not do anything. We'll have them bare-bones. Just have the page to begin with and few of our CTS and that's about it and we'll kind of try to take it from there. That was one of the challenges. Second challenge was like you have been mentioning was around making our creatives understand what we're up to, image dimension. They were not habituated to have exactly the same dimension because we were trying to build this automatic workflow of assigning a fixed dimension and whatever because through this AMP transformation script that would pick up my CMS generated page and generate an AMP valid AMP page. So I now had to like list down a set of restrictions that folks working on the images or the styling or those kinds of aspects is concerned. Another thing that we observed is that once we had this in place and every now and then we would come up with newer campaign or newer thought process, theming, styling or some event that drives a lot of stuff that happens on our side. And now we would have to touch a lot of AMP things that can break a lot of things in the AMP ecosystem. So everyone would be scared. So kind of leave the AMP pages as is which also was risky knowing that most of our traffic or increasing amount of our traffic was now coming to AMP pages. Just for the mobiles, which is what you were starting out with. Exactly. So you're now in a catch 22 kind of a situation. Exactly, you get me, yeah. Yeah, right, right, right. It's interesting, it's a valid legit problem. And I think it's also a problem where I think the context it's great to have both of you because one is a media organization where the adoption, the published rate is very high and the larger amount of the articles and all are the product in a way. In your case, this is a marketing channel for you, the these AMP pages so that you can drive a different business altogether in a way and facing so different kind of challenges. So are there any other practical challenges in your workflows and all now maintaining two different versions and all did you consider AMP first which was something that was suggested by the AMP team member a couple of weeks back? Did you go through any of these things and what are the challenges now in maintaining two different things? Yeah, yeah, Puneet, Puneet start and then I'll go to women. Okay, so the reason, I mean, you can, so we are maintaining two versions of the site as we speak or two versions of at least a subset of our site where AMP is in place. And we did obviously think about going AMP only but it is scary, right? I mean, so AMP essentially is a restrictive framework. It comes in your way a lot of times when you implement it, you know, the nature of framework is not a plumbing framework or an enabling framework. It restricts you, tells, it gives you this guideline and the guideline can change. You do not control that guideline, you know? Yeah. So that makes it very risky from a strategic perspective to go AMP only. And that's what I wanted to respond to Nana that day but, you know, with due respect, so, but yeah, so that is the reason. That's why we have this session. Yeah, exactly. So our reason to not go AMP only has been exactly this that we would then be placing our faith into a body that we have no control over which is a scary preposition, you know? I'll give a counter-argument to this, counter-argument to this is that even HTML specs or JavaScript specs or CSS specs is something that we have no control over. Why do you have a problem with AMP? Like I said, it is a restrictive framework. JavaScript isn't, HTML isn't, right? AMP gives you this list of things that you cannot do. And yeah, I mean, JavaScript is freaky powerful, right? Yeah, yeah. Any workflow changes that you have had to do within the development of Dev workflow? We had, we've got this transformations kind of workflow, which is fairly automated now. Any tools you can suggest or share that you've been using to invent in both of them? We've built everything custom. We haven't used, because our CMS was primarily homegrown, the CMS, all the pages for this. You said ASP or something that. This is all that.net ecosystem, but everything was custom built. They were not used to. Sounds like a little bit of a tech debt, but technical debt. A lot, a lot of tech debt, yeah. Yeah, yeah, yeah. Okay, so Vimal, what are the practical challenges that you might be having from a development workflow point of view? Have you considered AMP first and AMP won't be kind of a way? No, not AMP fully, because now that will definitely restrict the options for the business, right? So they want to try out many things. Say for example, in the COVID period, they want to create a widget for the users that shows the number of cases and all. But if you are only AMP, then that may not be possible. We may not be possible to use that charting library, JavaScript library within the page. So that kind of restrictions prevent us going AMP first, but, and also maintaining two code bases are always a challenge, right? So whatever layout change or display change, or a new piece added to the structure of the content, you need to bring that again to the AMP. But luckily, in Drupal, this AMP theme is taking care of most of the things. So once we set out the layout and set out the initial design, Drupal will, this module will handle the rest. And so I guess the same is for WordPress as well. So WordPress, Google even supporting a module for WordPress, a plugin for WordPress, which creates AMP version of a page. So since we are using that and leveraging on that, I did not face a big tough challenge for this. All right, so in order to use some of these plugins and all do you have to already have to start with certain set of restricted things in your main page so that the translation is successful or no. And also I want to add and bring that point back. Is it because you're using a tool like this that often the AMP becomes invalidated because the tool is not that smart in doing things and then you constantly have to battle, okay, I make one change or no, the AMP got invalidated, fix that too. Is that something that you do? Yeah, so from a content ordering perspective, there are definitely some restrictions. So we use something called CK editor to add content, right? So the content order and the editorial team, the reporters and editorial team often use these tools and they try to put an eye frame from some place or they embed some non-supported JavaScript code within this HTML itself as part of the CK editor thing. That we cannot do anything on that, right? So whatever we put as content will come and it will make the AMP page invalid. So what we do is that this with Google webmaster tools and all it will provide a list of invalid AMP pages. And when these pages comes in, we go to the corresponding content and see what is wrong there and correct it. My personal viewpoint is rich text editors are evil and they are the ones that are causing half the developer headache as well as the fights between the content and the dev team. And yeah, if you could completely do away with the rich text editor, that would have been great. And yeah, absolutely. But I do want to have a future conversation on this on rich text editors because we have been trying to restrict, restrict, restrict options provided in rich text editor in sites that we are working on constantly. It is a negotiation between the teams and we want to justify it technically impact-wise and all. And probably in a subsequent conversation in a different session, I'll have people who can at least do a comparison between these editors as well because some of them spit out horrible markup eventually. So the HTML editors or the rich text editors aside, that is the biggest reason why AMP is becoming invalid in your case. So is it not possible to have a kind of a exclude list or a rather include list, whatever the case might be and filter out iframes and things like that from anything that comes out from there? Is that does that strategy work? That will definitely work. But no, but this some of the clients want to do all kinds of fancy stuff within the editor itself. Right, right. So it's more like a people negotiation problem. Yeah, yeah, yeah. So the HTML sanitizer or the HTML tools are already in place, but whenever we add certain restrictions, the editorial team come to us saying that no, they cannot, they want to do this in this phase and all. And we are kind of reluctant to add development effort. So whatever they want, they also not willing to put development effort. So what they are saying is that they want to do it their own. They do not want to make it as a development effort. They want to make this small change in the content itself. So got it, got it. Absolutely. So this is a very interesting conversation. And I think I would love to have this conversation at some other point of time because this is again the reason why Rich Tech's editors have come in and caused the entire challenge. But one of the points that you said that sometimes like during COVID time, they want to put out a widget or a banner, but it cannot go on AMP because AMP doesn't support it, but they will still want to do it. How do you resolve this? Because what my mind says that if a large portion of your traffic is now coming on AMP, their decisions are now restricted to the things that can be done within AMP because otherwise, any effort they put in putting out the widget is only going out to a subset of the users, maybe 20% of your users or 30% of your users. And 70% of your users are actually not getting that widget, which you consider as an important flash message at this point of time. So how do you deal with such situations? Yeah, so the primary objective of this widget is that anyone who visit the main page should see this. So through AMP. Why main page? What do you mean by main page? By main, I mean. By main, I understand non-AMP or is it home page? Yeah, home page. Yeah, I mean home page. Okay. Basically, kind of a branding initiative as well. Like, we are aware of the situation and we are providing, so it is kind of a statement that this media portal wants to provide not, so they do not want it for every different news articles they publish, but they definitely want, whoever comes to their home page should see this widget. That is what they have. So my point was that if we were fully AMP or we were only using AMP, that is not possible, right? All right, so there are some, one person's Kiran Srikumar is sending some comments or messages, but Kiran, just hold on with your thought for about five, seven minutes and then I'll try to bring you in as well. If you are there on, oh, it looks like he's not here on, but I'll pull out his point in a bit. He's not on Zoom right now, so he can't ask the question by many. So the thing that I want to move into now is the criticism around AMP, Google and the ecosystem around it. And I'll start out with, this is something that is, something that I feel strongly about as well, personally, that one is that AMP is not officially a Google-owned project at this point of time, but, and that is always the thing that you'll hear, but you really cannot disassociate it. If there are two guests in this panel, for both of them, Google has been the reason why AMP was adopted in the first place. And no one said Apple, no one said Facebook, no one said any other Amazon, nothing else. So if there's any company that has been named at this point of time as Google, and that has been the motivator. So you can't really disassociate it. So it is often the controversies around it or the criticism around it are that, A, it's such a Google project, Google pushes it, Google almost forces you to adopt it, because if you don't adopt it, the other person has adopted it, and they are getting a preferential treatment in certain ways, you don't own the server from where it is being sent out and all. It's almost a parallel standard that is being drawn out to HTML and a restrictive standard that is being drawn out to HTML. And yes, you are getting the front that has been put out, that is performance, user experience and all those things are, as people in the panel say that, yes, you are getting that, but you're also getting these things as losses in a way that the way Google forces you to use them in many ways. So what are your thoughts around that? So have you participated in these discourses and what are your viewpoints about it? Vimal, I'll start with you. Yeah. So what I see, I see this and their thing as a cost-effective solution, not something that promoted by Google, but as a cost-effective solution for publishers to create performance-ready pages, right? So there is no one preventing you to create pages that is performing well on all the browsers. And if you can do that, I don't think there is a problem. So even Google or any search engine will definitely take that into consideration. So if you do not have an AMP page, but your pages are fast enough and your pages are responsive and your pages serve your user purpose very well, then no one can stop us, right? But if you do not have that budget, if you want to make something performance-ready, but you do not have the time or money to invest into the finer details to how to do this, then AMP is a better solution. So you do not treat AMP pages as a solution that fits for all the different scenarios. And in our case, so where we especially deal with news portals, there is a question or a confusion or a kind of uncertainty here that almost all news providers are using AMP. And no, it is becoming, if I am not using AMP then there can be a problem. So I do not want to take that risk. I do not want to take that risk. Okay, so it almost sounds like a FOMO kind of a thing that is there and what Wimble says that if you can make something performance, then that is something that Google will anyways reward you. But I will also add that it's a pretty recent phenomena that they have very recently announced though, only in May or something like that around that month, that the top stories that also will actually allow the in the search result sites where that are not AMP but performing in a way, as long as you can meet these criteria, then we will start performing. Now, this is a recent change. It wasn't something that was there. And part of me believes that just because there has been so much criticism around and so much discourse around the restrictions of AMP and how strong holding like companies like Google and all have the power to almost dictate things on smaller businesses. And almost all, no matter New York Times and all of them, they are all significantly smaller businesses than Google. So they will be almost coerced into implementing it. If Google puts in such a big thing that look, the moment you do it, you are getting such a high spot on search. The moment you are doing it, we will make you, we will help your articles discovery through a Google Discover and all. So what do you think of these practices, Puneep? So my, here are my two cents on it. One, I believe that if you have a non-AMP page that let's say has a speed, whatever the speed thing may be of three seconds and an AMP version having the speed of three seconds, I think the AMP page scores a lot better. So I do not believe that a non-AMP version can, and maybe at a later discussion, we can go into the technical underline integrities of why I think so or what have the... Which score are you talking about? The speed speed score. So what score? I'm just saying any. You can use anything as a speed thing. You can say speed, page speed score or when it goes interactive, whatever. But what I'm saying, when you have a speed of X for an AMP version and a non-AMP version, the same speed, I believe the AMP version will always score better in terms of getting higher traffic from Google. Right, because Google has a preferential treatment to AMP. Yeah, yeah. Is that true? So is that a myth or is it true? Yeah, it is true. In public places, they always say that, all it matters is your content and how the page performs for the user, right? I agree. So they publicly stated that AMP is not a ranking factor and speed is, and in that way, they actually are indirectly saying, because they pre-cache all the AMP pages. So when you search something, your AMP page is already cached and it will open a lot faster than your non-regular page, even if that one is faster. So I personally, on my side, have AMP for a lot of experiments and I cannot do this with clients, but I can do a lot of perf experiments on and I've tried to see what happens when I implement an AMP page, what speed comes up, does it get more hits versus the other one, those kinds of things. I will though add that Google officially says that AMP will get preferential treatment in certain ways, like the top stories carousel until now and even until the next set of benefits come in. So even if you have a parity in performance, AMP gets a preferential treatment in where on mobile results, mobile search results and what order they are being shown. So while they might not consider it as a ranking signal in a way, they may or they may not anyways, we don't know all what all the ranking signals are. What is evident is that in this outcome or in the output, it's just like Google will first show us a Google ad first before an organic search result. Similarly, and obviously that by that, you can imply ad gets a preferential treatment because Google has to make money out of it than organic search result. You can almost all make that extension that if AMP results are getting a preferential treatment over organic search results, then that also is a clear preferential treatment, right? Yeah, yeah. So I do believe like you said, Google does give a preferential treatment if you have two-page ZAMP and non-AMP exactly the same speed. So let's keep this aside for a moment. Now, once you know that, let's say all your competitors are going out and implementing AMP. Hasn't happened for my clients. I don't have media publishing businesses like Vimal has, but let's pick Vimal's client here. If eight out of 10 of his competitors are now on AMP, he probably has no choice, but to, his client has no choice, but to go for an AMP implementation. So I see that as one aspect and my experience with AMP has been, it brings on this additional maintenance cost. Every time we change the layout, every time we bring in like he was mentioning the COVID thing. Now, we've had this conversation, do we want to do this in only our regular pages or always, you know, also on the AMP one? Okay, so what would happen if we do on AMP? What would break? What, who needs to be notified and so on and so forth? You know, so I have seen that more as an additional cost. So what I believe, you know, what has been my understanding with AMP's preferential treatment, is that it has now added this additional cost and effort to get the similar kind of growth that we were getting before that. Okay, this is interesting. I'll move on to the next point, which are, which is around alternate solutions to AMP. Can, is AMP the only way out in whatever benefits it is giving it? But one of the things I want to highlight about this cost factor, because Wimble is also talking about cost and you're also talking about cost into different, slightly different ways, in my opinion. Wimble is talking about the cost that AMP saves cost. Why does it save cost? Because if the alternate is, if you have to do so many performance optimizations and all on your own site, that will be a lot of technical manpower cost in a way. And that is, if you just slap on AMP to it, you get a lot of benefits for a lot less effort, and therefore the project cost less effort. You're talking about the cost in exactly the opposite way. I just want to highlight this clearly, that if you have AMP, then now you're maintaining two different code bases, and that is going to increase the amount of effort that you're having to put in this. But largely what Wimble also said that if you have information publishing kind of a site and you are using one of these tools that automatically translate as, and you are awake during the nights to keep checking for validation errors that how the content has come in, then the effort is not that much higher. That's what Wimble is arguing for. But if I look at the alternate approaches, I feel this one of this main cost thing and why this entire baggage of AMP exists is it's almost like a cure. It's almost like this tablet. Instead of saying that, hey, you don't have to exercise every day. Look, you can be lazy, you can be on the couch, just pop in the spill. Now, there is a side effect to the spill as well, and that is obviously not being advertised as much. But is it true to say that exercising is something that can should be considered as a minimum hygiene level, or what is the minimum hygiene level? What is the minimum hygiene standard of work that should be put in? From where the benchmark, you have to say that this is extra work or this is a work that we are not having to do in the sense that some of the things that AMP provides are intelligent resource loading, pre-loading, and pre-rendering. These are things that I'm taking from what the talk had come in two weeks back. Non-blocking code, deferred layouts, chunk processing, sandboxing, everything else, which is what that means is you should not, any external JavaScript you're loading or anything external resources you're loading. It should not come in between or block your rendering of the page. Efficient font loading, addressing server times, pre-rendering certain things and all. They are all strategies and techniques that have been involved in the last, say in the last 10 years or so. Let me put it that way. But that is how things are. Baseline strategies are always increasing. And as developers, these are things that I would say, even if you're not going the AMP route, your basic HTML route or a basic implementation route should fulfill these bits. So what are your thoughts about this, Puneet? Do you think that, am I right in making this argument? Because I also add a few articles that I've read, wherein the bottom line that it has come down to is that in case AMP would not pre-load the next set of pages that you want to load and pre-load resources, and had it not been served from really high-speed Google CDNs, which it's very hard to beat the quality of Google pre-CAS CDNs, every other tech improvements that they have put in are a part of standard practices and even other projects are taking in like Gatsby. Like other technologies are also applying it. So what are your thoughts around this, Puneet? Is AMP the only solution to performance and only solution to the things that they are talking about? Or do you feel that there are alternate solutions that are viable as well? I completely believe that there are solutions that would actually give you performance better than AMP. And the reason I believe this is AMP is primarily JavaScript-based, okay. And while I work with a lot of React, Next.js and those kinds of projects, I still am a guy who believes in having as less a JavaScript as possible, because we all know that the best performance is where you have as less of the baggage as can possibly exist. I can share pages where you will have an AMP in a regular page and you'll see the page speed score of the regular page higher than that version. Yeah, yeah. I have no two doubts in my head that when you minus all the pre-CASing and pre-rendering that Google's infrastructure brings in, you can build pages that are faster. That stated, performance by its nature needs you to pick all the boxes. And the moment you kind of falter on even one of those, it kind of spoils the house, you know, which is a real problem and that's the prohibitive nature of AMP. So I understand from where Google is coming or AMP is coming in being prohibitive. And this happens with me. I work with a lot of sites where we improve the performance and a month later someone messes up something and the speed score go for Hivaya. That happens because you need everything to work when it comes to it. So it is difficult. It is challenging. I agree, but it is achievable. What's worrying? I'll just add one last bit. What's worrying? Is the additional benefit that Google offers to AMP and not to an equally faster regular page? Right, it's two different equals in a way the inequality between the two things. So Vimal, just want you to pitch in on this point as well. Like one of the statements that I have read from another article that I had read just 10 minutes before this session, by the way. Don't tell anyone. That AMP performs as good as a non-horrible web page. What that article is trying to say is that only if you horribly code your web page and by obviously they're taking the benchmark, picking it up and they're saying these are the things that you should obviously do. These are the things that makes code non-horrible into 2020 in HTML. If you are making a website page that is non-horrible, then AMP probably performs as good as that, except that preloading and the Google cache bit. That's the caveat that adds. So Vimal, what are your thoughts about that? Do you think that that can be a benchmark for other sites anyways and not go for AMP? Are there alternate solutions available? So my point is that definitely AMP makes developers lazy and they think that they do not want to take care of the standard practices they should follow. So I would argue that everyone should follow the standard processes and if they treat the end user who consumes the content, consume the bit first, then they should be right code in such a way that is acceptable for the end consumer. So whoever use the page should get the best experience they can. So that is the whole point. So this AMP provides an abstraction layer on top of the HTML with automate many of these stuff. But at what cost? At does it come at a cost where all other, like Google's own browsers or Google's own set of infrastructure are not the only thing that consume your pages. There are so many other things that try to consume your pages following the HTML standard. Sometimes it might be just even a reading experience improver like readability and all would actually care about whether you have HTML on the page and whether I'm able to read it. Of course they have to now also start supporting AMP as an alternate standard. So it comes at a cost, right women? If you take this abstraction layer. This AMP essentially renders it as HTML itself, right? So it is a JavaScript that automatically identify the largest contentful, largest piece of content that should be rendered within the view space. And it will make sure that your first input delay is minimal and there is no cumulative lay or sheets and all by providing certain restrictions, right? So what I say that it is like using a stencil to draw. So I can use my pen directly to draw something. And if I use a stencil, there is a restriction, right? I can only use the certain parts to draw this. But an artist who creates something can use pen better than a stencil. But if someone who is not an artist and want to create something can use a stencil. So I absolutely love this analogy that you just given. Go ahead, you want to complete the point? Yeah, so what I'm saying is that I see AMP just as a pool that just installing AMP will give you this much performance. So if I have a WordPress site or a Drupal site and I want my content is my primary thing and I do not care about how it, I do not have much concern on the design, the layouts, the elements and all, but I want to publish my content and the end user should be able to consume that content faster. Then definitely AMP is a way, but if you have, if you need flexibility, if you want to do innovation of your own, if you want to try out new strategies for monetization, you want to build more functionalities on this thing, then you should definitely invest on improving the performance of whatever framework technology you use. There is no other way for it. I do ready to use solution, that's all. I do want to pitch in with a couple of points in this, which I have as a partly a counter argument in this that I completely agree that this is like a stencil and stencils are good. Provided you choose which stencil you want, you go and buy it yourself and so in case you actually read through AMP specs and adopt the restrictions that AMP is suggesting in your own markup, that I won't write more than a certain amount of CSS, I won't write a more than a certain amount of JS, I will only treat JS in a deferred manner or a async manner external JS. Those restrictions, if you can self-impose in your basic web page, that will always give you a performance and where I say that one of the differences is even though AMP actually renders as an HTML, it renders an HTML because a JavaScript library has to run through it, otherwise it will not run as a, so if there are alternate systems consuming this piece of content, other than something that can actually run a JavaScript in it, then you're not getting, then the HTML framework basically or the HTML standard is much more widely accepted. So if you're doing a content syndication as an example, which is also something that you will be doing, which is if you're passing on thing to talking between two different systems. Now, do you start talking in AMP only or existing systems will talk in HTML, right? So the same problem exists in all the JavaScript frameworks, unless you render it in the back end, the same problem is there. So if you use React or Angular or any, the same problem. Absolutely agree with, absolutely. So when you're going web component-based things and then using that to render, and I kind of lie in Puneet's boat in the thing that use as little JavaScript as you can get away with in any system that you're trying to do it, but I know that there's an alternate approach also available and I'm not competing against that in any way, but this is a frame of mind or this is a philosophy that is there. One final thing that I have, and I just take five, seven minutes before I close this, the last question is, is it worth it for me? Is it worth implementing AMP? What is your closing thoughts? Because I did do a quick search on this thing as well and there are, there are question marks that are being raised even at this point of time as Google starts opening it up more. The reason, why did all these organizations have to adopt it? Because Google gave a preferential statement to AMP in the top stories Carousel and what? Now, in May, they announced that if you can meet these benchmarks then we'd allow your non-AMP pages to also come up there. That means they're trying to make the field a little bit more level. Do you feel if they actually made the field level or it's already in the path of getting a little bit more level playing field, do you think that the AMP project will survive long? Is that something that you feel that will happen, Vimal? And therefore, is it worth investing in it? And if yes, I'll combine this with the question of the comment that Kiran Kumar had made, the thing that I had said. Is it set, can we discuss on case studies where AMP has been used and why? In the thing, I'll turn that, we already discussed a little bit, but I'll turn that around and say that in what kind of projects or in what kind of websites would you consider it is worth it and in what kind of considerations you will say it's not worth it. So Vimal. Yeah, so my point is that there is no solution that fits for every bucket, right? Every kind of problem, it is not like that. So in my case, it is media portal, media portals where I see the most of the AMP use cases are and I definitely think that is worth using AMP because it by default will provide you an advantage because your main product is your content, right? And without worrying about performance optimization by your own, you just worry about how to structure the content and how to create content rather than building an infrastructure or putting more effort on optimizing specific aspect of this thing and AMP will affect all these things and it will provide you something better. And I am always an advocate of this open web where everyone should have an equal right, right? So if I can build something that can provide the same performance as AMP can provide, then no one should distinct between these two things or two technologies, right? So these two things should be treated equally. So if Google says that they have a preference for AMP rather than not saying that performance is matters and AMP can give you more better performance or use AMP, then I have a problem. So if Google is saying that you should use AMP to get in a certain place in Google, then definitely there is a problem. But if they are saying that performance and the user experience is that matters, if you come up with something that provides the same performance as AMP, then we will treat you both same. Then there is no issue. And I clearly see there is a definite future for AMP because it can reduce the cost in a very multitude in order, right? So if you include a person to optimize your JavaScript or if you get a very senior JavaScript developer, so JavaScript is a new thing. And it is kind of difficult. So with all this browser API and there is a lot of things that you need to, so there's rendering engine layout, how the browser manages layout, how the browser loads. So there is a lot of things to learn, right? And these are changing every day. So new browsers come in, new versions of browser come in with new technologies that can use hardware to optimize what you render and all, right? So for a JavaScript developer, it is a tough time now, I would say. Right, right, right. They need to constantly learn new things, what is happening in there, otherwise they will fall far behind. And some team, some dedicated team is working on something that will handle all these things. Why can't we use it? That's my point. That's a good valid point. And you are saying that media business is where you feel that there's a lot of scope of using something like AMP. Any other industry or any other use cases you want to flag out here that you feel that play along nicely with them? No, anything that is content oriented. Anything content oriented? Anything content oriented. I am not sure about e-commerce or a purchase workflow, but the e-commerce, so nowadays content and commerce always gel together, right? So there is no just product display and card system, but content around it. So if you want to create a blog or a recipe site or a whatever additional related content site around your e-commerce portal, that can definitely support this thing, the AMP. Right, but I'm not very sure about the product display or the product. You are more or less hopeful that AMP will survive, or you are more or less a little positive about or more confident that AMP is something that will most likely survive and you would be willing to invest in it, right? Yeah, but the other thing, Google and... What is Google's behavior of how to treatment of AMP? That's the point that I have also recorded. So I'll summarize it at the end. So, Puneet, is it worth it for... And for what purposes and use cases, would you say it's worth it? So content, obviously. And whenever we get into this sort of discussion with the client, we tend to try to look at what are the competitors doing when you try to search for the kind of content that works for that site. Are those guys AMP? What kind of content this is? I believe a lot of social-like content works well with Discover. So that's an additional stream. So now this is one aspect of what is the benefit? So anyone who's doing content more of socially in nature and when you look at competitors, are they on AMP? Then there's probably no escape out. So that is one aspect. Second aspect I would tend to look at is what is the investment or effort if you just want to start experimenting. Like Vimal said, you have a very standardized CMS system where there are plugins available, then it's relatively a low effort thing that you can probably at least try out. But for some of the folks where I worked where it was a custom CMS and you had to write everything from the bottom up. So then you consider that effort part in the equation and kind of take a call. But probably everywhere where we tend to do it, we tend to begin with smaller experiments to see what happens. And then gradually decide on larger investment. And are you hopeful that the project will stick around? I hope it would not, but I believe it will. Okay, so let me summarize what Vimal and Puneet just said for as a part of the closure of this conversation which is very nice. AMP is just a tool. It's just a tool for you to be able to implement certain good performance features and user experience features. So if you consider it that way, that's a good way of looking at AMP. And there are obviously alternate tools available for you to get the same objective. If you are using sites for publishing content or even marketing content or anything around that, over there it makes sense to consider AMP as one of the tools under your arsenal to be doing it. You also might have to look at competitors. Are they doing it or not? Because if someone else is doing it, there's a very good chance that they are getting some return out of it. And one of the reasons they might be getting return out of it is because how at this point of time, Google is treating it in a way which we just discussed some of them are preferential. But then also need to take a look at the investment and the effort involved in going to this because once you get into it, you either get a tool which automatically converts and yes, because of certain workflow reasons, you might be constantly getting in variations and this and that. And Google is very strict with AMP, which I have also read about that if there is no parity between the content that AMP has and the content that the main page has, then also Google complains. Google wants equal content between the two as well. So there is going to be an investment and an effort either, whether you are using automatic translations or whether you are lying on the system with a lot of technical data and implementing hand coding it yourself, either which ways there will be a lot of effort. As far as long-term prospects go, what I hear is that there's a belief that it will carry on, but there is also at least some of us over here hope that it doesn't. And one of the reason I say that is because while Vimal did highlight that the motivation stated by Google is good, that it's there for delivering a good performance, it's delivering a good user experience and so on and so forth. We also know in the recent hearings by all the big corporates, what kind of reasons they give in order to save their back and grow their own businesses to get out of it. So with that understanding, I always realize that, obviously Google has it's has is seeing the benefit in controlling this aspect. If enough people can be lobbied into taking this route, then Google has an edge over some of the other organizations in how the web for the future can be shaped in a way. That's how I see it. And therefore with that caveat I would buy a suggestion would be simply to just simply think before you leap and look at all the other alternatives that are there. I hope that's a reasonable summary and includes all your points. So any closing thoughts Puneet? No, this was nice. I think you covered it fairly well and it was interesting to also learn Vimal's perspective and I think it matters for someone like me who's been working on very custom tools. So yeah, very helpful, very nice. All right, thanks Vimal. Any closing thoughts? Nothing, so you did it very well, Savik and Puneet also thank you for your input. So that definitely matters. All right, so thanks a lot everyone. Thanks a lot especially to Puneet and Vimal for coming in. Saturday mornings are not an easy thing for anyone and thanks to also people who have joined in and people in the future will be seeing the video as well. So for watching this conversation. And also thanks to Hasik for giving us the space to be having these conversations. So before I close this conversation, I just want to say that in the future, we are going to have some sessions and newsletters. We are planning certain sessions on designing and we are starting off with the design. As I said first, that we are going to have more content oriented conversations and design. We are trying to schedule in the later part of September conversations on design, specifically how to demystify a web design as a space because it's really difficult often for designers to coming from a print or a non-digital background to be working in the fluid environment of a web and the several set of things that you need to consider over there. So we'll be starting off with sessions around that around in the month of September and in the early September, we are also going to have a session. We are planning a session where we look at breaking down performance using the web page test tool and how it breaks down performance and understand that bit taking one website as an example. And that will be a lot of performance oriented understanding as well, which would in a way explain also why AMP is performing well, why is it giving such restrictions and what kind of advantages AMP has, how can you adopt it in without adopting AMP itself in a way should give insights into that. Also having conversations about security e-commerce and things like that and hopefully those will be lined up soon. If any of you want to propose, want to hear about any new topics around web design, web development, content web in the larger umbrella of topics, please send in a proposal on hasgeek.com slash content web. You can also request for a session and then we can try to find out using our network, people who have actually worked on those using those technologies to be able to come in and have these conversations like that. With that, I'll just end with another thank you. Thank you, Puneet. Thank you, Vimal. It was great and it was a pleasure having you. Thank you. Thanks a lot. Bye-bye. All right, bye. Take care.