The subject of AMP came up at a meetup I was at the other day. It came up in a “Hey have y’all seen this thing yet?” context. Some people have heard of it, some hadn’t. Even among those who had heard of it, the vibe was mostly: “this is newfangled tech. It’s the future, probably. I guess it’s a thing I gotta learn, I just haven’t gotten around to it yet.” Which makes sense. It’s just like hearing about some new JavaScript framework that is taking off. “Obviously, it’s a big deal, I just haven’t gotten there yet. Perhaps I will one day when it’s clear I need to for a project.”
Other folks at the meetup were like “Isn’t it that thing that makes it so you can’t use CSS or JavaScript?” Someone else thought it was more like a CMS. Neither is quite true, but there is certainly plenty of confusion out there (and a lot of outright shrugs). Let’s not re-explain what AMP is here, but cover some of the potentially confusing and controversial points.
Is this a Google thing? Or…?
That’s something the site doesn’t make particularly clear. It’s technically an open source project with a variety of contributors and partners, but… it’s a Google thing. Google employees work on it. Google threw the recent conference. Google hosts the required JavaScript file at the top of all AMP pages. Google hosts the cache that makes up 1/3 of what AMP “is”. The whole point of AMP is having Google show your AMP page in the coveted SERP carousel.
Here’s a succinct explanation of the three parts, from Jeremy Keith, controversial bits included:
- The AMP format. A bunch of web components. For instance, instead of using an
img
element on an AMP page, you use anamp-img
element instead.- The AMP rules. There’s one JavaScript file, hosted on Google’s servers, that turns those web components from
span
s into working elements. No other JavaScript is allowed. All your styles must be in astyle
element instead of an external file, and there’s a limit on what you can do with those styles.- The AMP cache. The source of most confusion—and even downright enmity—this is what’s behind the fact that when you launch an AMP result from Google search, you don’t go to another website. You see Google’s cached copy of the page instead of the original.
The AMP site doesn’t disagree and is equally clear.
Your website becomes https://google.com/yourwebsite.com
In a way, anyway. Unless you do something really unusual like Paul Bakaus has done and make your entire website AMP, the only way you end up on an AMP page is when you’re:
- On mobile
- Click an AMP result in a Google Search
And when you do that, the URL you land on starts with https://google.com. You bookmark that, you share that, you email it to yourself, whatever, it’s a Google URL. Kinda weird. Confuses plenty of people. There is a way to “Request Desktop Site”, but meh.
John Gruber found it particularly weird:
If I tap the result, I get the AMP version of the Ars article, served from Google’s domain. So far, I get it. But the kicker is that I don’t see any way to get from the AMP page Google is serving to the canonical version of the article on Ars’s website. Even if I share the article, what gets shared is the google.com URL. On desktop browsers, these URLs do get redirected to Ars’s website. But on mobile they don’t. Share from one mobile device to another and nobody ever leaves google.com. Why would any website turn their entire mobile audience — a majority share of their total audience, for many sites today — over to Google?
It makes no sense to me.
Makes no sense in a why would any publisher do this on purpose?, kinda way.
They way I thought of it, at first, was that it’s just another publishing format. Just another RSS. This latest round of publishing formats is Facebook Instant Articles, Apple News, and AMP. There will be more. I said:
Hey, whatever you want. As long as…
- It’s not very much work
- The content’s canonical home is my website
I just want people to read and like CSS-Tricks. Ideally, I can monetize on (good, curated) sponsored content that makes its way to all these channels anyway.
Which I still think, for the most part. The strategy is: go where the readers are, which makes sense.
Follow up from Gruber:
The lock-in aspect makes no sense to me. Why would I want to cede control over my pages to Google? AMP pages do load fast, but if publishers want their web pages to load fast, they can just engineer them to load fast. Best answers I got were that it wasn’t really strategic — publishers are going with AMP just because their SEO people are telling them to, because Google features AMP pages in search results. I suppose that is a strategy, but ceding control over your content to Google isn’t a good one in the long term.
That worry is rooted in distrust of Google. Personally, I’m not too worried about that, but I get it. I get fist-wavy about plenty of other things.
I’d also add that, compared to Apple News or Instant Articles, having google.com at the front of the URL doesn’t feel like much of a loss of control.
It’s a non-trivial technology investment
At first, I kinda thought it was in the trivially-easy category, like RSS.
Yah, it’s a kinda weird new format, full of web components like <amp-img>
and such. But of course, just like a WordPress site can kick out an RSS feed, there is a plugin for a WordPress site to kick out an AMP version. Web searching around, I see there is plugins for other popular CMS’s like Drupal and Jekyll. Probably about 20 seconds of technology investment.
But… you lose a lot if that’s all you do.
All your ads and calls-to-action and such don’t get to come along. You can have ads on AMP, but only AMP-specific advertising platforms. It’s likely you’ll be handling advertising with totally new partners. You’d better hope you get a ton of mobile search traffic, otherwise, it’s probably not really worth dealing with. If you’re going all-in on a publish-wherever strategy, you’re probably looking at all-new advertising partners everywhere. Ugh.
Your newsletter signup form in the footer? Gone. Your little suggested articles widget at the end of the article? Gone.
It’s not like these things can’t exist in AMP, it’s just going to require to rejigger how they are done entirely to get them back, because your JavaScript isn’t allowed. Even your branding and typography and stuff is going to require custom work to maintain.
These are the options for going AMP, it seems to me:
- Use a CMS plugin to generate an AMP page for you, and just let the default be the default.
- Use a CMS plugin, but fight whatever battles you need to customize it for your needs.
- Build your own system.
- Use a magical tool like Mercury or a paid custom service like Relay Media
Personally, while I am totally fine with another publishing format and totally compelled by the speed, I don’t love any of those options.
AMP won’t tell you: heyyyy maybe don’t use this
There is some risk here, and I think that’s part of the controversy. The AMP docs aren’t going to list reasons to not use AMP. They are compelled to tell you why you should.
The risk is that it’s more development than it’s worth. The risk is that you do a bunch of work and lose money. The risk is confusing users. The risk is something weird and uncouth happing at Google. Even wider scope, the risk is that AMP is bad for the web.
You don’t need AMP to get AMP-like results.
The Google caching is notable in that it is free, but other than that it appears to be nothing more than any CDN can do for you. You can build your sites to be prerender and cache friendly. You can limit your use of JavaScript. You can carefully select your HTML and write your CSS with the goal of performance in mind. You can do all these things all by yourself (and in fact you should be doing all of these things).
There is also nothing too exciting about the claim that using a subset of the web’s features will improve your performance. Kill JavaScript on any traditional article page out there and you’ll likely see very similar returns.
But, it’s like a clean slate. You could do this yourself, but you won’t. Or at least, people won’t at scale. Perhaps in a world where AMP is wildly successful, it influences the “regular” web toward cleaning up its act.
Even right now, AMP can be a perfect excuse on internal teams. Jeremy Keith:
Beleaguered developers working for publishers of big bloated web pages have a hard time arguing with their boss when they’re told to add another crappy JavaScript tracking script or bloated library to their pages. But when they’re making AMP pages, they can easily refuse, pointing out that the AMP rules don’t allow it. Google plays the bad cop for us, and it’s a very valuable role. Sarah pointed this out on the panel we were on, and she was spot on.
Putting a point on the not-required-for-perf thing:
At AMP Conf, Natalia pointed out that The Guardian’s non-AMP pages beat out the AMP pages for performance.
Is this actually good for the web, or not?
I absolutely recommend listening to ShopTalk 248: AMP, in which we had Paul on along with Barb Palsar.
Paul likes AMP, and is absolutely a pro-web dude, but admitted that there is some risk that AMP turns out to be not-so-good for the open web. Barb is an entrepreneur and admitted AMP is a risk.
Tim Kadlec is worried about the tool lock-in:
Using a very specific tool to build a tailored version of my page in order to “reach everyone” doesn’t fit any definition of the “open web” that I’ve ever heard. …
But they should be decoupled. Provide tooling to improve performance. Provide a model and method for producing a revenue stream and improving distribution.
Paul Irish chimed in on that article:
While the “tools not rules” philosophy is technically correct, it doesn’t scale across the developer base as easily. Subsetting what is possible on the platform provides clear constraints and is certainly easier to follow.
AMP is a commitment to the web. Google probably could have followed suit with Instant Pages and provided some non-web format that would create a parallel publishing universe. But AMP has been designed to be web-compatible because Google believes that content has the best value when its on the web.
Gina Trapani is worried too:
If you talk about the open web you’re talking about standards-based and decentralized and where content isn’t privileged right? And AMP does all those things. It’s not a W3C standard… yet. It’s not decentralized because at least all AMP pages are hosted on Google’s cache. So if you search Twitter for google.com/amp there’s lots of results there people are sharing that URL so it’s not decentralized…. AMP content is privileged in search results, and that concerns me.
It’s that privilege that incentivizes the use of AMP at all. It certainly was for me.
In my experience, people are motivated to use AMP…I’ve seen this from our clients…mostly because of SEO. They want it in that top stories carousel, they want that lightning bolt of approval in regular search results which is happening now. And that concerns me. I’d rather that the concern for them was about performance and better user experience but it’s about SEO and search rankings. How many publishers would use AMP if that weren’t a factor? Fewer.
ANYWAY. It’s complicated.
To me it would feel better if…
- The tooling to create really good AMP pages got even better and easier.
- More that just Google used the format to do cool things.
- It was never used as search ranking factor (or anything that could be interpreted as such) by anybody.
- It became a W3C standard.
- The advertising ecosystem became super-ready to follow your content whereever it is.
But my thoughts are evolving on this just like everyone elses.
Most important part:
Want fast mobile pages? Get rid of most of your JS; get it down to one lean script, and, no, a bunch of minified, concatenated libraries don’t count as lean. Get rid of most of your CSS, and inline whatever remains directly into a style tag. Get rid of your back-end delays by caching the generated HTML using a CDN.
…And you’ve got AMP. AMP just makes all of the above a lot easier, and gives people a solid set of rules to refer to when unsure.
AMP creates a parallel web. Content is published in two formats, one that has been going for decades and is understood by all, machines and people alike, the other is AMP. It has a cut down subset of features, creates it’s own brand new standards, meaning you have to built a parallel universe to support AMP. I would liken AMP to building your own mobile app, it takes a lot of effort and you do get some benefits but it’s a silo’ed environment for one particular app stor. In the long term it’s not good for the web.
It might not be well known, yet, but in any recent discussion about AMP I never hear somebody mention Cloudflare’s introduction to Accelerated Mobile Links.
With notable quotes from the introduction:
and
I guess this might change the discussion a bit.
(not affiliated)
This is what happens when a search engine becomes essentially a monopoly.
Many websites depend on Google for most of their traffic, so if Google says “Do X or else your traffic will be drastically reduced” then you are forced to obey.
If faster pages was the aim they could have easily achieved the same thing by giving a SERP boost (along with a lightning bolt icon) to all pages that were faster than a specified threshold, along with guidelines and even tools to help developers achieve the required speed. Google already measures the speed of pages, so this is totally possible from a technical point of view.
But apparently what they care about is not faster pages, but more control over our content and AMP is just an excuse for them to gain even more power.
Theo,
You’re missing the point here: Google is actually making your pages faster for you by caching the AMP versions. Yes, Google could just boost faster pages regardless of AMP, and I’m fairly certain that they do, but for the average web content creator, Google-backed AMP pages are going to be much faster and much cheaper than anything else within reach.
This is a great collection. I missed what Tim wrote about AMP.
What made me concerned about AMP is not listed, but a (former?) Google developer summarized in https://meiert.com/en/blog/20160818/amp/ — we lack insight into the specific design decisions, and without that insight, AMP seems to be poorly designed. It may not be surprising if AMP was dead within a few years (my take).
Perhaps it is as you say: complicated.
Your comment about “not being worried about Google” – I understand; and I know you pick your battles carefully and meticulously avoid “dissing” anybody or anything. I do need to confess however, that I don’t share your “cart blanch” attitude of trust.
Google is massive – if they want it, they buy it. Google seems uncomfortably arbitrary to me, closing programs and facilities which have been used so long they have become essential generic commodities. If they’re not careful, their sheer size can change almost their every move into being a “bully” to someone using the web. Google is the kind of company that demanded the FTC and its laws come into existence; for which monopoly laws were created. Google’s market share can, by definition, mean things like “you play ball my way or you don’t play at all.” Google has always generated suspicion about the possibly abuse of their position – whether they’ve actually abused it or not people wonder – “do those who pay get top billing.”
Google has shown great altruism which clearly benefits not only the web but other aspects of our lives too, Google Earth comes to mind. For some, it’s natural to wonder how long that altruism can last, Panoramio comes to mind. Who is there who hasn’t scratched their head in wonderment when search after search pulls up two or three results of what you really asked for and page after page of sheer crap where Google things it knows better what you want than you do? And who hasn’t done an image search for something like “kid on a swing” and had every single result page pull up photos of “obama” or “hillary.” Or written a definitive article about something in a field where you may be the single person on the planet qualified to write about but find it buried down Google’s results under pages of single teenage blog pages posted by kids who mention one keyword once; but have hundreds of adolescent followers “liking” it.
That’s sort of where I am with almost anything Google. It’s there. It’s been incredibly altruistic while also being arbitrary and capricious. I want to trust it; but, can’t fully and every neuron attached to my “common sense” center screams “watch out.” In many things I see they don’t get it right – but in some cases don’t know the situation is completely solvable. And, even if I did receive some epiphany from on high some night for solving a great problem – Google is so huge and diffuse and self-protective, how would anyone ever get through to them? (Of course Chris might have their direct phone number but what about me).
That’s the way it is with me and AMP. Of everything I’ve read, it’s only the one thing: “it’s faster” that draws me in. Absolutely every other requirement either screams “you’ve gotta be kidding,” “How’s that any better,” “why would I want to do that,” “who has time to do all that,” OR “you implement that and it’ll be too costly or impossible to change back.”
Of course, this is just amateur me talking; and I’m all too aware of how detractors come out of the woodwork when something new is invented. My field is ripe with what you call these days “haters.” Which makes me really try hard not to be part of the kind of “establishment” like who wouldn’t accept Arthur Couney who wanted to import the European invention, infant incubators, into the established US medical system. That was until he, for 40 years, set up what was basically a free “newborn ICU” (for the time) in Luna Park on Coney Island, funded by a public admission fee of 25 cents. (Forty years he did that treating 8,000 children and saving 6,500 of them).
Perhaps AMP is the next greatest invention – I hope not, because we sure need to give up a lot for seemingly so little gain – but even if it is, it worries me, being what seems so… unilateral.
To add one thing to the discussion: Even if you hate AMP, learn how it works. It’s not magic. It is basically enforcing a set of rules that make pages load faster:
Limit CSS
All CSS is inline
Minimal JavaScript
The dimensions of all elements are known before external assets load
etc.
You can use those principles without using AMP.
Personally I like AMP, and I think many websites that are simple static content should be 100% AMP.
One thing I’ve seen over and over in comments on Reddit, Twitter, and Hacker News is that it’s simple to convert a site to AMP, but difficult (or impossible) to remove your AMP pages from Google results if for any reason you decide to discontinue the use of AMP.
One developer converted his whole site (thousands of pages) as a test, decided against using AMP, then found that the only mechanism to remove a page from Google’s AMP cache was to send them every single page URL you wanted to remove individually, which for him meant thousands of requests would need to be made.
You might think that sounds like a lot of work, but it wasn’t – since the form didn’t work anyway so he couldn’t remove any pages from the AMP cache at all! ♂️
Be careful testing it out, make sure you can un-AMP your pages if you need to before converting your whole site! ⚡️
Remember Google’s rel=”author” setup years back, in like 2009? Authors of webpages could connect their G+ accounts to their content and their avatar would often show up in SERPs next to their listing. It was supposed to drive more traffic and give people an incentive to sign up for G+, too. But that went the way of the dodo. If this doesn’t take off, those carousels will likely drop off, too. I suspect this is an experiment that won’t catch on, specifically because of this debate itself. The incentives just aren’t clear enough, and the worries too great for people to jump on the bandwagon.
“It became a W3C standard”
I’ve said this before and I will say it again: AMP cannot be turned into a w3c standard because:
– Web components are already a standard
– A caching proxy can’t be a standard
– JavaScript is JavaScript is a standard
Progressive web app enhancement is the standard, a caching CDN is a utility.
None of the things AMP does actually have to do with writing great publishing sites. Actual publishing CMS’s (not blogging platforms) have great Schema.org micro data in them, dynamic rel linking and canonicals, etc.
It’s this laziness first, good dev last mentality that Google is promoting while not clearly stating the risks (what if the cdn is taken down in the future? What happens to your carefully configured amp-utility?)
<!--[if AMP]>
Just when all major browsers became standardized we get IE6 all over again.
<![endif]-->
Hey Chris,
thanks for your write up, it shows you’re clearly thinking about potential problems and solutions, and we need more developers out there doing exactly that, in the context of AMP.
Now, I’d just like to clarify two things: First, You seem to position AMP in the context of the still-lacking WordPress plugin, as something you “turn on” on top of your “normal website”. I don’t think that paints an accurate picture. You would have none of these issues if you’d built AMP pages from scratch. It’s a bit like saying “pfft RWD is weird because that WP plugin kinda doesn’t work” :)
Second, creating another m.dot site, or parallel web, as some would call it, is entirely the developers choice – we don’t enforce it. In fact, I’d heavily discourage it (and I’ve done so before in my blog). To be fair, you are mentioning I’m doing the unusual thing and am treating AMP like…any other library to build a website, but does that really have to be unusual?
Anyhow, keep your thoughts coming, and maybe stop by at one of our design reviews on a Wednesday!
Honestly the more I try to imagine a different response the more I hear always the same one: “Without the SERP benefit no one would ever consider amp”.
It’s not the best technology. It’s the imposed one.
Sorry to say, but it’s the reality.
I really love all of you Googlers, but as sad as it is this is the reality.