Andrew Welch · Insights · #craftcms #mobile #performance

Published , updated · 5 min read ·


Please consider 🎗 sponsoring me 🎗 to keep writing articles like this.

Google AMP: Should You Care?

AMP is Google’s Accel­er­at­ed Mobile Pages ini­tia­tive. Here’s a primer, and how to imple­ment AMP with Craft CMS

AMP is an ini­tia­tive from Google that is an answer to what they view as the slow, clunky mobile web. Google has long cared about web per­for­mance; that’s why they cre­at­ed Google Page­Speed Insights. Google cares about web per­for­mance because users care about web per­for­mance. There are a ton of stud­ies to back this up; one I find use­ful to present to clients is The Need for Mobile Speed.

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

Google cre­at­ed Google Page­Speed Insights as a tool to help devel­op­ers make their sites faster, and many web devel­op­ers just shrugged and ignored their rec­om­men­da­tions. They even made page speed a rank­ing indi­ca­tor for the Search Engine Results Page (SERP), and many web devel­op­ers still just shrugged and ignored it.

The most amaz­ing thing about the web is also it’s most glar­ing flaw: you can real­ly put any­thing on a web page that you feel like. This includes mak­ing web­sites that per­form ter­ri­bly, espe­cial­ly on mobile devices that are more sen­si­tive to per­for­mance issues due to their lim­it­ed pro­cess­ing pow­er and high laten­cy cel­lu­lar Inter­net connections.

A large num­ber of peo­ple who are mak­ing web­pages today come from a design back­ground, not an engi­neer­ing back­ground, so per­haps this is no sur­prise. But Google decid­ed to do some­thing about it. So they cre­at­ed AMP.

Link What is Google AMP?

Per­haps a bet­ter ques­tion is what it isn’t. AMP is more about what you can’t do and forces us to become a min­i­mal­ist. You can’t have exter­nal CSS files. You can’t have exter­nal JavaScripts (with a big aster­isk, more on this lat­er). Cer­tain HTML tags are ver­boten. !important is not allowed in your CSS. And so on and so forth.

While these restric­tions may seem oner­ous, they exist for a rea­son: the per­for­mance impli­ca­tions of allow­ing them. A num­ber of very smart peo­ple have come up with best prac­tices for cre­at­ing per­for­mant mobile web­pages, and AMP enforces them. Inter­est­ing­ly, if you fol­low all of the best prac­tices rec­om­mend­ed by Google Page­Speed Insights, you’re already doing most of what AMP requires you to do to cre­ate per­for­mant webpages.

AMP also intro­duces web com­po­nents, essen­tial­ly new tags that allow you to do things in a per­for­mant way. For exam­ple, instead of using the <img> tag, you must use the <amp-img> tag. While this may seem arbi­trary (and even a lit­tle annoy­ing), these new tags exist for the same rea­son: they imple­ment things in a mod­ern, per­for­mant manner.

The con­cept of web com­po­nents comes from Google’s Poly­mer Project, and the basic idea is that we can extend HTML5 syn­tax by cre­at­ing new seman­tic tags for the addi­tion­al func­tion­al­i­ty we require. Web com­po­nents are meant to bun­dle fron­tend UI ele­ments into reusable com­po­nents that can be stan­dard­ized across projects. It’s an inter­est­ing con­cept that nev­er real­ly caught hold in the main­stream, but it has resur­faced with AMP.

While the focus is on mobile, AMP will work in any brows­er. How­ev­er, typ­i­cal­ly you will have a nor­mal ver­sion of your web­page as well as an AMP ver­sion of the same web­page. The AMP ver­sion will be found by users pri­mar­i­ly via Google search results, which mark them with a lit­tle light­ning bolt ⚡ to encour­age peo­ple to click on them.

Google AMP SERP for a nys​tu​dio107​.com blog page

This may seem to some like a return to the bad old days before respon­sive design, where there exist­ed a mobile ver­sion of a web­site, and a desk­top ver­sion of the same web­site. And they would­n’t be entire­ly wrong. How­ev­er, AMP is Google’s open answer to the walled-gar­den approach offered by Apple News and Face­book Instant Arti­cles.

Google orig­i­nal­ly only returned AMP pages in their News search results, but has since announced that they are plan­ning to roll it out in the main Google search results for mobile. 

Google will also cache your AMP pages for you, and deliv­er them from its own Con­tent Deliv­ery Net­work (CDN) via a URL like this:

https://www.google.com/amp/nystudio107.com/blog/the-craft-cache-tag-in-depth/amp

How­ev­er, con­trary to pop­u­lar belief, this isn’t Google hijack­ing your con­tent. You can still link to the reg­u­lar ver­sion of your page on these Google-served pages, or do what­ev­er you like. Google is just serv­ing the page con­tent to accel­er­ate its deliv­ery to the end-user. It’s real­ly not any dif­fer­ent than hav­ing Cloud­Flare (or any oth­er CDN) serve up your con­tent for you.

