Is AMP for You? A Developer’s Quest to Enlightenment
In my last article, I ventured to create a really fast website from scratch. The website is conjugaison.xyz, a website for French verb conjugation lookup. Mainly built for myself, I used it as an experiment to write a website from scratch and make it really, really fast — below 1 second to load a page.
It allowed me to explore many avenues to speed up a website. Accelerated Mobile Pages or AMP by Google is one of those things. In this article I report what it is, how much effort it took me to adapt my website for AMP, and a list of gotchas for developers.
The case for implementing AMP
There is no denying it, loading websites on Mobile phones is slower than on Desktop yet users demand fast websites. According to a Google study, a landing page takes on average 22 seconds to load on an average mobile device on 3G. Horrible!
Why is that? First, the computing power is less on a Mobile device. Second, and most important, network connections are not all LTE. Using an average Mobile device on 3G slows things down.
To palliate against this limitation, Google has created Accelerated Mobile Pages or AMP. It is a cache of web pages loaded directly in search results. Viewing an AMP page is instantaneous because Google serves the user a cached page directly in Google Search. The user never leaves Google Search to visit to the actual domain.
This is of course self serving for Google. After all, they do want you to use Google Search. Google also wants you to perform more searches. What better way to make things fast to load. As such, speeding up the serving of a page from a search result is a win win situation.
There is however a lot of AMP controversy since you never leave Google when you click on an AMP page link. Instead of going to the website in question, Google keeps you on its domain. From that perspective, AMP is like a curating framework for generating content on Google Search. Can you imagine if all websites were AMP? A user would never have to leave Google Search to get content and answers. If that were the case, Google would have carte blanche to evolve the web and its standards as it would see fit. That is the fear many have.
Fortunately, that isn’t the case today. Nevertheless, in the SEO world, it has become a best practice to implement AMP.
Do note however that AMP is not a silver bullet (read on to see why). There is nothing more important than speeding up your website period. In fact, Google recently announced it will start punishing slow websites in mobile rankings in summer 2018.
What is AMP or Accelerate Mobile Pages?
AMP stands for Accelerated Mobile Pages. Its funny that it is often called AMP pages — the “pages” word is repeated twice :)
AMP pages are server-side rendered. Think of it as a web site cache on the Google network, worldwide. Like a CDN but instead of you pushing to it, Google will pull from your website to cache things.
Performance on mobile is key here. As such, lots of features you are used to are not available (i.e. javascript, forms, external stylesheets, etc). Most can be enabled with special syntax while others cannot.
No external stylesheets are allowed. CSS must be inlined in the HTML page and limited to 50kb in size.
AMP pages are HTML compatible. Meaning that you can either build an AMP-only website and it will work everywhere. Alternatively, and the most common route, you can build AMP-specific versions of pages from your website. Essentially complementing your website with AMP.
AMP pages are served only on Mobile Phone devices. You won’t see them on Desktop or Tablets.
AMP has a lot of documentation. You can find a step by step conversion guide under www.ampproject.org. Also, Shopify has a great article on AMP pages. Finally, if you find AMP lacks a feature you require, the project is open source — you can contribute to adding it.
Converting my website to AMP
After an initial read, lots of things were compatible with my website. For one, conjugaison.xyz has no Javascript. However some changes were necessary. Let’s go through them one by one.
CSS
Not being able to load an external CSS file is a problem. Furthermore, the CSS is limited to 50kb yet my Bootstrap sums up to 81kb. Yikes!
There was only one solution to this problem. I had to strip out unnecessary CSS. What I ended up doing was copying the essentials of the Bootstrap typography and grid classes I was using. I wrote custom HTML and CSS for the navbar, form and button. Final CSS size became 6kb. Tenfold improvement. Nice!
Finally, I inlined the CSS in the head section of the HTML file. Here is the full head section of the HTML document.
Custom Font
My website uses a Google Font called Courgette. It makes the website a lot more fun. It does however require an external CSS file. Fortunately, AMP pages makes an exception and allows loading external fonts for white-listed origins including fonts.googleapis.com. This allowed me to include the font with this line in the head section:
<link rel=”stylesheet” type=”text/css” href=”https://fonts.googleapis.com/css?family=Courgette">Form
As I mentioned before, my website has a form to perform a search of a verb. Well AMP Pages forbids them out of the box unless you include the amp-form extension by adding this line to the head section:
<script async custom-element=”amp-form” src=”https://cdn.ampproject.org/v0/amp-form-0.1.js"></script>Note: Kind of ironic that AMP pages forbids Javascript, yet it requires the page to load its own Javascript to enable some features.
Google Analytics
Finally, there is the analytics part essential to track usage of the website. Here too an extension is required. It is called amp-analytics.
Other dynamic elements
AMP pages offers extensions for a number of dynamic elements you would typically have on your website. From dynamically loaded lists, to GitHub gists, to Mustache templates, etc. You can find a full list of amp extensions here. Furthermore, AMP pages is an open source project. You can contribute your own extension on the ampproject GitHub repo.
AMP Validation
AMP page validation comes out of the box. One simply needs to append #development=1 to an AMP page URL in order to run the validator on any AMP page. The console will log any errors and give you hints to fix them. For example:
In most cases the validator provides clear hints for fixing the errors. However, the one shown above was particularly misleading. It says “The mandatory text (CDATA) inside tag ‘head > style[amp-boilerplate] — old variant’ is missing or incorrect.” In my case the error was wrong as I did include the amp boilerplate inline style tag.
What was missing however was the amp-custom attribute on my inline CSS style tag. The open style tag must have the following attribute:
<style amp-custom>When all is right, the validator will give you an ok:
Verifying AMP page on Google
On my iPhone, I googled “conjugaison xyz” and obtained these results (left). Notice the flash symbol near each search result — that indicates Google indexed those pages as AMP pages. Clicking on the first result doesn’t load my website — instead it loads the cached AMP version on Google (right).
How does AMP load the page so fast?
Clicking on an AMP result does not load the website in a new page. Instead, Google performs an AJAX call to display the cached AMP document. That’s why it’s so fast. Google also prefixes the document with a header and buttons. There is a link to open the real website and a close button to allow you to get back to the search results.
Google also changes the URL to ensure a page refresh loads the AMP page. For example here is the URL in the address bar for the above page:
https://www.google.ca/amp/s/conjugaison.xyz/verbe/dire
If you load that on desktop, it will redirect you to the website. However in Developer Tools you can emulate a mobile device and paste that link, the tricks behind the magic get exposed as shown in this screenshot:
You’ll notice it took 6.69 seconds to load that page. But that is not representative since is a fresh page load from both Google (www.google.ca) and the AMP page. In real life, you’ll be on Google Search on your Mobile. So you will already have taken the hit of loading Google and all related assets. When you actually click on the AMP link, its lighting fast — below half a second.
This leads me to pointing out a few gotchas for developers as they test their AMP pages…
AMP gotchas
As I mentioned, AMP is no silver bullet. As a developer, you need to be aware of a few gotchas.
Gotcha #1 — AMP page slows down my website
In January 2018, Google announced that it is starting to punish slow Mobile websites in rankings. It did so already on Desktop for a while now.
The funny thing is that AMP-only websites slow down on mobile when loaded standalone (not through Google Search). Extra assets get loaded for every page load to handle AMP. To demonstrate this, I added a switch to turn off AMP on my pages ?noamp=1. I was able to compare load times using Lighthouse, the newest Audit tool in Web Developers found in Chrome. I ran this on my laptop tethering my iPhone 6 on LTE.
Left is with AMP, and right without AMP. Without AMP, it takes 2.2 seconds to interactive. With AMP, it jumps to 3.6 seconds. This degradation comes from loading Javascript files to activate AMP features. This pushes out the first meaningful paint of the page from 1.5s to 3.6s.
The conclusion here is to avoid creating AMP-only pages. Instead, have AMP versions of your pages and tell Googlebot where those are. That way you get the best of both worlds. To make your AMP page discoverable you use link meta tags.
On a non-AMP page, you specify an AMP page exists:
<link rel="amphtml" href="/article.amp.html">On an AMP page, you tell Google where the original page is at:
<link rel="canonical" href="/article.html">Gotcha #2 — AMP pages not appearing on Google Search
It takes some time for your AMP page to appear on Google Search. And as Gary Illyes from Google pointed out in 2016 not long after AMP came out:
In general the same applies on AMP results as on normal web results: we have to crawl and index the page in order to show a result for it. Depending on the site this can take from a few minutes to days, but most of the time it’s pretty fast.
Source: Search Engine Journal
For me it took a few days for my first page to appear in Google Search Console. The one page AMP indexed was the home page of the website — the list of all verbs. What about the actual conjugated verb pages — the true content? In total I had 1,963 pages submitted via my sitemap and Google did index them all. But only one was showing up AMP indexed. This had me worried.
During my investigation, I used Google Search’s AMP Test feature to make sure my page was valid. There was a “Submit to Google” button so I pressed it. That added the page to the AMP cache. The page then appeared in the AMP index. However, the day after it disappeared from the AMP cache. That explains the bump in the above graph.
This could be seen in search results as well. On the left is the lookup for verb “finir”. It is not in the AMP cache. Yet the home page is. After running validation, the page finally appeared in the AMP cache as shown on the right. The day after it was gone from the cache.
This leads be to believe that Google only adds pages to its AMP index when they appear often enough in search results. Otherwise, they get knocked out of the AMP index. This kind of makes sense. After all, AMP is just a big cache on Google Search. And as we developers know, you don’t cache information that is not being used.
This is however concerning because as a developer I spent a lot of effort to implement AMP without any guarantee of my page being added to the AMP index. Bummer.
Gotcha #3 — AMP does not equal improved rankings
On the SEO aspect of AMP, I turned to SEO expert Samuel Lavoie. According to him, contrary to common belief AMP will not give you a ranking boost.
Currently AMP do not provide ranking boost but rather a visually enticing AMP blue logo in the SERPs (Search Engine Result Pages). As opposed to the upcoming Page Speed update in summer 2018 which will demote pages that delivers slow experiences on Mobile. I think devs and webmasters should focus on optimizing their First Meaningful Paint rather than deploying AMP.
Gotcha #4 — AMP is not for every website
Samuel goes further reminding me that AMP was built for a specific type of website:
I do not suggest going full-on AMP except for some publishers and only for their breaking news content. Although AMP is great for the Web and users, it is still too much under Google’s ecosystem (even using google.com as your urls until next summer) and give limited options for publishers. I see the current AMP iteration as an experiment and something that will fade away to a more sustainable approach; reward fast and mobile friendly websites no matter the technology stack being leveraged.
He raises a good point. In fact the AMP project specifically states that AMP was built for Publishers and Advertisers. Does your website fall in that category?
Conclusion
There you have it, a deep dive into AMP from a technical perspective, spiced up with SEO wisdom. To summarize:
- From a development perspective, implementing AMP takes time and effort. You’re best to create a 2nd version of your website which is AMP. Avoid having an AMP-only website like I did.
- AMP won’t boost your rankings and will keep the user on Google’s domain — not yours.
- AMP was built for Publishers and Advertisers. If you’re site is an online tool, not the best fit.
For the majority of websites out there concentrate on making your website really fast instead of implementing AMP. You have until summer 2018 to speed up your website on mobile. After that, Google will penalize you in rankings.
Be wary of articles out there that say AMP improved their website stats (page rank, time on page, bounce rate). They are usually comparing their original slow pages against sped up AMP pages. That is not an apple to apple comparison. I believe the faster load times is the reason for the boost — not AMP. AMP just happens to force you to speed up your website.
Then again, as a developer maybe dropping the AMP buzz word to management is enough to grant your team that 2-week sprint necessary to speed up the website. If that psychological trick is what it takes, then by all means, AMP it up!
Thank you to Samuel Lavoie and Thibault Duval for having read and provided feedback on this article.
