A Technical Review Of Adding Support For Google's AMP Pages

2016-11-22 - By Robert Elder

Overview

• Key Considerations When Using AMP
• Does AMP Improve Search Engine Rankings?
• Pros and Cons of using AMP Pages
• Gotchas
• Conclusion
• References

Introduction

     In this article, I discuss the technical details of what was involved in updating my blog to be have support for Google's AMP (Accelerated Mobile Pages).

     Google's AMP project is an initiative that seeks to provide mobile users with a faster and better experience when browsing the mobile web.  For example, a user's search experience on Google is improved since pre-rendered AMP-compatible views of pages can be cached and served directly from Google's servers without the user's machine having the need to make any requests to content producer's server.  Another aspect of the speed improvements are the tight restrictions placed on AMP pages that forbid excessive use of Javascript or features that block page rendering.

     This blog does not use any frameworks so this article will contain more of the gory details that you might not get exposed to if you were simply running a Wordpress site.  If you are running a Wordpress site this article probably won't be very useful to you.

Key Considerations When Using AMP

     If you're a developer, you probably just want to know "What key design differences will my AMP pages have from my non-AMP pages?".  Here is a list of them:

• You can't use Javascript on AMP pages[1], but you can put Javascript in iframes[2] or substitute the javascript feature for an existing amp-component[3].  This rule feels rather draconian at first, but Javascript is one of the biggest potential source of slowing down a page.  You don't have to look very far to find examples of pages that attach every event handler possible and cause the page to lag so badly that you can't even scroll on mobile.
• AMP pages require that Javascript is enabled[4].  Because AMP does things like lazy-load images, you won't be able to see images with AMP unless javascript is enabled.  In order for pages to pass AMP validation you must include the "https://cdn.ampproject.org/v0.js" script on AMP pages.  Furthermore, I believe you are required to hotlink to the ampproject version as I have been unable to pass validation with a locally served copy of these scripts.  After checking the validator source in the AMP project git repository, it looks like this is the case since the full URL appears to be hard-coded in the validator configuration.
• You can't use inline 'style="..."' tags[5]  I actually used these quite a bit, but it wasn't particularly difficult to move them into the style tag of the head section.
• AMP uses inline 'style="..."' tags on rendered markup which can unexpectedly interfere with stylesheet rules since inline style attributes have high precedence.
• External stylesheets are not allowed[6]  You can't include external stylesheets in the form of <link rel="stylesheet" href="..." />
• You will likely want to maintain a separate AMP view and a non-amp version of your pages.  You could serve all of your users (desktop and mobile) an AMP page, but due to various markup restrictions you're unlikely to want to do this.  For example, if you want to support images on your site and you need to be able to serve users who don't enable Javascript, then you'll need a separate view for this because the images will not load on a Javascript disabled AMP page.  Historically, people would often create one page with a 'reactive' layout that involved percent based widths and @media css rules that might change depending on screen width.  With AMP, the differences between the 'Desktop' and 'mobile AMP view' become so great that it only makes sense for it to be a completely different document (that you programmatically derive from a common template).
• The DOM structure of AMP pages will be slightly different than for desktop pages.  For example, on desktop, you might have

  <div class="something">
  	<img .../>
  </div>
  

  and after you convert it to be an AMP image tag you'll have

  <div class="something">
  	<amp-img ...></amp-img>
  </div>
  

  but after the page loads the DOM will turn out looking like this

  <div class="something">
  	<amp-img ...>
  		<img .../>
  	</amp-img>
  </div>
  

  so a rule like this that worked on the desktop view will not work on mobile AMP:

  .something > img{
  	display: block;
  }
  

• There are a few minimum requirements to an AMP page.  One of these requirements is a set of stylesheet rules that is validated using a regex[7], so you may need to be careful if you use a minifier, or if you use an editor that tries to format things on you.

Does AMP Improve Search Engine Rankings?

     This is the million dollar question that everyone is wondering about.  I was unable to find a credible source that AMP pages currently improve search engine rankings.  It is, however, entirely likely that it will become increasingly important in the future.  Google already signals that being generally mobile friendly is an important consideration in displaying their search results.

     Here are some completely unscientific hastily collected empirical results of my search engine rankings for some specific terms before and after implementing AMP.  I consider these results completely inconclusive but here they are anyway:

