Wow, I'm still learning the basics of HTML but holy moly that looks obnoxious to implement.

Great article, clears some of the things theampproject doesn't tell straighout forward, like you cannot use javascript, tracking has a very limited support.

The proposed change in AMP URL scheme is a good move in terms of the website’s security. So far so good....Now many publishers have already started using AMP. Hope other sectors will also started using it more.

Hello Barry Pollard! In case you haven't heard, Disqus is now compatible with Google AMP. You can learn more on the Disqus blog: https://blog.disqus.com/dis...

-Adam from Disqus

Yup saw (and tweeted!) that but not had a chance to try it out yet.

Still a bit of a pain having to set up separate domain so think saying it's "compatible with Google AMP" is a bit if a push! Would be nicer if there was an amp-disqus tag so it was natively supported.

Think that wiki page could do with further info on what the hashes are. Don't really get those - though as I say not spent any time on this. Is it possible to show all these comments on the AMP version of this page for example so you see same comments on both AMP and non-AMP versions?

Thanks for the feedback! I’m not necessarily the go-to-expert on Google AMP at Disqus, so I’m channeling one of my teammates to try to answer your questions:

While we’re not actively working on a dedicated amp-disqus tag, we are exploring ways to improve the amp-iframe integration to make it easier to integrate. One way we might do this is by hosting the embed on our own domain, so all you would have to include is the amp-iframe tag. As far as the “hash” part of the instructions go, I agree that we could make that more clear, so we already have: https://github.com/disqus/d.... And to answer your last question, it is indeed possible to load the same exact Disqus thread across different URLs (AMP and non-AMP). You can achieve this by specifying the same identifier variable using that hash in the src of your iframe URL.

Would you mind if my teammate emails you directly at barry@tunetheweb.com? We’re planning on writing a piece on some performance optimizations that we’ve recently completed. We would love your feedback before it goes live!

Hi Adam, finally made some time to get this working (and now replying via my AMP page so let's see if this works!). It wasn't the easiest to do and still don't think the instructions are as clear as they could be (and consider myself pretty technically able). I've left my feedback here: https://github.com/disqus/d... if you want to pass that on. I never heard from your colleague btw or might have asked them for help directly, but also satisfying to figure it out myself :-)

Thanks for quick follow up! Will definitely make some time to try to implement it on this site now. And absolutely have your colleague email me directly.

I also don't like the direction things are going in with the AMP project. Google have suggested that sites can have standard HTML pages and AMP pages alongside each other. One of the problems with this is that each page will need a separate URL. Serving essentially the same content from different URLs completely flies in the face of the principles of responsive design. As you point out, most of the speed benefits of AMP could simply be obtained by optimising the standard HTML pages better, and without most of the restrictions of AMP. Overall, the AMP project seems poorly conceived and driven more by commercial considerations than by a desire to help end users.

I'm actually coming round to it a bit more. On a technical level I don't like it - for the reasons given above - but there's no doubt the impact: articles are now quicker to load. The publishing industry needed this kick as just "being able to" apply these performance techniques was not working as they were not prioritised. When Google shouts people listen. However I do hope the forcing of AMP on people is a short term phase that we move on from - like "mobilegeddon" - where the extra visibility in search results is now no longer necessary only a year after introducing them (https://webmasters.googlebl.... AMP is actually a very good framework and fine with it continuing - it just shouldn't be a framework FORCED on website owners to benefit from extra UX in Google's results and tools.

The performance gains are impressive. I just find it horrible we are forced to use two different URLs for what is essentially a single resource. Also, some webmasters have put a lot of effort into optimising their standard HTML pages, and I don't believe they should be penalised if they choose not to adopt AMP. Overall, I feel there should have been a better way of bringing about faster-loading pages.

Agree. My point is most webmasters have not optimised - or have been overruled by other people insisting to add loads of junk. AMP doesn't allow junk so as a way of forcing people to concentrate on performance it's working. I don't like it on principal, I don't think it should be necessary - but the results speak for themselves. It is working. And for that reason I'm starting to change my mind on it.

"No menu - despite it being CSS only. I use this Pure CSS Off-Screen Menu code for my "hamburger" menu drop down in mobile view. Unfortunately it uses a little hack with a checkbox to work and, as per above point, AMP does not allow forms or input tags. So the menu - which is only useful in mobile view does not work in mobile view :-( A request for menu support has been raised, but for now will have to live without it."

Excuse my French but this is bulls**t I don't have any time to figure out silly new rules. You can't use a javascript mobile menu or a CSS menu. This seems really silly to me.