Andrew Welch

Andrew Welch · Insights · #webperf #craftcms #mobile

Making the web better one site at a time, with a focus on performance, usability & SEO

2016.12.02 · 5 min read ·

Google AMP: Should You Care?

AMP is Google’s Accelerated Mobile Pages initiative. Here’s a primer, and how to implement AMP with Craft CMS

Lightning Trees

AMP is an initiative from Google that is an answer to what they view as the slow, clunky mobile web. Google has long cared about web performance; that’s why they created Google PageSpeed Insights. Google cares about web performance because users care about web performance. There are a ton of studies to back this up; one I find useful to present to clients is The Need for Mobile Speed.

Google AMP exists because of you. And me. We didn’t listen.

Google created Google PageSpeed Insights as a tool to help developers make their sites faster, and many web developers just shrugged and ignored their recommendations. They even made page speed a ranking indicator for the Search Engine Results Page (SERP), and many web developers still just shrugged and ignored it.

The most amazing thing about the web is also it’s most glaring flaw: you can really put anything on a web page that you feel like. This includes making websites that perform terribly, especially on mobile devices that are more sensitive to performance issues due to their limited processing power and high latency cellular Internet connections.

A large number of people who are making webpages today come from a design background, not an engineering background, so perhaps this is no surprise. But Google decided to do something about it. So they created AMP.

What is Google AMP?

Perhaps a better question is what it isn’t. AMP is more about what you can’t do and forces us to become a minimalist. You can’t have external CSS files. You can’t have external JavaScripts (with a big asterisk, more on this later). Certain HTML tags are verboten. !important is not allowed in your CSS. And so on and so forth.

While these restrictions may seem onerous, they exist for a reason: the performance implications of allowing them. A number of very smart people have come up with best practices for creating performant mobile webpages, and AMP enforces them. Interestingly, if you follow all of the best practices recommended by Google PageSpeed Insights, you’re already doing most of what AMP requires you to do to create performant webpages.

AMP also introduces web components, essentially new tags that allow you to do things in a performant way. For example, instead of using the <img> tag, you must use the <amp-img> tag. While this may seem arbitrary (and even a little annoying), these new tags exist for the same reason: they implement things in a modern, performant manner.

The concept of web components comes from Google’s Polymer Project, and the basic idea is that we can extend HTML5 syntax by creating new semantic tags for the additional functionality we require. Web components are meant to bundle frontend UI elements into reusable components that can be standardized across projects. It’s an interesting concept that never really caught hold in the mainstream, but it has resurfaced with AMP.

While the focus is on mobile, AMP will work in any browser. However, typically you will have a normal version of your webpage as well as an AMP version of the same webpage. The AMP version will be found by users primarily via Google search results, which mark them with a little lightning bolt ⚡ to encourage people to click on them.

Amp Serp

Google AMP SERP for a blog page

This may seem to some like a return to the bad old days before responsive design, where there existed a mobile version of a website, and a desktop version of the same website. And they wouldn’t be entirely wrong. However, AMP is Google’s open answer to the walled-garden approach offered by Apple News and Facebook Instant Articles.

Google originally only returned AMP pages in their News search results, but has since announced that they are planning to roll it out in the main Google search results for mobile.

Google will also cache your AMP pages for you, and deliver them from its own Content Delivery Network (CDN) via a URL like this:

However, contrary to popular belief, this isn’t Google hijacking your content. You can still link to the regular version of your page on these Google-served pages, or do whatever you like. Google is just serving the page content to accelerate its delivery to the end-user. It’s really not any different than having CloudFlare (or any other CDN) serve up your content for you.

Google’s AMP Cache, as they call it, handles validating the AMP page, and ensures that what it is delivering is in sync with your published page. But nothing prevents you from serving the AMP page directly; indeed you have to, otherwise Google can’t discover and cache the AMP page to begin with.

So how does Google know about your AMP pages? You include a tag like this in your regular HTML pages, and GoogleBot will crawl and consume them:

<link rel="amphtml" href="">

Similarly, on your AMP page, you include a <link rel="canonical"> to point to the regular version of your page. As you might have guessed from the links above, the blog you’re reading right now has an AMP version of each blog page. Here’s a link to the AMP version of the following blog entry: The Craft {% cache %} Tag In-Depth

Show Me the Code!

So now you have at least some idea of what AMP is all about; to find out more, check out Google’s What is AMP? page. And now without further ado, let’s look at what the most basic AMP page looks like:

