What is AMP?
AMP (Accelerated Mobile Pages) is a markup language for web pages intended to speed up the mobile rendering experience. This of course makes the assumption that a. your device is on a slow connection and b. could benefit from a lighter presentation layer in terms of rendering speed.
Put simply, AMP will deliver faster page rendering when compared to the same web page using conventional HTML/CSS/JS.
Accelerated Mobile Pages consist of three different parts (Source):
- “AMP HTML” – HTML with some restrictions for reliable performance and some extensions for building rich content beyond basic HTML.
- The AMP JS library ensures the fast rendering of AMP HTML pages.
- The AMP CDN (optionally) delivers the AMP HTML pages.
In essence, you’re giving up the infinite amount of choice you have available using your favourite development tools and libraries, but you’re gaining a ridiculously performance optimised presentation layer in exchange.
Where To Look For The Basic Layout
AMP is very easy to get started with. If your company blog happens to use WordPress, you can download and install this plugin which pretty much handles everything for you. I say “pretty much” as your AMP pages need to validate. More on that in a moment, let’s suffice it to say you’ll wish you’d not cut any corners in your blog post markup, images and videos.
Once you’ve installed Automattic’s AMP plugin, add the Pagefrog plugin, which aside from AMP Analytics support for Google Analytics, Chart Beat and Parse.ly, you get much better control over the page layout, your logo use and several other handy styling options:
Just be sure to activate AMP here:
Pro tip: for better integration with Yoast’s SEO Plugin, install this glue plugin from Yoast.
If you’re running a custom CMS or have some sort of platform that’s less well supported by a development community, you’ll need to implement page templates based on this schema.
What Does AMP JS Do?
AMP’s JS Library handles all of the rendering performance enhancements offered by AMP. It enables the custom elements included in the AMP HTML spec; for instance “amp-img”. The outcome, responsive images by adding srcset into the markup. AMP JS makes anything loading from external resources asynchronous and enables ads, analytics and lots of performance optimisation.
What About AMP CDN?
The AMP CDN is a pull request based proxy for your AMP content. If you make a request for your site content via the following URL, you’ll get your AMP content:
Here’s a like for like comparison of one of Builtvisible’s pages:
Valid AMP, Served Via WPengine
Valid AMP, Served via AMP CDN
Invalid AMP, Won’t Serve Via CDN
Interestingly, I think that CDN’s a mixed bag. On the one hand, it’s a useful albeit binary validator. On the other it could be a great performance enhancer. I’ll assume that on a slow connection, Google might choose to serve some or all of a page’s resources via the AMP CDN.
I found the CDN 100ms slower than WPengine’s (which is nice) but it also introduces minor validation errors in developer console if you’re using “#development=1”. I can imagine somebody somewhere getting really stuck with trying to resolve a validation error seemingly introduced via the CDN.
If you want to track your AMP pages (and why wouldn’t you) then you’ll need to follow the steps to implement AMP analytics in this guide.
If you’re using the WordPress AMP plugin, the implementation looks like this:
Access by editing the file: /amp/templates/single.php
I doubt GTM support will be available as AMP tries to reduce the page load overhead, not inflate it. Tom has set up alerts in our analytics to let us know if and when we ever see any meaningful traffic from this exercise.
As a side note, you’ll overwrite the GA modification if the AMP plugin updates, so bear that in mind. I’m pretty sure they’ll be an update to natively include support for GA at some point, which will be nice.
If you’re using the PageFrog plugin, it’s slightly easier. Just authenticate with your GA account from this screen:
Fun With Validation
When I decided to write this post I thought, “how hard can it be?”.
To find out, head to the AMP report in Search Console:
It’s OK, that’s not as bad as it initially looks. In fact, the majority of errors are caused by lazy markup in early blog posts. If nothing else it’s just a good excuse to go and review all of our old pages.
I think for the most part you can get your pages to validate more or less immediately. The gotcha for us is that we have a huge amount of legacy posts with images that use only a “width” attribute in the image container. That was a mistake made a long time ago – so now we have around 200 posts that will need this remedying. Our CSS takes care of image width and so the solution is to remove the “width=” attribute and let AMP JS sort it out.
Chrome’s Developer Console has a built-in AMP validator, so the quickest way to assess the damage is to add the parameter: #development=1 to the end of your page URL like so:
Then head to console to take a look:
Just a pesky video issue to sort out. I think it’s quite a simple fix as we serve video in HTML5 video containers as often as possible. I’ll probably tweet about it later.
When You’re Ready
Obviously, I’m now sat waiting for all the lovely traffic, or more likely, for my existing traffic levels to be preserved should Google make good on their promises. With a GA alert set up, the last thing to do is make sure your standard web pages declare the AMP content as follows. Good luck!