Que penser de Google AMP (Accelerated Mobile Pages) ? (2016)
Accelerated Mobile Pages Project, AMP en plus court, est considéré comme la réponse de Google au format Facebook Instant Article. Gratuit et en code source ouvert, ce framework est destiné à créer des pages pour mobiles plus rapides à charger, ce qui est fort louable. L’incitatif principal pour les éditeurs est la promesse de Google de mieux classer les pages qui se chargent vite dans les résultats de son moteur de recherche.
Concrètement, AMP est un framework restrictif associé à un modèle de diffusion dynamique. En effet, Google n’a rien d’inventé d’extraordinaire : pour des pages plus rapides, il faut avant tout retrancher dans les choses à charger.
Nous savons bien que ce qui ralentit les pages aujourd’hui, c’est en grande partie cette avalanche de javascripts, notamment ceux qui vous traquent au bénéfice des markéteurs. AMP propose donc une solution des plus simples : le format n’autorise pas ces scripts, ni aucun script sur mesure, ni aucun script provenant de tiers. Wow. Nous sommes impressionnés par tant de génie radical.
Pour le reste des “ralentisseurs”, la réponse de Google est similaire. La couche de design est-elle souvent lourde à charger? Et bien, c’est fort aisé à résoudre : il suffit de couper dans le design… Dans la pratique, et par exemple, les déclarations CSS sont obligatoirement inline (dans le code HTML) et sont limitées à 50 Ko, et seuls des scripts asynchrones (scripts téléchargeables en arrière-plan après l’affichage de la page) préapprouvés sont possibles.
Si vous aimez les librairies JavaScript style jQuery, Bootstrap, Angular, React, pas de chance; vous êtes limités à une seule librairie de fonctions de base : AMP JS. C’est là que l’on comprend bien qu’AMP est dédié avant tout aux pages statiques de contenu, du style articles de presse. Oubliez ainsi AMP pour tout ce qui pourrait ressembler de près ou de loin à une application Web.
Pour ce qui est de la publicité, elle ne peut être affichée que dans un tag amp-ad et ne provenir que de réseaux soigneusement sélectionnés, comme Google AdSense par exemple. Ce qui facilitera sans doute grandement le travail des bloqueurs de publicité.
Des louanges
Expérience utilisateur
S’il y a manifestement un bénéficiaire avec AMP, c’est l’utilisateur. Oui, des pages plus sobres et débarrassées de la plupart des traqueurs et publicités sont plus agréables à consulter et bien plus rapides à charger. Il y a donc de fortes chances que l’utilisateur consulte plus de pages sur un site AMP. Tout comme il le ferait sur un site mobile classique qui serait bien réalisé et optimisé.
Des critiques
Fragmentation du Web
Facebook Instant Article, Google AMP, Apple News, et demain sans doute d’autres… pour un bénéfice discutable… on peut s’interroger sur la pertinence qu’il y a à multiplier les formats.
Concernant l’initiative de Google, notons qu’il n’est guère compliqué de faire avec HTML/CSS des pages dédiées aux mobiles tout aussi rapides, et même plus rapides qu’avec AMP. D’où la question : y avait-il vraiment nécessité à créer un sous-ensemble non standard d’HTML pour faire du mobile efficacement (si ce n’est pour encadrer strictement la nature des contenus, et priver les éditeurs d’une part de leur liberté quant au choix de l’apparence de leurs articles et de la façon dont ils les monétisent)?
La multiplication de ces formats plus ou moins propriétaires, va aussi rendre la vie difficile aux éditeurs. Plutôt que de créer une seule version mobile, un éditeur doit décliner une version par canal de diffusion, sous la menace plus ou moins claire d’être “puni” (contenus moins mis en avant par un canal). Bien sûr, Google s’en défend par la voix de Dave Besbris, le VP qui supervise le projet : non, Google n’offrira pas de traitement de faveur aux pages AMP (ce qui permet de mettre en question leur intérêt). On veut bien le croire. Mais dans les faits, c’est le contraire, les pages AMP ont une mise en valeur sur Google Search, notamment avec une présentation en carrousel pour les articles de sites de presse, ce qui constitue une exception de taille. Chez Facebook, la situation est tout aussi ambiguë…
Une version Web normale, une déclinaison adaptative pour les tablettes, une version Facebook, une version Google et pourquoi pas, si vous êtes éditeur de presse, une version Apple… Tout cela a un vrai coût en développement et maintenance. Et tout ça ne va pas dans le sens de la promesse du Web ouvert, accessible et interopérable : avoir une page unique, accessible par tous, quels que soient son équipement, son réseau d’accès, son système d’exploitation, son navigateur, etc. Plutôt que d’améliorer l’expérience mobile pour tous, nous fragmentons le Web, le séparant en différentes saveurs : classique, Google, Facebook…
Une monétisation difficile
Les pages AMP génèrent aujourd’hui peu de trafic… Deux éditeurs, Slate et The Atlantic, qui proposent leurs contenus au format AMP, avouent que ces pages représentent moins de 4 % de leur trafic. Difficile dans ce cas de vendre ces pages à des annonceurs, d’autant plus que les formats publicitaires autorisés par AMP sont encore en nombre réduit, et qu’il y a de fortes chances pour que le framework interdise indéfiniment les pop-up et autres interstitiels qui sont parmi les formats les plus appréciés des annonceurs.
Un motif d’inquiétude
L’écosystème Google est peuplé de morts au combat. Il est tout à fait envisageable que Google cesse de soutenir activement ce format, ce qui signerait très probablement sa lente agonie. N’oublions pas que la principale motivation des éditeurs à utiliser AMP est l’espoir de bénéficier d’un placement favorable dans le moteur de recherche de Google. Sans le soutien actif de Google (qui dans la pratique met réellement en valeur certaines pages AMP), le format aurait sans doute beaucoup moins de charme aux yeux des producteurs de contenu.
En conclusion
Il est tout à fait possible de faire des sites mobiles aussi rapides que des sites AMP — en employant la plupart des stratégies déployées dans AMP (réduction drastique des requêtes, des JavaScript, des CSS, emploi de CDN, etc.) — tout en restant dans le cadre des standards du Web et en gardant la liberté d’échapper à certaines restrictions que l’on jugerait excessives. Puisque Google promet qu’un site normal ne serait pas désavantagé par rapport à un site AMP, pourvu qu’il soit aussi performant pour les mobiles, il est de fait difficile de percevoir un quelconque avantage décisif au format proposé par Google, surtout compte tenu de ses inconvénients et mesures coercitives. Si Google ne tient pas ses promesses — c’est-à-dire qu’il avantage les sites au format maison — à vous d’évaluer ce gain de visibilité chez Google Search au regard de l’investissement et de l’ensemble des inconvénients.
What should we make of Google AMP (Accelerated Mobile Pages)?
The Accelerated Mobile Pages Project, or AMP for short, is considered to be Google’s answer to Facebook’s Instant Article format. Free and open-source, this framework seeks to enable faster-loading pages for mobile devices. The incentive for publishers to actually use AMP is Google’s promise that faster-loading content will appear at the top of its results list. So far so good.
More specifically, AMP is a restrictive framework for dynamic delivery models. Google hasn’t broken any new ground: for faster loading, just restrict content for loading.
It’s no secret that the main culprits of slow-loading pages nowadays are the ever-present javascripts, used mainly for marketing purposes. AMP has come up with a simple solution: its format precludes the use of these scripts, or any other custom script, or third-party scripts. How radical. Sheer genius.
But there are other culprits apart from javascripts, and Google’s response to these is similar. Is the page’s design too heavy? No problem: just strip it out. In practice, this means, for example, that CSS declarations must be inline (in HTML code) and limited to 50kb, and only pre-approved asynchronous scripts (scripts that can be loaded in the background after the page displays) are allowed.
If you like using JavaScript libraries such as jQuery, Bootstrap, Angular, or React, you’re out of luck; you’ll have to make do with a single, very basic library, AMP JS. In other words, AMP deals only with static content such as press articles; you can forget AMP for anything to do with Web applications.
Advertising can only be displayed in amp-ad tags and only if it comes from preselected networks, like Google AdSense. This of course will make the work of ad blockers that much easier.
What’s hot
User Experience
The biggest winners of AMP are users. Cleaner, mostly ad- and tracker-free pages are more pleasant to look at and much faster to load. Chances are that users will load that many more pages on an AMP site, just like on a traditional, well-designed and optimized mobile site.
What’s not
Web fragmentation
Facebook Instant Article, Google AMP, Apple News, and who knows what’s next… that’s a lot of different formats for a marginal cost-benefit ratio.
Regarding Google’s format specifically, it’s really not that hard to create dedicated pages for mobile devices with HTML/CSS that are just as fast as AMP, if not faster. Which begs the question: was it really necessary to create a non-standard HTML sub-set to be efficient on mobile platforms? Unless the real intent is to throttle content and deprive publishers of some of their freedom to decide on the way their articles are displayed, and the way they generate revenues.
The proliferation of these more-or-less proprietary formats will also make life difficult for publishers. Rather than creating a single mobile version, publishers will have to create a different version for each platform, under pain of being penalized with lower placement on the results list. Of course, Google, through Dave Besbris, the VP in charge of the AMP project, denies any such intent, asserting that Google will not give AMP pages preferential treatment. Which makes us wonder where their interest lies. In any case, the facts belie Besbris: AMP pages are indeed given preferential treatment in Google Search, with carousel presentation for press sites: quite the exception. On Facebook, the situation is just as murky.
So, to sum up: normal Web version, adaptive Tablet version, Facebook version, Google version and, if you are a press publisher, Apple version… the development and maintenance costs quickly add up. And this flies in the face of the promise of an open, accessible and interoperable Web: each page accessible to all, regardless of hardware, access network, operating system, browser, etc. Instead of improving the mobile experience for all, we’re fragmenting the Web into subsets: traditional, Google, Facebook…
Hard to capitalize on
AMP pages currently generate little traffic. Two publishers who offer AMP-formatted pages, Slate and The Atlantic, say these account for less than 4% of total traffic. Hard to sell these pages to advertisers, especially since AMP authorizes very few advertising formats and chances are that the framework will indefinitely preclude pop-ups and other interstitial formats that are particularly popular with advertisers.
Reason for concern
The Google ecosystem is littered with dead projects. It is entirely possible that Google will eventually stop actively supporting AMP, which would signal the beginning of its slow and inexorable death. Remember, the main incentive for publishers to use AMP is to appear at the top of Google Search results. Without the active support of Google (who, in practice, does give AMP pages preferential treatment), the format would lose most of its charm for content producers.
In conclusion
By using the same strategy AMP uses (drastically reducing queries, javaScripts, and CSSs, CDN use, etc.), it is perfectly possible to create mobile sites that are as fast as AMP sites, while remaining within Web standards and keeping the option of avoiding restrictions deemed to be excessive. Since Google promises that normal sites will not be treated differently from AMP sites, as long as its mobile performance is up to scratch, it is difficult to see any real advantage to Google’s format, especially when you take into account its drawbacks and restrictions. If Google does not keep its promise, i.e. if it does give its proprietary format sites preferential treatment, it is up to you to decide whether enhanced Google Search visibility makes up for the extra investment and inconvenience.