<!doctype html>
<html ⚡ lang="en">
    <meta charset="utf-8">
    <script async src=""></script>
    <title>Hello, AMPs</title>
    <link rel="canonical" href="" />
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <script type="application/ld+json">
        "@context": "",
        "@type": "NewsArticle",
        "headline": "Open-source framework for publishing content",
        "datePublished": "2015-10-07T12:02:41Z",
        "image": [
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
    <h1>Welcome to the mobile web</h1>

So a few interesting things to note about this skeleton AMP document:

  • The <html ⚡ lang="en"> tag has a funky ⚡ in it; this can also be just amp as well: <html amp lang="en"> This lets Google know that it’s an AMP page
  • The default AMP inline CSS style provided by the <style amp-boilerplate> tag. Additional inline CSS styles can be included via the <style amp-custom> tag.
  • The inclusion of JSON-LD in the AMP spec, further demonstrating Google’s commitment to Structured Data (aka “Rich Cards”) via JSON-LD. And yes, the SEOmatic-rendered meta works fine here.
  • The only included JavaScript is loaded async, and comes from Google

Other than that, it’s nothing too unusual. It may rankle some feathers, because it’s a custom subset of HTML5, but truth be told, it isn’t very hard to wrap your head around it, and get it working.

So… Should You Care?

AMP pages certainly do load fast, especially on mobile devices where the weight of normal responsive webpages can be more noticeable than on a desktop computer. They load even faster once GoogleBot has crawled your pages, and serves up the AMP pages via its AMP cache from the SERP page.

If I were a publisher of any kind, I certainly would implement AMP pages. But then I’d also implement Apple News and Facebook Instant Articles as well, all out of pragmatism.

For everyone else, I think the adoption of AMP is less clear. At the very least, it isn’t very hard to do, and it can make you rethink how you approach building webpages. Which I think is a good thing, the web could use more of a focus on performance to make people’s experience more pleasant.

Implementing AMP in Craft CMS

Craft CMS’s use of Twig makes it a natural for implementing AMP pages. Simply create a new _amp_layout.twig that your other templates extend, and then spend some quality time removing JavaScripts from your templates, and replacing them with AMP web components if available. This blog, for example, uses VueJS to implement the “hamburger” menu; for the AMP pages, we instead use AMP Sidebar web component.

Then set up a route like this in your AdminCP:

Amp Route

And then in your _amp_entry.twig file, include some Twig code to load the appropriate entry from the URL segment:

{% extends "_base/_amp_layout" %}

{% if entry is not defined %}
    {% set entrySlug = craft.request.getSegment(2) %}
    {% set entry = craft.entries.section("blog").slug(entrySlug).first() %}
{% endif %}

To generate your inline CSS, you’ll either need to hand-code the CSS needed for the AMP pages, or if you use Gulp or Grunt (and you really should be using a task runner to automate your build system), you can extract it using the fantastic Critical. I was already using it to build the CriticalCSS for the regular webpages, so it wasn’t a big deal to adapt it for building the CSS for my AMP pages.

That’s about it… build your AMP page, run it through the AMP Validator, fix any issues. Lather, rinse, repeat. If my experience is any measure, you’ll likely be annoyed at first, dismayed at all of the things you’re letting go of. But then, you may find it liberating and thought-provoking in the end.

Happy AMP-ing!

Buried In Tag Manager Tags

· 2017.04.19

Tags Gone Wild! Managing Tag Managers

#frontend #devops #performance

Homestead Prairie Schooner

Insights · 2017.03.31

Local Development with Vagrant / Homestead

#devops #frontend #homestead

Tidal Wave Disaster

Insights · 2017.03.20

Mitigating Disaster via Website Backups

#backups #devops #craftcms

Web Host Server

Insights · 2017.03.09

How Agencies & Freelancers Should Do Web Hosting

#devops #hosting #vps

Critical Css Stopwatch

Insights · 2017.02.28

Implementing Critical CSS on your website

#critical-css #frontend #performance

Autocomplete Search

Insights · 2017.02.22

Autocomplete Search with the Element API & VueJS

#autocomplete #elementapi #vuejs

Structured Data

Insights · 2017.02.11

JSON-LD, Structured Data and Erotica

#json-ld #structured-data #SEO

Craft Cms 3 Beta

Reviews · 2017.02.09

Craft 3 Beta Executive Summary

#craftcms #Craft 3 #Review

No Robots

Insights · 2017.02.02

Preventing Google from Indexing Staging Sites

#frontend #craftcms #SEOmatic

${ category } · ${ blog.postDate }

${ blog.title }

#${ tag }