AMP

A short while ago, I discovered "AMP", a new top-secret acronym (it gets exhausting, in the long run...) for "Accelerated Mobile Page". This very fine initiative from Google - a company known for its philanthropy - aims to drastically improve the mobile web experience. And yet, it deserves some consideration.

---

The idea of adapting the web to mobile devices, with their limited capabilities and their reduced screen sizes, is nothing new. One of the first serious attempts was none other than the WAP, a technology parallel to the traditional Web that aimed to offer a semblance of the Internet to mobile phones over the limited networks of the time. Developing WAP content could barely be compared to developing a website.

The democratization of Internet access on smartphones initially pushed web craftsmen towards dual development: a traditional website and a mobile website. This terribly costly approach (development, maintenance, ...) generally failed to satisfy mobile enthusiasts, since the versions intended for them were often limited in functionality. Then came responsive web design (RWD, also called "responsive design"), driven by the adoption of Media Queries((CSS instructions that make it possible to adapt a site's layout depending, among other things, on the width of the screen displaying it)). That was in 2009. Since then, websites compatible with mobile devices have become legion.

RWD is not a miracle solution: by default, it merely changes a page's layout, but the resources it contains (images, scripts, various multimedia content) remain the same. Everyone is in the same boat, whether it be a computer enjoying a fast connection or a smartphone with a limited data plan and a mediocre transfer speed. One concrete example, among so many others: a 1920 * 1200px image, designed for a desktop computer, will uselessly weigh heavily for a simple smartphone that will only display it small. My blog is a good example of this, incidentally. When you think about it, the waste is staggering: useless traffic on the Internet, useless downloads (and therefore display delays) on the smartphone, unnecessary strain on the device's memory, and so on.

To counter these limitations, JavaScript solutions have been put in place. One can for instance delay the display of images depending on their position on the page (lazyloading), or send adapted resources by first analyzing the device's capabilities. These solutions require the use of a JavaScript library whose size must be kept small so as not to delay its execution. Even more interesting, the evolution of the HTML language will fill part of RWD's limitations: the famous < picture > tag illustrates this idea, since it allows you to specify different image sources from which your browser will select the most suitable. This spares us the execution of potentially too resource-hungry JavaScript code, by letting the browser natively manage the choice of resources. These new web standards are pushed by the various groups responsible for them: the W3C, or the WHATWG.

---

It is into this fast-evolving landscape that Google arrives with its AMP, a subset of HTML dedicated to excluding all the elements that are disproportionate for mobiles. You write an AMP page like an HTML page, except for a series of tags deemed problematic by Google. Among these, let us mention the < script > tag, as well as the famous < img > tag - replaced by < amp-img >. The sole exception to these rules: the AMP script, which is precisely what translates the custom tags into standard HTML. Google also takes the opportunity to suggest the use of Google AMP Cache, servers dedicated to storing your AMP pages' resources in order to serve them to your visitors as fast as possible. A service offered "free of charge, Google-style". The Mountain View company specifies of course that AMP primarily targets newspapers and other blogs, rather than web applications that necessarily require JavaScript code. When you think about it, AMP could appear as some kind of evolution of RSS, where the content of a complex site is projected into a simpler context. Except that here, it is the site that decides on the appearance of this context, rather than the end user.

Fair enough.

AMP raises several problems for me.

The first is that we are going back to a separate development logic for a site's mobile version and traditional version. Admittedly, creating an AMP page can in no way be compared to a dedicated mobile version from the 2008-2010 years: we are talking about a simple HTML page without complex content, whose layout remains modest. But every change you make to your graphic identity will have to be carried over twice.

The second is more political: why on earth does Google, which nonetheless spares no effort to improve web standards, show up with a bastard solution that will sooner or later have to give way to the actual standards((For example, < amp-img > works essentially as an alias of < picture >.))? AMP looks to me like a band-aid applied to a wound destined to heal on its own. Hard to get enthusiastic about that.

Finally, for all that AMP is an open-source project, it is essentially driven by Google. If needed, here are a few reasons to worry about it:

• Product placement, such as Google AMP Cache
• Unilateral decisions about the web's evolution, without going through the regulation of a "neutral" entity
• The abuse of a dominant position in general, since Google plans to favor "mobile-friendly" content in its search results. And nothing is more mobile-friendly than AMP, according to the Google engineers...

All these reasons make me doubt the relevance, as much as the legitimacy, of AMP on the web. Yet I confess that having a current framework to slim down mobile pages remains tempting. For the time being, and since version 0.10, Ghost enforces an AMP version of its articles. Out of curiosity, you can access the AMP version of any of my articles by adding /amp at the end of its URL. Within a few weeks, I will decide whether it is better to disable it, keep it, or even improve it.