L'Accelerated Mobile Pages Project (AMP) de Google

Google et ses partenaires viennent de lancer sur Github le projet "Open Source" AMP pour "Accelerated Mobile Pages" autrement dit les "pages accélerées pour mobile".

AMP Project : Une autre idée de la performance mobile web

Si on peut saluer l'initiative tournée vers l'expérience utilisateur, la rapidité de chargement, la performance avec à la clé une économie de la bande passante, qu'en est-il de la méthode et de l'Open Web ?

Présentation du projet AMP de Google et de ses partenaires

L'objectif de AMP Project :

Accélérer le chargement des pages web et des contenus statiques sur mobile et permettre aux grands éditeurs de contenus de mettre en place des stratégies de performance à grande echelle tout en garantissant une meilleure délivrabilité des publicités.

Les technologies et les moyens mis en oeuvre :

Les acteurs du projet AMP propose pour se faire, de livrer aux appareils mobiles une version spécifique de leurs contenus via des sous-ensembles de HTML (AMP HTML), CSS et SVG. De ces "versions allégées" sont prohibés nombre d'éléments, des sélecteurs et des balises qui seront remplacés pour certains par des "Custom Tags". Javascript s'occupant du chargement et de l'affichage.

Par exemple, les balises <IMG> deviennent <amp-img>, <video> devient <amp-video>... Les balises form, iframe, input... Sont prohibés et ne passeront pas la validation AMP. 

Les "Custom fonts" sont autorisées à condition que la source soit en HTTPS et que l'inclusion se fasse via Font-face. Les balises <scripts> sont également prohibées sauf le script du runtime AMP requis "https://cdn.ampproject.org/v0.js", les "Web Composants" (extended components) et les JSON LD de type "application/ld+json". A noter, les scripts doivent comprendre l'attribut "async".

Pour les "metadata" toutes possibilités Microdata, RDFa, JSON-LD, offertes par Schema.org sont permises dans le cadre des "schema.org/CreativeWork" ou des types plus spécifiques tels que "schema.org/NewsArticle" ou "schema.org/BlogPosting". Les "Open Graph Protocol", "Twitter Cards" et metadata similaires sont également supportés par HTML AMP.

Les contenus riches tels que les vidéos, les questionnaires et autres contenus interactifs devront obligatoirement passer par des "AMP HTML Components" inspirés par les "Composants Web" de HTML5. 

Sont déjà disponibles : amp-img, amp-audio, amp-anim, amp-ad, amp-pixel, amp-video, amp-carousel, amp-lightbox, amp-iframe, amp-instagram, amp-twitter, amp-youtube.
Cette (très) courte liste est amenée à grandir mais cela devra passer par des technologies promues par les grands acteurs du web telles que Polymer, X-Tag, Bosonic...

Bien sûr, au regard de ces adaptations et prohibitions, il existe aussi des balisages obligatoires. Dont celui de la fameuse "bibliothèque AMP JS" qui est "chargée de charger" toutes les autres ressources de la page et de les mettre en cache sur les serveurs de Google pour les servir rapidement et au plus près de l'utilisateur final.

Extrait de code source d'une page HTML AMP

Pour avoir une vue plus complète de l'implémentation technique de AMP je vous invite à aller sur "https://www.ampproject.org/how-it-works/" (lien en bas de page)

Mise en oeuvre opérationnelle de AMP sur un site web.

Pour des contenus simples avec du texte, des images, quelques contenus riches comme de l'audio/vidéo, cela semble simple mais nécessite tout de même un développement pour une sortie spécifique et dédiée au mobile. Pour des contenus faisant appel à des librairies et des bibliothèques tierces pour des contenus interactifs ou très riches, les choses vont se corser, avec en plus la nécessité d'adopter des technologies issues de ces grands acteurs et peu conforme avec l'Open Web et l'accessibilité.

Tests de performance pour l'AMP HTML

Devant une telle débauche de moyen et d'enthousiasme pour AMP Project, il convient de tester la solution. Pour cela j'ai tout simplement passé la page "https://www.ampproject.org/how-it-works/" à la moulinette de PageSpeed et voici le résultat pour la vitesse sur Mobile.

AMP HTML testé sous Pagespeed

