This post originally appeared on the TES Engineering Blog.
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:
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.
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.
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.
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:
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.
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.