This post originally appeared on the TES Engineering Blog.
Accelerated Mobile Pages are normal stuff of the web in many respects - publicly reachable via a URL, viewable in any browser, built with HTML, CSS and Javascript.
The difference is, they load almost instantly on mobile - music to the ears of anyone who's waited 10 seconds for a page to load over 3G (all of us, then).
More information is on the AMP project website.
The payoff if you make an AMP version of your page
- SEO - AMP pages can be served higher up Google search results, for example in the carousel of article stories that you sometimes see when googling for news.
Speed - the page will be stored automatically by Google onto their AMP cache which is used by Google search, giving near-instant page load speeds when a user clicks through to it from search results.
What makes a valid AMP page?
To ensure AMP pages are lightning quick, some quite heavy restrictions are in place:
Javascript
You can't use any of your own Javascript, either external or inline. You must load the 'AMP runtime' script from their CDN, which controls the loading order of various page elements. For additional commonly-used functionality like analytics, image carousels or iframe ads, there's a selection of scripts authored and hosted by the AMP project.
In summary, you can achieve some lightweight interactivity, but this restriction drives home the point that AMP is intended for mainly static, content-focussed pages.
AMP sees heavy overuse of Javascript where it's not really needed (eg in the delivery of static content to the user) as the enemy of a fast mobile web. They explained their decision to ban custom Javascript in an introductory blog post.
HTML
You have to use AMP versions of some common tags eg. <amp-img> instead of <img>. This gives the AMP runtime script the ability to control the loading order of external assets like images and video.
CSS
No external CSS is allowed - it has to be inlined into a single <style> tag in the page, and can't total more than 50Kb. Read on for details of how we got the CSS under this limit at TES.
Fonts
Web fonts have to be loaded from an approved CDN eg Google fonts.
Our first candidate - the TES job page
The first tes.com page we decided to AMP-ify was the job page.
It's a great example of a page that is all about the content, light on interactivity, has significant mobile traffic, and welcomes the best SEO ranking it can get.
Reducing CSS below 50Kb
We don't have tonnes of base CSS at TES, but we do have more than 50Kb - to get our AMP pages to validate we'd have to slim this down.
My first attempt at this was to use the Critical CSS library which automates the process of launching the job page in a browser (PhantomJS), extracting only the CSS that is actually needed to render the content and saving that out to a file which you can then inline into your AMP page.
This technique did work but had some flaws:
For our existing pages, we have build processes (we use Gulp and Webpack) to generate compiled Javascript and CSS; these builds run on our CI server and the resulting file are then deployed through to production. These build processes transpile and bundle static files. The critical CSS process is different, it requires a fully rendered copy of the page to be launcheable in a browser - not so simple to set up on CI.
The extracted CSS is based on what PhantomJS renders, which may not be the same as other browsers. But the extracted CSS has to work in all target browsers. For example any extracted CSS will contain vendor prefixes applicable only to PhantomJS - any equivalents for other browsers must be added as an additional step (we used gulp-autoprefixer).
We've since moved to a more scalable (and generally useful) pattern - make our entire CSS codebase completely modular - everything is either a component (corresponding to a UI widget like a button, panel or form input) or a utility (spacing, typography, grid, icons).
The key is granularity - if we break things up finely enough we can compose the CSS for any page with little wastage, making it much easier to stay under AMP's 50Kb limit. This approach reduces the weight of all our pages, AMP and otherwise.
It also means we can continue to build our CSS from the SASS source files on our CI server.
Javascript
It was a double-take moment to read in the AMP spec that you can’t use any of your own Javascript. But I’m personally in favour of this, it encourages you to consider progressive enhancement as a strategy - eg if your forms work without Javascript you’ll have the choice to enhance them with an XHR post or leave them as-is. Either way, your transition to AMP validity will be an easier ride.
The job details page has a photo carousel - the amp-carousel was easy to swap in. It also showed a map using the Google Maps static API. We switched to an embedded interactive map using amp-iframe.
As we AMP-ify other content pages that have more complex Javascript running in the browser, we’re considering making the AMP version much simpler and linking through to the ‘full fat’ page to access all features.
Results
The AMP pages took a couple of weeks to start appearing in search results. We wondered if this was due to the Google Search Console reporting that structured data was incorrect in our pages (we’d applied JobPosting) but the individual pages validated and those warnings seemed erroneous.
When the pages eventually started appearing they strangely only turned up in searches conducted from google.com, not google.co.uk. We’re still waiting for this to change.
Seeing the page load instantly from search results is an ‘it was all worth it’ moment. They might not always be completely instant but are generally fully loaded in under a second - far faster than non-AMP pages. Using the mobile web is nothing short of painful for many users, so the AMP initiative is a big step in the right direction, and purports to keep its spec open source.
This was the third in a series of posts about improving page performance. Part 1 discussed what we're measuring and how, and Part 2 was about optimising hero images.
A video of me talking about the performance issues discussed in this post.