Creating a parallel AMP site with Jekyll
Google AMP (Accelerated Mobile Pages) is a strict subset of html that essentially only allows for content and a subset of supported inline css. Nearly all of the case studies are news sites. Google will give preference to valid AMP sites for mobile searches, if only because google can ensure the page is lightweight and fast. Though I attribute the project to google as google is leading the evangelizing effort, bing has joined with cloudflare hosting AMP pages too.
On a side note, I visited the travel site to find they have 250 elements in their
head element. As an unfair comparison, this page has 5 at the time of this writing.
But this discussion got me thinking about how easy it would be for me to “AMPlify” this site which is a Jekyll site. The history of this site has basically been a testing grounds for new technologies:
- 2012: move from homegrown static site solution to jekyll
- 2013: incorporate LESS CSS, RequireJS, minification using
Gruntfile.js. I can laugh at it now as the title is “The Perfect Blogging Workflow”. Heh.
- 2014: migrate from GoDaddy/IIS/WCF/C#/MySQL to DigitalOcean/Apache/Flask/Python/SQLite.
- 2015: Move frontend dependencies to bower. Still using grunt but starting to use webpack to generate sourcemaps and minify. Use skeleton.css for theme.
- 2016: Theme update, migrate to cssnext, remove Grunt, and use digested assets
- 2017: AMP!
AMPlifying with amp-jekyll
Amp-jekyll is still maturing and the currently released version (1.0.1) does not support jekyll permalinks, so I had to directly reference the repo in the Gemfile.
One of the first steps is to copy their
amp.html for your own use. Since I have a stylesheet that is preprocessed and minified, I needed to include it in my
amp.html. Typically, built pages use a
link to reference the stylesheet, but since AMP requires only inline css, I had to go with an include directive.
This did not work out of the box for me, so I created the following script to execute on every build to make sure the included css fit AMP requirements.
For regular posts, I updated their layout to include an
amphtml link so that webcrawlers know that I support AMP and where the AMP pages are loaded.
Now when I build the site, all blog posts have a sibling, AMP-enabled page that lives at the same url except it’s prefixed with
/amp. So the urls look like:
I had three posts where I forgot the
/blog prefix in the url. Amp-jekyll made these obvious and so I fixed these urls. Yes, I realize changing urls after the fact breaks the internet, but these weren’t popular articles – not popular enough for me to setup redirects.
I also had broken image links in older posts because I was using raw
figure html elements instead of the
Criticisms for AMP
- Kill Google AMP before it KILLS the web
- The Problem With AMP
- Google AMP is Not a Good Thing
- And Please Make Google AMP Optional, which was just posted a few hours ago
The articles are relatively succinct, so I recommend reading them – they’re decent, but I believe they’re overreacting:
- Google doesn’t actually own AMP. AMP has an open governance model. Only when there is no one working on the project does Google give itself the power to appoint a leader, in which case, since no one is working on the project does it even matter?
- Content is not just loaded from Google’s servers. Cloudflare hosts AMP content as well. Speaking of cloudflare, I’m not sure why having external sites cache content on edge server rubs people the wrong way. It alleviates concerns of DDOS attacks and site maintenance.
- You can create your own AMP cache
- Links work as normal. If a user clicks on an amp link, they’re taken to a feather-light page which has all the content they want, else if a user clicks on a non-amp link they get all the features of the full app.
- The subset of CSS allowed is annoying if only for the fact that one has to do small tweaks to get the css compliant. Without this subset, AMP would not be able to assume the layout was fast and sensible. It’s a tough sell, as no one wants to create custom css for AMP, but I understand the reasoning. Thankfully, this blog does not use a lot of CSS – only a few sed statements were needed to become AMP compliant.
- I’ll agree that removing AMP content from google’s AMP cache isn’t the most user friendly. Sending an “update-ping” to get immediate removal is tedious at best, but “cached content that no longer exists will eventually get removed from the cache” so one can just wait for the expiration. Since cache busting is a tough problem, this is a fine solution, though an optimal solution would be like Cloudflare’s where they have a nice UI for cache busting.
- One isn’t giving up anything when having a parallel AMP site. AMP content is still served from the origin, and if there happens to be an AMP cache server present, the content is served from there. It’s not like whoever hosts the AMP server owns the content. It’s simply an optimization for those who seek the content in a nice layout.
- Some lament that AMP would be good for fake news sites. I’m not sure where this idea sprouted from. I believe that satirical newspapers like the onion should be able to participate in AMP and reap any potential benefits.
With all the back and forth, why did I use AMP? It was a combination of two reasons. First, this site is a testbed and I wanted to answer the question of what effort is required. Since I only spent a couple hours adding this feature, the effort was low. Second, will tons of traffic pour in from the increase in search rank? I won’t know until if I don’t try! Before we part, I have to embarrassingly admit, given my stance on the importance of metrics, this site employs zero analytics and I will have a hard time determining improvements unless there is an order of magnitude increase. AMP does have a whole section on analytics, so this may be an area worth exploring.