Need to Catch Up on the AMP Debate?

Avatar of Chris Coyier
Chris Coyier on (Updated on )

📣 Freelancers, Developers, and Part-Time Agency Owners: Kickstart Your Own Digital Agency with UACADEMY Launch by UGURUS 📣

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:

  1. The AMP format. A bunch of web components. For instance, instead of using an img element on an AMP page, you use an amp-img element instead.
  2. The AMP rules. There’s one JavaScript file, hosted on Google’s servers, that turns those web components from spans into working elements. No other JavaScript is allowed. All your styles must be in a style element instead of an external file, and there’s a limit on what you can do with those styles.
  3. 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:

  1. On mobile
  2. 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…

  1. It’s not very much work
  2. 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.

Tim Kadlec:

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.