Voilà peu de temps, j'ai découvert "AMP", un nouvel acronyme top-secret (c'est épuisant, à la longue...) pour "Accelerated Mobile Page". Cette bien belle initiative de Google - dont on connait la philanthropie - vise à améliorer drastiquement l'expérience du web sur mobile. Pourtant, elle mérite réflexion.

Elle ne date pas d'hier, l'idée d'adapter le web aux terminaux mobiles, avec leurs faibles capacités et leurs écrans aux mensurations réduites. L'une des premières tentatives sérieuses n'était autre que le WAP, une technologie parallèle au Web traditionnel qui visait à offrir un semblant d'Internet aux téléphones mobiles par les réseaux limités de l'époque. On pouvait à peine comparer le développement d'un contenu WAP et le développement d'un site web.

La démocratisation de l'accès à Internet sur smartphones a initialement poussé les artisans du web dans la direction d'un double développement : un site web traditionnel et un site web mobile. Cette approche terriblement coûteuse (développement, maintenance, ...) ne satisfaisait généralement pas les adeptes du mobile puisque les versions à leur destination étaient souvent limitées en fonctionnalités. Et puis est venu le responsive web design (RWD, également appelé "responsive design"), poussé par l'adoption des Media Queries((Des instructions CSS qui permettent de distinguer l'agencement d'un site en fonction, entre autres, de la largeur de l'écran qui l'affiche)). Nous étions en 2009. Depuis, les sites web compatibles avec les terminaux mobiles sont devenus légions.

Le RWD n'est pas une solution miracle : par défaut, elle se contente de changer l'agencement d'une page, mais les ressources qui s'y trouvent (images, scripts, contenu multimédia divers) demeurent identiques. Tout le monde est logé à la même enseigne, qu'on parle d'un ordinateur au bénéfice d'une connexion rapide ou d'un smartphone doté d'un forfait limité et d'une vitesse de transfert médiocre. Un exemple concret, parmi tant d'autres : une image de 1920 * 1200px, pensée pour un ordinateur fixe, pèsera inutilement lourd pour un simple smartphone qui ne l'affichera qu'en petit. Mon blog en est d'ailleurs un bon exemple. Quand on y pense, le gaspillage est effarant : trafic inutile sur Internet, téléchargement (donc délais d'affichage) inutile sur le smartphone, surcharge inutile de la mémoire du terminal et j'en passe.

Pour contrer ces limitations, des solutions JavaScript ont été mises en place. On peut par exemple retarder l'affichage des images en fonction de la position sur la page (lazyloading) ou envoyer des ressources adaptées en analysant préalablement les capacités du terminal. Ces solutions impliquent l'emploi d'une bibliothèque JavaScript dont la taille doit être restreinte de sorte à ne pas retarder son exécution. Plus intéressant encore, l'évolution du langage HTML va combler une partie des limitations du RWD : la fameuse balise < picture > illustre cette idée, puisqu'elle permet de spécifier différentes sources d'image parmi lesquelles votre navigateur sélectionnera la plus adaptée. On s'épargne ici l'exécution d'un code JavaScript potentiellement trop gourmand, en laissant le navigateur gérer nativement le choix des ressources. Ces nouveaux standards du web sont poussés par les différents groupes qui en sont dépositaires : le W3C, ou encore le WHATWG.

C'est dans ce paysage en pleine évolution que Google débarque avec son AMP, un sous-ensemble de HTML voué à exclure tous les éléments disproportionnés pour les mobiles. On écrit une page AMP comme une page HTML, à l'exception d'une série de balises jugées problématiques par Google. Parmi celles-ci, mentionnons la balise < script >, ainsi que la fameuse balise < img > - remplacée par < amp-img >. Seule exception à ces règles : le script AMP, qui permet justement la traduction des balises personnalisées vers du HTML standard. Google en profite également pour suggérer l'emploi de Google AMP Cache, des serveurs dédiés au stockage des ressources de vos pages AMP afin de les servir le plus rapidement à vos visiteurs. Un service proposé "gratuitement à la Google". L'entreprise de Mountain View précise bien sûr qu'AMP vise essentiellement les journaux et autres blogs, plutôt que les applications web qui nécessitent forcément du code JavaScript. Quand on y réfléchit, AMP pourrait apparaître comme une sorte d'évolution de RSS, où le contenu d'un site complexe se trouve projeté dans un contexte plus simple. Seulement ici, c'est le site qui décide de l'apparence de ce contexte, plutôt que l'utilisateur final.

Soit.

AMP me pose plusieurs problèmes.

Le premier, c'est qu'on retourne à une logique de développement séparé pour la version mobile et la version traditionnel d'un site. Certes, la création d'une page AMP ne peut en aucun cas être comparé à celle d'une version mobile dédiée des années 2008-2010 : on parle d'une simple page HTML sans contenu complexe, dont la mise en page reste modeste. Mais chaque modification que vous apporterez à votre charte graphique devra être répercutée à double.

Le second est plus politique : pourquoi diable Google, qui ne ménage pourtant pas ses efforts pour améliorer les standards du web, débarque avec une solution bâtarde qui finira tôt ou tard par devoir céder sa place aux véritables normes((Par exemple, < amp-img > fonctionne essentiellement comme un alias de < picture >.))? AMP m'a tout l'air d'un sparadrap qu'on applique sur une blessure vouée à se résorber. Difficile de s'enthousiasmer pour ça.

Finalement, AMP a beau être un projet Open-Source, il est essentiellement piloté par Google. Au besoin, voici quelques raisons de s'en inquiéter :

  • Le placement de produits, comme Google AMP Cache
  • Les décisions unilatérales quant à l'évolution du web, sans passer par la régulation d'une entité "neutre"
  • L'abus de position dominante en général, puisque Google compte favoriser les contenus "adaptés au mobile" dans ses recherches. Et rien n'est mieux adapté au mobile qu'AMP, selon les Google-ingénieurs...

Toutes ces raisons me font douter de la pertinence, autant que de la légitimité d'AMP sur le web. Pourtant j'avoue que disposer d'un framework actuel pour dégraisser les pages mobiles reste tentant. Pour l'heure et depuis sa version 0.10, Ghost impose une version AMP pour ses articles. Vous pouvez, par curiosité, accéder à la version AMP de n'importe lequel de mes articles en rajoutant /amp à la fin de son URL. D'ici quelques semaines, je déciderai s'il vaut mieux la désactiver, la garder ou même l'améliorer.