Accelerated Mobile Pages

AMP : A NewAn Old Approach to Web Performance on Mobile

Like everyone else in the business, I read with interest the announcement regarding Accelerated Mobile Pages. This makes the claim:

"AMP HTML is a new way to make web pages that are optimized to load instantly on users’ mobile devices."

The "How it Works" page goes on to say:

"We began to experiment with an idea: could we develop a restricted subset of the things we’d use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance? That experiment has culminated in a promising proof of concept we call Accelerated Mobile Pages (AMP). AMP HTML is built on existing web technologies, and the documents written in it render in all modern web browsers and web views. "

There's some hyperbole here - this is not a new technique at all. Indeed, it's fair to say that the mobile revolution was kick started by a group of engineers who had near enough exactly the same insight as this "new way". Those engineers were at NTT, the product was launched by NTT DoCoMo, the subset of HTML adopted was called cHTML (compact HTML), the product was branded iMode and it was a tear-away success. IMHO, the content business model associated with iMode can also be fairly said to be the progenitor of the App Store. But that's for a different day.

cHTML?

In about 2001, there was a beautiful article in the NTT Technical Journal (English) describing why it was the cHTML was created. It's a long time ago (and I can't find the article online), but as I recall there was an oh-so-polite take down of the alternative standard for mobile web pages WAP.

My recollection is that the journal stated "we read the WAP specification and couldn't understand it, so we created something fit for purpose". So that's based off a 15 year old memory, but I think it captures the gist of what was said.

cHTML was designed with small screens, low-bandwidth, limited (four way) navigation, low device memory and low CPU in mind. Cleverly, cHTML also defined a set of icons and emoji that were guaranteed to be on the device and thus eliminated a whole range of secondary network requests.

cHTML was compact, efficient (compressed pages could often fit in one network packet), fast, worked well on tiny screens (aided by the information density of Japanese characters).

AMP?

The team that wrote AMP asked themselves

"could we develop a restricted subset of the things we’d use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?"

Now clearly AMP is not cHTML, but there is an element of back-to-the-future here. But enough sniping, this really does solve some major problems.

I have written before about my hatred of reflow after I have scrolled a document. The AMP authors have gone-to-town on this issue and that's truly great news:

"Resources must declare their sizing up front"

This is just what the doctor ordered - in detail:

"the aspect ratio or dimensions needs to be inferable from the HTML alone. This means that after initial layout, an AMP document does not change until user action. An ad at the top of the page can’t suddenly say: “I want to be 200 pixels high instead of 50.”

There's more, but, to my mind, nothing as important as that last requirement. The 'more' includes, for example, restrictions JavaScript, CSS file size, CSS selectors, CSS transitions and animations. In addition, a whole lot of HTML tags are verboten. 

Final Thoughts

I'll draw one other comparison, the exorcism of Flash from mobile devices, just as it was gaining a toe-hold.

Flash (Lite) on mobile was big news in 2005-2006. Why the fall from grace? The problem was not necessarily Flash per-se, but how authors used it, particularly for ads delivered the desktop. At Phidget, I had plenty of first-hand experience of third-party Flash content where campaigns were needlessly bloated and ActionScript regularly used in tight loops that consumed 100% CPU. (One imagines this was all down to production budgets - when a piece is commissioned, I don't imagine that optimisation entered into the brief.) Whereas ad industry bodies published best practices for Flash authoring, in my experience, these were widely ignored.

Led by Apple, Flash was banned first on mobile and is now widely acknowledged to be the bad-guy on the desktop and on mobile. (Awful security does not help either.) Result: it's now into its dotage.

Another way to look at AMP is that it's a set of restrictions applied to limit the worst excesses typical practices employed by publishers who have decided to screw the experience in favour of the revenue. This is where I draw a parallel with Flash - rich campaigns with Flash were a major factor in the death of Flash as a means to create rich campaigns. Substitute the words 'ads injected by JavaScript' for 'Flash' and you have the contemporary problem that AMP seeks to solve.

AMP, like cHTML before it, has created a framework that acknowledges the user experience.

Google's backing is key here - if they prioritise AMP pages in search results, the world will be a better place as a result - SEO ranking changes will cause trickle down changes in the publishing industry.