What are your thoughts on Accelerated Mobile Pages (AMP)?

AMP is one of the worst Google projects to date. It's anti-web, anti-publisher, and serves no one but Google and its shareholders. Essentially, what Google is saying is that we're all too stupid to figure out how to make a fast, mobile-friendly website. Thankfully, they're kind enough to do it for us.

Thanks but no thanks Google. 🙄

I'm of fairly mixed opinion. It can be worthwhile for performance and limitation of external assets (scripts, making ads behave) and certainly makes for a content-centric page with fast page load times, but it can sure be fiddly.

Three months ago I switched my blog's format to one that implements a lightly modified version of Amplify for Jekyll. It took a while with a surprising amount of migrating data (there's always something that got missed) and reimplementing anything remotely JavaScript related into some godawful iframe based hacks; Disqus comments and gist embeds, for example. I still will never have my site 100% AMP compliant, as I want to keep a search page, which I'm not going to bother putting through an iframe hack.

On the upside, I've got an incredibly fast blog format, which makes use of virtually no JavaScript, making for an immensely fast page load. My site can load from the Google AMP CDN if it's clicked on from a mobile device via Google search result, but otherwise my page loads natively from GitHub Pages and has no redirects to the CDN version, as I went in whole-hog. The focus is the content and that's what any readers get. I also don't see the banner at the top of my pages, including when loaded from the AMP Project CDN on mobile; at least, not when navigating directly (cdn.ampproject.org/c/s/my.com, versus loading from a Google search result will display it, from google.com/amp/...).

The performance is clearly better, but Google clearly made a series of decisions that benefitted them over either publishers or users - e.g. the lack of a simple "Go to the HTML version" link for each article, the automated hosting in Google's CDN, the type of analytics included, adverts supported, etc.

As a user, when I click on a link and it loads quickly and it's clean, that's great, but then when I try and share that link and realise it's sharing the AMP version, then I get pretty annoyed...

I still do most of my reading through RSS feeds, call me old fashioned.

When I encounter an AMP page, there's just something that feels off about them. That they show differently in search results cheapens the content to a degree. Not to mention the lack of publisher-owned branding. Recognizable type faces, colors, and logos are the strongest indicators of the reliability of the author/content, and you lose a lot of that.

Here's a video from an event I went to last year where Calvin French-Owen, the co-founder of Segment, gives a good primer on AMP pages. It's pretty clear why they exist, but a common refrain is to just make your own site not suck. heavybit.com/library/blog/get-ampd...

I don't like AMPs.
I like sites that use a minimum of connections and bandwidth, tho.

AMP is just another way for Google to sneak in more analytics, by requiring people who adhere to the AMP standard to include files hosted on Googles servers.

You can properly optimize for mobile use without having to resort to AMP.

I am sensing a strong correlation between "fake news" clickbait and AMP.

Most annoyingly from a user perspective, pages that don't open in the browser, but inside a Webview in the Twitter or Facebook app do not get the benefits of the Android Share button, so adding an article to Pocket for example is now six taps instead of two.

I really dislike them and wish there was an opt-out. They're well implemented, I just prefer the original experience. What's frustrating is I can't figure out how to get to the original article. At least with Facebook's implementation I can "Open in Safari"

Mostly I'm just confused about what they are. They seem to be a variation of HTML with weird tag things? But they don't appear to be hosted on people's sites, instead just being shown through a page on Google...

I see less ads, that's for sure. But sometimes I don't think I'm browsing content from that site, loses the feeling of the original site. It's a compromise in a lot of ways, a good one I suppose. The implementation is good, and it does make browsing seems more fluid, a lot more fluid.

You can read the discussion about AMP strategy for Wikimedia (Wikipedia and friends) at phabricator.wikimedia.org/T124243.

wicg.github.io/ContentPerformanceP... seems a much more interesting solution to the problem!

I was enthusiastic about AMP at first, as a constraint on the bloated web, but Google's implementation of it within their results is both bad for user experience and bad for the open web. If it were one or the other, I could see the merit in the tradeoff, but it's both.

The current state of the user experience could be a nitpick, but the intrusive banner, the lack of user navigation and sharing options, and the general lack of context just kill it for me. Ordinary users might not notice or complain, but their web browsing experience is definitely stifled.

Google just needed to penalize pages that offered bloated, bad experiences. That would have aligned everyones' interests. Especially mine, because dev.to is fast af.

As a concept, it's a great idea - there is far too much bloat on the internet. However, newer sites (the ones which are supporting AMP, in general) are usually built the "right" way in the first place. In other words, designed to be lightweight.

There are some obvious problems with it but a couple of my favourite ones are that there is no ad support (AFAIK) which means loss of revenue for content providers, analytics is a pain, and all AMP pages look the same! They may as well have just done a spec for a JSON feed, just like RSS.

Having to add a proprietary Javascript to my website in order to support AMP will never have me add AMP to my websites.