Google’s AMP Cache, as they call it, han­dles val­i­dat­ing the AMP page, and ensures that what it is deliv­er­ing is in sync with your pub­lished page. But noth­ing pre­vents you from serv­ing the AMP page direct­ly; indeed you have to, oth­er­wise Google can’t dis­cov­er 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 reg­u­lar HTML pages, and Google­Bot will crawl and con­sume them:

<link rel="amphtml" href="https://nystudio107.com/blog/the-craft-cache-tag-in-depth/amp">

Sim­i­lar­ly, on your AMP page, you include a <link rel="canonical"> to point to the reg­u­lar ver­sion of your page. As you might have guessed from the links above, the blog you’re read­ing right now has an AMP ver­sion of each blog page. Here’s a link to the AMP ver­sion of the fol­low­ing blog entry: The Craft {% cache %} Tag In-Depth

Link 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 with­out fur­ther ado, let’s look at what the most basic AMP page looks like:

<!doctype html>
<html ⚡ lang="en">
  <head>
    <meta charset="utf-8">
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <title>Hello, AMPs</title>
    <link rel="canonical" href="http://example.ampproject.org/article-metadata.html" />
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <script type="application/ld+json">
      {
        "@context": "http://schema.org",
        "@type": "NewsArticle",
        "headline": "Open-source framework for publishing content",
        "datePublished": "2015-10-07T12:02:41Z",
        "image": [
          "logo.jpg"
        ]
      }
    </script>
    <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>
  </head>
  <body>
    <h1>Welcome to the mobile web</h1>
  </body>
</html>

So a few inter­est­ing things to note about this skele­ton 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 pro­vid­ed by the <style amp-boilerplate> tag. Addi­tion­al inline CSS styles can be includ­ed via the <style amp-custom> tag.
  • The inclu­sion of JSON-LD in the AMP spec, fur­ther demon­strat­ing Google’s com­mit­ment to Struc­tured Data (aka ​“Rich Cards”) via JSON-LD. And yes, the SEO­mat­ic-ren­dered meta works fine here.
  • The only includ­ed JavaScript is loaded async, and comes from Google

Oth­er than that, it’s noth­ing too unusu­al. It may ran­kle some feath­ers, because it’s a cus­tom sub­set of HTML5, but truth be told, it isn’t very hard to wrap your head around it, and get it working.

Link So… Should You Care?

AMP pages cer­tain­ly do load fast, espe­cial­ly on mobile devices where the weight of nor­mal respon­sive web­pages can be more notice­able than on a desk­top com­put­er. They load even faster once Google­Bot has crawled your pages, and serves up the AMP pages via its AMP cache from the SERP page.

If I were a pub­lish­er of any kind, I cer­tain­ly would imple­ment AMP pages. But then I’d also imple­ment Apple News and Face­book Instant Arti­cles as well, all out of pragmatism.

For every­one else, I think the adop­tion 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 build­ing web­pages. Which I think is a good thing, the web could use more of a focus on per­for­mance to make peo­ple’s expe­ri­ence more pleasant.

Link Implementing AMP in Craft CMS

Craft CMS’s use of Twig makes it a nat­ur­al for imple­ment­ing AMP pages. Sim­ply cre­ate a new _amp_layout.twig that your oth­er tem­plates extend, and then spend some qual­i­ty time remov­ing JavaScripts from your tem­plates, and replac­ing them with AMP web com­po­nents if avail­able. This blog, for exam­ple, uses Vue­JS to imple­ment the ​“ham­burg­er” menu; for the AMP pages, we instead use AMP Side­bar web component.

Then set up a route like this in your AdminCP:

And then in your _amp_entry.twig file, include some Twig code to load the appro­pri­ate 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 gen­er­ate your inline CSS, you’ll either need to hand-code the CSS need­ed for the AMP pages, or if you use Gulp or Grunt (and you real­ly should be using a task run­ner to auto­mate your build sys­tem), you can extract it using the fan­tas­tic Crit­i­cal. I was already using it to build the Crit­i­calC­SS for the reg­u­lar web­pages, so it was­n’t a big deal to adapt it for build­ing the CSS for my AMP pages.

If you have Rich Text fields that your clients put images and oth­er such things into, check out the Ampli­fy plu­g­in that lets you do things like {{ entry.body |amplify |raw }} to automag­i­cal­ly make the HTML from the Rich Text fields AMP-friendly.

That’s about it… build your AMP page, run it through the AMP Val­ida­tor, fix any issues. Lath­er, rinse, repeat. If my expe­ri­ence is any mea­sure, you’ll like­ly be annoyed at first, dis­mayed at all of the things you’re let­ting go of. But then, you may find it lib­er­at­ing and thought-pro­vok­ing in the end.

Hap­py AMP-ing!