AMP, Quick and Dirty

Accelerated Mobile Pages (AMP) trade userland JavaScript and network-loaded resources for lightning-fast load times. Since AMP is able to constrain resource loading and page rendering, it can save both CPU cycles and bandwidth during page rendering. It’s a compromise, but for content-driven sites it’s certainly worth a look.

Plus it’s easy to do. I start porting this blog mostly out of curiosity, but after half an hour, one new template, one additional build rule, and a little bit of polish with the AMP validator, I had a simple (but functional) AMP-compliant facsimile of the real thing.

Updating the Template

Following the getting started guide, I first created a template exclusively for the AMP route. It shares all of its variables with the route that’s served to desktop browsers, but it allowed me to check AMP’s boxes with no impact on the existing experience. These really only meant a few changes:

  • noting AMP support in the <html ⚡> tag
  • removing all userland <script /> and <style /> tags
  • adding the AMP runtime and <style amp-boilerplate> styles

Not wasn’t my prettiest work–stripping away the base stylesheet will do that–but it was somewhere to start.

Updating the Stylesheet

Next up was the stylesheet. All new, but heavily dependent on existing parts.

/* amp.css */
@import 'normalize.css';
@import 'screen';

.header {
  /* AMP-specific rules go here */

Since the site build was already running through gulp. I’d barely added amp.css to the list of source files before a compiled version was ready for injection (as compiledCss.amp) back into the template using an amp-custom style.

<style amp-custom>

Restoring Analytics

Most modern analytics libraries use JavaScript for tracking–streng verboten in AMP. But since the format is designed with advertisers in mind, the <amp-analytics> provides a reasonable alternative (with pretty good vendor support). I imported it into the AMP template just after the core library.

  <meta charset="utf-8">
  <script async src=""></script>

  <script async custom-element="amp-analytics"
  <!-- ... -->

Setting up tracking (e.g. Google Analytics) just meant adding an <amp-analytics> element inside the existing page <body />:

<amp-analytics type="googleanalytics">
<script type="application/json">
  "vars": {
    "account": "UA-XXXXXXXX-X"
  "triggers": {
    "trackPageview": {
      "on": "visible",
      "request": "pageview"

Referencing the AMP page from the original page

All that work and no-one to see it? Switching back to the desktop template, I added a <link /> to the AMP version of the page:

<link rel="canonical" href="{{url.self}}" />
<link rel="amphtml" href="{{url.selfAMP}}" />

Thirty minutes in, and things were ready for finishing touches. Chrome has AMP validation built-in; by browsing the local development site with #development=1 in the URL hash, I was able to find and fix lingering issues with the implementation. I sanded down the rough edges, and voila! v0.1 was off to the races.


While the step-by-step details here may help you get up and running, the more important message here is for other emerging technologies. When big business depends on pulling the internet onto a new standard–and make no mistake, alongside the noble mission of ‘make the web fast’, AMP also happens to be very well suited for selling ads–decent documentation and tooling go a long way.

Water runs downstream. Make adoption easy and adoption will come!