Bringing Google AMP to LexBlog

For the past couple of months, we have been working on making our platform compatible with Google’s Accelerated Mobile Pages (AMP) format.  If you’re not familiar with AMP, I think it’s fair to summarize it thusly:  The practice of offering your website in a special format that Google invented, so that your Google SERP’s (search engine result page) have a small gray lightning bolt next to them, which leads the viewer to the AMP-formatted version of your page, which is hosted by google, and is definitely faster and more user-friendly than the default version of your page.

AMP carries a fair amount of controversy.  Many thought leaders worry about the rabbit hole of proprietary formats, and also the eyebrow-raising prospect of allowing google to serve your website. It’s worth getting acquainted with both sides of this argument if you are interested in AMP.  This podcast between web pioneer Jeffrey Zeldman and WordPress co-creator Matt Mullenweg is by far the best discussion I have found on the debate. For me there is one simple fact that cuts through the entire argument like a laser beam: If a Google search result has a little gray lightning bolt next to it, I’m far more likely to click on it because I know it’s going to be much faster, and I know the next page I see will be content-focused, simple, and legible. In that suspenseful moment where thumbs are hovering over search results, I want LexBlog to fall among the have’s, rather than the have-nots.

How, Generally?

Several years ago I met with former LexBlog CTO, current LexBlog Fairy GodFather, and google employee Robert McFrazier.  I was delighted to pester him with questions as usual, and when I asked him an open-ended question about the best thing we could do for our platform, he told it would be to introduce AMP.  Furthermore, he noted that in the WordPress space, developers were handling AMP as a plugin concept, rather than a theme concept, which he felt was a shortcut not always worth taking.  Although taking a plugin approach allows for faster adoption, it’s very heavy-handed and leaves the AMP page with very little of the design and branding that appears on the non-AMP version.  Given the time and ability, he believed it would be much better to adopt AMP from within a theme, so as to more easily carry the theme concepts (color scheme, layout, logos, fonts, icons) into the AMP version. Robert was right.  Even today, years after our talk, the WordPress community is approaching AMP almost entirely via the “official” WordPress AMP plugin, with virtually no theme frameworks doing anything interesting with AMP.  I’m very proud to say that at LexBlog we’ve broken that trend!  We have developed a one-click solution to enable an AMP version on any site using our modern platform, and that version carries all of the important design and branding concepts included in the non-AMP version.  As this project has matured, I’ve often had trouble telling the difference between our normal front-end and our AMP front-end.

How, Specifically?

There were three categories of things that we needed to import to our AMP version: Design, layout, and content.

Design

Because we approached this from within our theme, rather than taking the shortcut of approaching via a plugin, it was very convenient to grab design elements such as:

• Typekit fonts.
• FontAwesome icons.
• Firm logos and blog logos.
• Color schemes.

Layout

Layout was more difficult.  By layout, I mean things like white space, alignment, and a grid system.  Unfortunately, I was not able to simply load our normal CSS in its entirety, because it would have exceeded AMP’s size limit of 55kb.  I could potentially have just imported only the elements I needed, but I didn’t design that system to be served a la carte and I didn’t want to increase our bug surface area by forcing the issue. What I did instead, was grab a subset of the Bootstrap front end framework — just their grid and white space stuff — and then modify it to be compatible with AMP’s formatting rules.  I like this solution, largely because I really like Bootstrap, and also because it was fast to implement and left me with many thousands of kb left over for adding custom styles on top of it.

Content

By content I mean the act of converting html into the format that AMP requires.  A simple example is instead of the normal <img> tag, AMP uses an <amp-img> tag.  It gets far more complex from there, as everything from animated gifs to twitter embeds require special massage therapy.  This is where I was happy enough to stand on the shoulders of giants and grab some formatting code from the official WordPress AMP plugin, noted above.  It was fun to reverse engineer all the code into a state that was maintainable for our project, and I’m happy enough to avoid re-inventing that wheel.

What Next?

At the moment we are deploying AMP on internal blogs and employee blogs, and the results have been fantastic.  We’re in the process of generating automated test results against all of the blogs on our entire network, which we’ll use to further refine the product, before eventually opening it up for widespread use in some form later this year. I have no doubt that this product will be a massive success on a technical level.  More interesting will be the debate of, is AMP good for websites; is it good for the web?  My prediction is that the current stated fears about centralization will take on the look of John Henry’s hammer or William Jennings Bryan’s soapbox — it’s time to let the machines win something they’re going to win anyways.  If I’m being completely honest, I hope AMP eats the web.  I hope that in five years from now, we’re all making a single AMP-compatible website, rather than bolting on an AMP-compatible version.  Will that happen?  I don’t know.  But what I do know is that in order for it to happen, websites will need to preserve design and branding in their AMP offering, which is what our project is really about.