For further actions, you may consider blocking this person and/or reporting abuse
Read next
Why "AI" is the new "sustainable"
Ingo Steinke, web developer -
The Rise of Rust in Cybersecurity: What You Need to Know
Bek Brace -
Did You Know? Prometheus Supports Multi-Target Scraping with One Exporter!
Oliver Bennet -
The quest for a robust and scalable storage solution for home use.
Bharat -
Top comments (15)
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, fromgoogle.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 have seen this sort of criticism throughout discussions on the web, but have yet to come across a response from Google about any of it. Do we have any idea if they plan to modify the service in any way?
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 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.
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...
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!