So Google, a group of publishers and others have launched Accelerated Mobile Pages (AMP)
AMP promotes the goal of a faster mobile web which is something I think we’d all like to see.
If you visit g.co/ampdemo on a mobile, and search for ‘Obama’ there’s no doubt the stories in the carousel come up fast, and moving between them is slick too. The demo isn’t available in all regions yet so Addy Osmani posted a demo to YouTube.
Similar to Google’s Instant Pages, AMP relies on pre-rendering and caching to make the pages load instantly.
Where AMP differs from Instant Pages is that it forces developers to use custom elements for images, audio and video, and limits some of the other web features a page can use (only AMP supplied JS, limited CSS features and with exception of button no form elements etc.).
There’s plenty in the documentation about what technologies are allowed or not allowed, but there’s less information on why these choices were made.
And I wonder how much this lack of information and the project’s relative immaturity, coupled with being backed by Google contributes to the unease we feel with it at the moment.
Tim Kadlec has already discussed whether the incentives publishers have to adopt AMP conflict with an open web and I’d really recommend reading his post.
After a few days of testing AMP based pages, reading the GitHub Repo and other docs it’s clear AMP aims to be a set of custom elements and rules to enable pages to be pre-rendered quickly and easily – a set of constraints to protect us from our own excesses.
Some of the AMP components such as img, audio and video, are replacements for their HTML equivalents but control asset loading more finely (and of course dispense with optimisations like the browser pre-loader).
Others provide new features such as carousels or wrap 3rd party services. Let’s face it there are plenty of poorly implemented carousels and 3rd party scripts out there so applying an external quality control over them is welcome.
But does AMP really deliver in performance terms?
Is it really faster?
The AMP Project reports speed improvements of 15-85% (using SpeedIndex as their measure), but as we don’t have their data or methodology it’s unclear how much these improvements rely on pre-rendering and caching.
Testing AMP pages (without the benefit of pre-rendering) vs their existing equivalents shows something of a mixed picture.
- The Guardian
(The top set of images is the current Guardian site, and the bottom the AMP equivalent)
(The top set of images is the current Buzzfeed site, and the bottom the AMP equivalent)
In the BuzzFeed examples the AMP version is generally faster with the exception of the test that involved no network shaping.
The picture for The Guardian is reversed, over slower networks the current site starts rendering sooner but generally always finishes after the AMP version. The exception is the test that involved no network shaping where the AMP version is noticeably faster.
The current Guardian site makes over 100 HTTP requests per page, and the AMP version only 9. The effort The Guardian's developers put into performance clearly is reflected in the results.
Note: The current Guardian site uses HTTP, whereas the AMP version uses HTTPS which will affect the result with some TLS overhead.
What about progressive enhancement?
From a browser support perspective the pages work in every browser I’ve tried - Chrome on Android, Safari on iOS and even Opera Mini (with a few minor quirks).
One thing you might notice from many of the AMP tests is that with the exception of media there’s little progressive rendering; the content just appears to pop onto the page, this is by design…
The head of each page contains a style block that sets the whole page to be transparent