Ce résultat est décevant ! Car au final PageSpeed attribut une petite note de 75/100 pour la vitesse tout en soulignant les points de blocage récurrents que l'on retrouve sur les sites en version classique ; les JS et CSS bloquent l'affichage du contenu au-dessus de la ligne de flottaison, pas de mise en cache du navigateur, absence de minification des JS et pas de compression GZIP des ressources HTML.

Pour cette même page testée sur Dareboost, une note a peine meilleure avec 83/100 et un Speed Index de 1429 (Google recommande moins de 1000)

AMP HTML testé sous DareBoost


Que pensez de "AMP Project" à ce jour ?

Pour moi et nombre d'autres développeurs web, rendre le JavaScript obligatoire pour des objectifs de performance va à l'encontre d'un web ouvert, car la plupart des obstacles à la performance contre lesquels veut lutter AMP peuvent être réglés depuis longtemps par la mise en oeuvre de bonnes pratiques et l'utilisation raisonnées de librairies tierces.

Ce que je trouve étrangec est que le gain de performance attendu est confié à Javascript alors que c'est cette même technologie qui est en premier lieu incriminée dans les lenteurs du web, suivi par les autres resources statiques mal configurées. 

De plus cette mise en oeuvre oblige à Javascript pour effectuer le rendu de la page des composants web et des "customs elements".

AMP réinvente la roue ?

Il me semble même qu'avec AMP Project, Google et ses partenaires réinvente la roue à chaque occasion et complexifiant grandement la livraison des contenus. 

Là où de simples flux (JSON, XML...) légèrement vêtus de css suffiraient à fournir un contenu léger et rapide à livrer, AMP nous propose une usine à gaz qui multiplie les dépendances envers des technologies dont ils sont les initiateurs et promoteurs. 

AMP HTML et Google réinventent la roue

Que dire de la quasi obligation (à cette heure) de passer par les CDN de Google et son service de webfonts...

AMP Project : De bonnes intentions sur la mauvaise voie ?

Vous aurez peut-être des avis différents du mien, mais pour moi si l'intention est louable, la voie choisie ne l'est pas et sert d'autres intérêts et objectifs que la performance et l'expérience utilisateur.

Oui les grands éditeurs ont besoin de la publicité et de connaitre comment nous la lisons, mais les sites de presse et d'actualité sont pour la plupart imbuvables tant les publicités, les interstitiels et autres éléments d'engagement et de tracking nous éloignent de notre souhait d'y lire l'information.

Oui il faudrait que l'information et l'actualité sur mobile ne passe pas obligatoirement par une application pour être lue rapidement.

Oui le web d'actu et d'information peut-être rapide sur mobile, il faudrait juste que les développeurs et intégrateur applique les règles disponibles en matière de performance et qu'ils comprennent qu'une meilleure UX augmentera naturellement leurs KPI d'engagement.

Mais de là à réduire le HTML à une version limitée et littéralement dépendante de Javascript pour son affichage (Pas de JS pas de contenu ! par ce style obligatoire <style>body {opacity: 0}</style> ), il y a un pas que je ne souhaiterais pas voir franchi.

Conclusion : 

AMP répond plus à la nécessité pour Google et autres grands acteurs du web de préserver leur capacité à pister et à enfermer l'internaute mobile dans un univers où la publicité et le bigdata associés pourront se faire plus discrets dans leurs effets pénalisants pour l'expérience utilisateur. 

Par ailleurs AMP Project est sans doute un bon moyen pour Google de ramener à lui les éditeurs séduits par Facebook et ses "Instant Articles" ou par Twitter et ses "Moments" à qui il promet par ailleurs (via une prime à la rapidité) un meilleur positionnement dans ses SERPs mobiles (Résultats de recherche). 

Enfin l'idée d'une information majoritairement stockée et délivrée par Google n'a rien pour me séduire.

J'suis pas content ;-)

Impliqué depuis de nombreuses années dans la performance et l'application des bonnes pratiques je trouve cette initiative :

  • Bonne pour la finalité et la coopération qu'elle fait naitre.
  • Désastreuse pour le web, l'innovation, les standards ouverts et la neutralité d'internet.


Liens et ressources :


Pour continuer votre lecture sur la thématique Performance web

Partager l'article sur :

Lien permanent :

Tags : Performance web, Création de site web, Développement,

Commenter et noter cet article

Les commentaires pour cet article