Recently Google released the Accelerated Mobile Pages Project.
This open source initiative defines AMP HTML, a way to build web pages for static content that render with reliable, fast performance.
In this blog post I'll try to explain what it's really all about.
What is it?
AMP HTML is a way to build web pages for static content that render with reliable, fast performance. It is our attempt at fixing what many perceive as painfully slow page load times – especially when reading content on the mobile web.
To make up for those limitations AMP HTML defines a set of custom elements for rich content beyond basic HTML. For more info on how AMP HTML works, and some insights into the design, please read our blog post "A new approach to web performance" (which may be the first AMP HTML file you ever see :). We also have a non-technical description of what we are doing on www.ampproject.org.
So basically it's a subset of HTML, meant to render pages really fast and unobtrusively - serving critical content as fast as possible.
What are the ups?
AMP is not a standard meant to replace HTML; it is a set of conventions to speed the browser’s work rendering the HTML. A few things to keep in mind:
- Rendering an AMP page actively enforces their guidelines. (If ANY of them fail, the page will not render at all, it will show an error instead.)
- All elements on the page have to declare their size up-front so the layout can efficiently be computed once, and not cause a re-layout that may potentially cause the reader to lose his position on the page.
On the plus side, this makes any AMP page render its critical content _really_ fast. We're talking maximum 2 seconds on a 3G network here.
Most of the speed benefit would seem to come from managing the page-loading process to show the above-the-fold content ASAP, while most of the heavy lifting waits until the reader actually sees the page.
One of the side effects of the AMP project is that it sets a standard. "Is Company X abiding by Google guidelines"? If they serve AMP pages, they do. Guaranteed. If they don't, the AMP page wouldn't even render...
You could almost say it's a sort of quality label for speedy pages.
AMP is also a response to the ad blockers challenge. As of today, the system does not prevent any removal of promotions by ad blockers’ software.
But AMP is reformatting ads in a non-intrusive way —a static presence that does not ruin navigation. As such, it could be a major first step towards an “acceptable ads” policy that sounds like the only way out of the problem.
AMP allows you to maintain two different versions of your webpages (HTML and AMP HTML) or just convert entirely to AMP (but the latter may not prove to be as practical for just any page).
You could theoretically create an AMP version of your content pages, with a canonical header link like this:
<link rel="amphtml" href="<amp link>"> - and use those for any AMP consuming app (or sharing mechanisms?)
P.S: Google said it won’t prefer AMP pages over non-AMP pages - I guess that's a plus.
What are the downs?
It's pretty damned strict.
AMP HTML documents MUST...< a lot of things>
I thought we’d done XHTML Strict once already and decided it was a bad idea
If you want audio, video, or images on your page, you must use elements like amp-audio, amp-video, and amp-img.
In the case of images, I can see how this is a way of getting around the browser’s lookahead pre-parser (although responsive images also solve this problem).
In the case of audio and video, the standard audio and video elements already come with a way of specifying preloading behavior using the preload attribute. Very odd.
I’m not sure if this is solving anything at the moment that we’re not already fixing with something like responsive images.
Optional elements are great (web components!). Required proprietary elements? Not so much.
Doesn't sound like a subset of HTML when it's prohibiting the use of standard, basic HTML (even form and input elements - really?)... That’s forking HTML.
AMP essentially asks you to build an alternative version of your page that strips out not just anything that’s slow, but anything that might be slow.
You know how ad blockers block all ads, whether they’re perfectly reasonable or aggressively terrible?
Can it solve the problem it's trying to solve?
For most of the sites out there, the difference between their regular HTML pages and the corresponding AMP versions will be pretty significant.
That’s because the regular HTML versions are bloated with third-party scripts, oversized assets, and cruft around the actual content.
There’s nothing revolutionary about this.
The Google caching is notable in that it is free, but other than that it appears to be nothing more than what any CDN can do for you.
You can build your sites to be pre-rendered and to be cache-friendly.
You can carefully select your HTML and write your CSS with the goal of performance in mind.
You can do all these things all by yourself. And in fact you should be doing all of these things.
It does solve a problem, in that using AMP will guarantee a fast page - and if it were to become very popular, we would all have a much faster web.
At the very least, the AMP project (hopefully) helps raise awareness that on average, we can do a much better job of serving performant pages.
Following best practices is a must, but I personally do not believe enforcing a rigid set of them is the only way to serve fast content pages.
The overhead of tooling, knowledge and experience required to pull off similar sort of performance wins (like 15-85% better speed index) is very high.
But that's why, for quality websites, expertise is needed. Speed is our responsibility as web developers.
I will not be using AMP (much); but i will be keeping the best practices that shape it in mind - as always.