AMP stands for Accelerated Mobile Pages, and it represents Google's attempt to radically improve the speed and accessibility of the web for a rapidly expanding number of mobile devices. AMP was an open source project initiated by the Google search team in the hopes that Android users would open up a Chrome browser, perform a search (using Google of course) and be presented with a bunch of AMP based results.

This is leading to some rather spectacular claims from the Google team*, the suggestion is that a search that leads to an AMP results leads to "...under 1 second median load time. Measured across all AMP pages loaded from Google search" (711 ms to be exact). Clearly median results are not mathematically all inclusive so it is also important to note that almost all pages (up to 99th percentile with big pages, slow connections, etc.) see a dramatic improvement, 99% of AMP page loads are faster than 8 seconds (Non-AMP control group loads in 22 seconds on average).

It is important to note that even given these promising results for those of us who are developers with an ability to fine tune a website, you will in all likelihood be able to create a site that is faster than the equivalent AMP enabled page. AMP is trying to solve a broad set of problems by establishing some very basic guidelines, this does not absolve us of the need to create responsive and user friendly interfaces for all device types.

Solving Slow Rendering

Font rendering in any browser can be one of the most time consuming portions of displaying the page, and this is because it is part of the critical rendering path and it only occurs after styles are applied to the page, and it is only after the download of the font that the browse will allow the page to be displayed to the end user. The steps are roughly as follows:

  1. Download CSS
  2. Download JavaScript file (and more styles if necessary)
  3. Apply styles to the page
  4. If text exist that requires a web font only then download that font
  5. Render page only after the web font download is complete

This cautious approach to downloading web fonts (Chrome, FireFox and Edge waits a max of 3 seconds, Safari will wait longer) can have an overwhelmingly negative impact on your load times. What other things normally block rendering? Style sheets and synchronous scripts, stuff that looks like this:

<link rel=stylesheet>
<script src="…">

AMP takes these minimum requirements and use them as basic set of AMP rules, styles are then required to be in line, and scripts become asynchronous, resulting in no additional HTTP request in the critical rendering path, you HTML will then look more like this:

<script async src="…">

Now to those of us who have had to deal with async loading you know that you cannot necessarily rely on the resource you are attempting to load being there on time. It is also possible that a temporary network outage means you never get your asynchronous resource request. To get around this AMP pages require you to input some boilerplate styles (partially shown below) that provides CSS animation as a timeout, that is to say "make the content visible after 8 seconds regardless of other required downloads".

<style amp-boilerplate>    animation: -amp-start 8s steps(1,end) 0s 1 normal both
@keyframes –amp-start {
    from { visibility:hidden } to {visibility:visible }

It provides a rather simple and elegant failsafe.

Converting dasBlog

dasBlog has always contained the concept of mobile pages, designed to detect and display a page based on a known set of mobile device types. We used that concept to create a set of templates that would pass an AMP validation test, here are the very basic requirements to pass that test:

  • Start with the doctype .
  • Contain a top-level tag.
  • Contain and tags (They are optional in HTML).
  • Contain a tag as the first child of their tag.
  • Contain a