Google’s ⚡AMP reviewed as a developer

⚡

Google’s AMP has been getting lots of attention lately since its major worldwide roll out in the main search engine listing…

You’ve been AMP-ed

.. and with this article I want to chip with my point of view of the good and bad parts as a developer and site owner. But first…

Why?

The official answer. Do we need another HTML format to generate fast loading pages? Obviously the logical answer is no, because HTML is not the issue, HTML is actually pretty lean and mean. The biggest loading speed issue are iframes, ad networks, gifs and <script>-tags. Which AMP tried to kill in one big swoop! But then they didn’t...

So why are we doing this? Read along.

The good parts

• The web — specifically looking at you news sites — has been rendered to a messy bloat thanks to advertising networks and share buttons. Its been well documented and experienced that blocking ad network calls will improve your web browsing experience significantly. AMP initially doesn’t allow any Third-Party Content. The spec demands external tools to hook into custom HTML components. Take a peek. That a big Hooray! for users, but as a developer another weird custom spec to manage. I hope you’re using any of the approved ad networks, else you’re gonna be out of luck. Also is your CMS ready for <amp-youtube>?
• Part of the AMP spec is to mark up your content with meta data. A quest Google’s been wanting publishers to implement so they get a better understanding of the attributes and context of a page’s content — for utopist — or as cynics may say to extract your content and inject in the SERP directly. The good is the new json-ld spec makes much more sense then its predecessor (unfortunately still alive) microdata, which involves: itemscope, itemprop, meta, RDFa or even vcard attributes on nested DOM elements.

• 
  

  More visibility in Google.com results. The AMP icon might attract more visits to your listing. It was also launched with a small ranking boost (Update: officially not a ranking boost). My experience is that Google usually only says that to have developers adopt a new protocol. Personally I don’t see the uptick. And even if it improved your rankings, all your competitors would swoop in and in 6 months there would be no competitive advantage.For Google News publishers, of which my site is also a proud club member, the news carousel actually does show up more often, and AMP articles get way more eyeballs then before. Thanks Google!

• Speed! Yes it renders almost instant. And I know all non-4G/wifi people all over the globe will find this a killer feature to have. Including SSL by default. Even the good-ol’ <img> tag has been dropped in favor of <amp-img> for speed reasons.

The bad

• Maintenance of a carbon copy of your site’s content. Yes, AMP lives on its own URLs which you host yourselves. Only Google will crawl it, and it is not meant as a actual target to actually sent your visitors to (you could). Issues will appear, and you will find out late. Also Google will actually serve users their own local copy of your website. It closes the door to pages customized to logged in users. They do allow you to ping their CDN to update to a fresh copy. But yeah, more stuff to manage. Not cool. Although Webmaster Tools has some nice issue reporting. Update: and this new debug tool.
• Next to the point above. I thought we were all doing responsive design and wouldn’t be doing special mobile pages anymore? I was wrong. AMP is about mobile. So you’re building a custom mobile page. Until they also support desktop. For which I guess you would be doing @media queries to support those as well.
• The AMP-ed version is usually less user engaging due to the tied down html spec. Comparing the page-per-visit of the same page AMP-ed vs non-AMP the users are quicker in, but also quicker out. It might be caused due to less clutter on the not-feature-par non-AMP page but its bad. And I’ve seen more reports. One might argue this is actually a good thing. They do support stuff like image carrousels — can’t live without those — but only one Google provides for you.
• The spec started of mean and lean. But it’s already growing out of control to support all more and more existing web features. Good example: Cookie consent notifications. Their is a custom spec for that. Which is tied to a user. And does a CORS request to your backend. Don’t forget about Glycat! I don’t see an end in sight.
• Harder to monetize. The reason all those ad networks are loaded in a single page view is to make the most $ out of a single page view. My existing ad network for example isn’t supported yet, which implies I’m back to 2004 with a single Adsense unit, slashing revenue in half.

My advice

If AMP is an success, Google would be a clear winner. They would have results that load instantly, greatly improving the Google Experience™ setting the user up to use more of Google.

As a developer I don’t see how a mobile AMP copy of my site benefits me. It’s more backwards stuff.

But Google, lets meet in the middle. Users on 2G or GPRS get AMP-ed, I will supply an AMP supported website but we keep serving non-AMP to all other web users (e.g. iPhone 7 4G)? Hell, I will even propose a spec for that: amp-audience-target-only. LGTM.