*** This one improved, but it hadn't even been re-indexed as an AMP search result yet!

     The time between these two samples is about 4 or 5 days, which is the time it took for the pages to start getting indexed by google, and for me to fix some of the errors I had when I first deployed them.  In addition, about 20 days prior to these initial search results being collected, I had an article trending (How to Get Fired Using Switch Statements & Statement Expressions) which got about 60,000 page views and was on reddit and Hacker News.  I find that when a page from my domain is trending, all of pages appear higher in search results, but this declines steadily once it is no longer trending.  Therefore, I would consider the data to be biased in a downward trend.  It is also true that my blog in general seems to have been trending up on a yearly basis in terms of search engine rankings.  I don't know if you can extract any useful information from these facts, but there they are.

     I should also point out that it's no longer adequate to talk about 'search engine position' because mobile results are now extremely dynamic with lots of multimedia, and various other things that can't be considered search results, but definitely obscure your result if you're ranking below them.

Pros and Cons of using AMP Pages

     I will list a few pros and cons of AMP pages here, but they're really moot points.  The world is going mobile and if you aren't as well then you're going to be left behind.

Pros

     Potential improvement in search engine rankings.

     You get lazy-loading of images for free.

     Page load times are times are faster for your users, and you basically get a CDN for free.

     Possible increase in conversion rates due to Google being smarter than you are and forcing you not to use those 50 jQuery plugins on your site for your own good.

Cons

     You've now got 2x (well not quite but almost) as many pages to maintain.  Converting your pages to be AMP compatible is not just a matter of sticking the lightning symbol in the HTML tag at the top and calling it a day:  In my case I like to use lots of inline style tags all over the place, and these had to be moved into the header style tag.  If that's not a problem for you, you've probably got some pages and/or a feature where the fundamental value proposition is something written in Javascript.  For example, one of my most popular articles, Virtual Memory With 256 Bytes of RAM - Interactive Demo uses a Javascript simulation of virtual memory, and that's one of the fundamental reasons why the page is interesting.  I believe I can make it work fully with AMP by using the iframe technique, but frankly I haven't even thought about taking the time to convert it.  I just put a link on the AMP version that links to the desktop version.  There are also a few small things like the fact that <form> tags are forbidden and you need to use a special version for AMP pages.  For now I just removed those features on the AMP view entirely.  The laundry list of things that you can't include on AMP pages is long, and I anticipate that it will be easy to accidentally push something (a single style="" for example) that completely breaks AMP compliance site-wide.  Just after writing this article, I accidentally broke AMP compliance for all pages after Desktop Google Analytics started requiring you to put the analytics script in the head tag (which I updated for desktop and AMP).  AMP pages require you to put the special amp-analytics tag inside the body section.

     You've now got 2x (well not quite but almost) as much integration work to do.  This was something I didn't really consider at first, but since the AMP pages will likely be a different document, you now have 2x as many files to deploy.  In my case, I chose to put the AMP pages on a separate subdomain, but you could also choose to name the amp document slightly different (using an 'amp-' prefix or something).  Either way, that's 2x more of something to think about.  If you use the subdomain approach, don't forget about creating new your testing stages before production!  If you use the filename approach, don't forget to set up URL routing!  You'll now need more configuration files, and don't forget about getting Q/A to at least glance at all of the permutations of:

• Non-AMP View on Desktop
• Non-AMP View on Mobile
• AMP View on Desktop
• AMP View on Mobile

     Don't forget to throw in the cross product of the set of browsers with the list above.  New configurations like AMP Desktop are probably ones you don't really have to think about much, but are you confident enough to just never look at it at all?

     AMP has its own special way to add google analytics, but even that too will means extra work:  Google says: "We recommend that you set up and use a separate Analytics property for AMP measurement."[8].  Now you've got 2x as many analytics properties!

Gotchas

     In this section, I'll list a few of the mistakes I made during the conversion that confused me a bit in case they are of benefit to you:

Don't Forget to add Structured Data

     The AMP page validator will give you a pass even if you don't have any structured data on your pages.  Structured data is what enables your pages to appear with all sorts of fancy multimedia presentations directly in the search results.  I'm not 100% sure that you need to add it in order to get indexed, but I got a notification from Google that it was missing, so I added it anyway.  The data looks something like this:

<script type="application/ld+json">
{
	"@context": "http://schema.org",
	"@type": "Article",
	"mainEntityOfPage": {
		"@type": "WebPage",
		"@id": "..."
	},
	"headline": "Interfaces - The Most Important Software Engineering Concept",
	"image": {
		"@type": "ImageObject",
		"url": "...",
		"width": 123,
		"height": 123
	},
	"datePublished": "2016-02-01T08:41:59-05:00",
	"dateModified": "2016-02-01T08:41:59-05:00",
	"author": {
		"@type": "Person",
		"name": "Robert Elder"
	},
	"publisher": {
		"@type": "Organization",
		"name": "Robert Elder Software Inc.",
		"logo": {
		"@type": "ImageObject",
		"url": "...",
		"width": 123,
		"height": 123
	},
	"description": "Interfaces - The Most Important Software Engineering Concept"
}
</script>

     You can get information on how many of your pages have AMP validation errors or structured data issues in the Google (search console? Webmaster tools?  They keep changing the name of this thing...):

Missing Markup

     In converting the images, I mistakenly wrote some of the amp image tags like this

<amp-img ... />

     instead of like this

<amp-img ...></amp-img>

     The result was that all markup after this image tag looked like it was missing from the page, and furthermore there were no AMP validation errors!  The only visible symptom was a mystery lack of content on the page.  What happened, was that the following content, had all been placed under the 'amp-img' tag and a </amp-image> followed it, so it was all stuffed into the image tag, so this:

<amp-img ... />
<div>Content after image.</div>

     would turn into this:

<amp-img ...>
	<div>Content after image.</div>
	<img amp-img-id="AMP_1" ...>
</amp-img>

     but validation wouldn't complain.

You Can't Use @charset "UTF-8" in Stylesheets

     The header says it all, if you try to use it you get a validation error.  In my case, I didn't really need it so I just removed it.

Sizing AMP Images

     Initially, I couldn't figure out the best way to resize to the screen width properly, but then I figured out that you can use layout="responsive" which seems to work pretty well:

<amp-img src="..." class="amp-interfaces" width="708" height="312" layout="responsive"></amp-img>

Disappearing AMP Images

     If you create an amp-img tag with layout="responsive", but don't put a height or width on it, it will disappear.  You should also get an error in the developer console.

Conclusion

     Complete AMP compliance is a lot of work, although you can skip it all if you don't mind being left behind in the dark ages.  There are still many more aspects to AMP such as the components; amp form tags, and all the other AMP specific analogues of markup that are disallowed on AMP pages.  I haven't even begun to look into this stuff, and I will probably avoid it for as long as I can.  There is just too much stuff to work on these days.

References

     [1] A new approach to web performance  "With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts."

     [2] amp-iframe

     [3] Components / Tags

     [4] Create Your AMP HTML Page "AMP HTML documents MUST: ...Contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag as the second child of their <head> tag (this includes and loads the AMP JS library)."

     [5] "inline style attributes aren't allowed."

     [6] "but you can’t reference external stylesheets (with the exception of custom fonts)"

     [7] "AMP Boilerplate Code" "Validation is currently done with regular expressions, so it's important to keep mutations as minimal as possible."

     [8] "Requirements" "Refer to the AMP Analytics spec on Google Developers. We recommend that you set up and use a separate Analytics property for AMP measurement."

Amazon Cloud Servers For Beginners: Console VS Command-Line Published 2017-03-20	$1.00 CAD Terminal Block Mining Simulation Game	A Review of the react.js Framework Published 2015-02-16	Learning Laravel and angular.js Published 2015-02-06
A Weird Old Tip About EC2 Instances Published 2015-02-07	D3 Visualization Framework Published 2015-04-21	Silently Corrupting an Eclipse Workspace: The Ultimate Prank Published 2017-03-23	XKCD's StackSort Implemented In A Vim Regex Published 2016-03-17