Avez-vous déjà cliqué sur un lien après avoir recherché quelque chose sur Google, pour constater que Google ne vous a pas dirigé vers la page Web proprement dite, mais vers une version étrange de Google? Au lieu que l’adresse Web soit la source de l’article, il dit toujours «google» dans la barre d’adresse de votre téléphone? C’est ce que l’on appelle les pages mobiles accélérées de Google (AMP), et maintenant Google a annoncé que AMP est diplômé du programme d’incubation de la Fondation OpenJS. La Fondation OpenJS est un effort fusionné entre de grands projets de l’écosystème JavaScript, tels que NodeJS et jQuery, dont la mission déclarée est de «soutenir la croissance saine de l’écosystème JavaScript et Web». Mais au lieu d’une norme commençant par la communauté Web, une entreprise géante arrive dans la communauté après avoir déjà construit une grande partie du Web mobile et demande un tampon en caoutchouc. La discussion au sein de la communauté Web devrait être la première étape de l’élaboration de normes Web, et pas seulement un obstacle de dernière minute à franchir par Google.

Qu’est-ce que l’AMP?

Ce cadre HTML allégé et soutenu par Google a été créé avec la promesse de créer des pages Web plus rapides pour une meilleure expérience utilisateur. Couper le contenu à chargement plus lent, comme ceux développés avec JavaScript. À un niveau élevé, AMP fonctionne en chargeant rapidement des versions allégées de pages Web complètes pour une visualisation mobile.

Le projet Google AMP a été annoncé fin 2015 avec la promesse de fournir aux éditeurs un moyen plus rapide de servir et de distribuer du contenu à leurs utilisateurs. Cela a également été commercialisé comme une approche plus adaptable que Apple News et Facebook Instant Articles. Les pages AMP ont commencé à faire leur apparition en 2016. Mais tout de suite, beaucoup ont observé que AMP empiétait sur les principes du Web ouvert. Le Web a été construit sur des normes ouvertes, développées par consensus, que les petits et les grands acteurs peuvent utiliser. Ce qui, dans ce cas, implique de maintenir les normes Web ouvertes au premier plan et de décourager les normes fermées propriétaires.

Au lieu d’utiliser des balises de balisage HTML standard, un développeur utiliserait des balises AMP. Par exemple, voici à quoi ressemble une image incorporée en HTML classique, à quoi elle ressemble en utilisant AMP:

Balise d’image HTML:

”src

Balise d’image AMP:

Étant donné que la vitesse des pages de lancement s’est avérée plus rapide lors de l’utilisation d’AMP, les promesses de la technologie ne sont pas nécessairement mauvaises du seul point de vue de la vitesse. Bien sûr, il existe des moyens d’améliorer les performances autres que l’utilisation d’AMP, tels que la réduction des fichiers, la création de code plus léger, les CDN (réseaux de distribution de contenu) et la mise en cache. Il existe également d’autres frameworks soutenus par Google tels que les PWA (applications Web progressives) et les employés de service.

AMP existe depuis quatre ans maintenant, et les critiques se poursuivent encore aujourd’hui avec les dernières progressions d’AMP autour d’une partie très importante du Web, l’URL.

URL canoniques et URL AMP

Lorsque vous visitez un site, peut-être votre site d’actualités préféré, vous verrez normalement le domaine d’origine avec un chemin d’accès associé à la page sur laquelle vous vous trouvez:

https://www.example.com/some-web-page

Ceci, ainsi que son certificat SSL, clarifierait que vous voyez le contenu Web servi à partir de ce site à cette URL avec une bonne confiance. C’est ce qui serait considéré comme une URL canonique.

Une URL AMP, cependant, peut ressembler à ceci:

https://www.example.com/platform/amp/some-web-page

Grâce aux URL canoniques, les utilisateurs peuvent plus facilement vérifier que le site sur lequel ils se trouvent est bien celui qu’ils essaient de visiter. Mais les URL AMP ont embrouillé les eaux et obligé les utilisateurs à adapter de nouvelles façons de vérifier les origines du contenu original.

Quel contenu?

Une étape supplémentaire est leur structure pour les pages pré-rendues à partir du contenu mis en cache. Cette URL ne serait pas visible par l’utilisateur, mais le contenu (texte, images, etc.) servi sur la page en cache proviendrait plutôt de l’URL ci-dessous.

https://www-example-com.cdn.ampproject.org/c/www.example.com/amp/doc.html

L’URL finale, celle affichée ou la barre d’URL, d’une page AMP mise en cache ressemblerait à ceci:

https://www.google.com/amp/www.example.com/amp.doc.html

Ce modèle de cache ne suit pas le concept d’origine Web et crée un nouveau cadre et une nouvelle structure à respecter. La promesse est de meilleures performances et une meilleure expérience pour les utilisateurs. Pourtant, l’approche est la mise en œuvre d’abord et les normes Web plus tard. Étant donné que Google est devenu une partie tellement ancrée du Web moderne pour tant de personnes, toute technologie déployée aurait immédiatement un grand nombre d’utilisateurs et d’adopteurs. Cela est également associé à d’autres arguments avancés par d’autres équipes de produits au sein de Google pour remodeler l’URL telle que nous la connaissons. Cela a fondamentalement changé la façon dont le Web mobile est servi pour de nombreux utilisateurs.

Un autre développement plus récent est la prise en charge des échanges HTTP signés, ou «SXG», un sous-ensemble de la norme des packages Web qui permet de découpler davantage la distribution du contenu Web de ses origines avec des échanges HTTP signés cryptographiquement (une page Web). Ceci est censé résoudre le problème, introduit par AMP, que l’URL qu’un utilisateur voit ne correspond pas à la page qu’il essaie de visiter. SXG permet à l’URL canonique (au lieu de l’URL AMP) d’être affichée dans le navigateur lorsque vous arrivez, fermant la boucle à l’éditeur d’origine. Le positif ici est qu’un standard Web a été utilisé, mais le négatif ici est la vitesse d’adoption sans consensus général des autres principales parties prenantes. Actuellement, SXG n’est pris en charge que dans les navigateurs basés sur Chrome et Chromium.

Pousser AMP: comment une nouvelle «norme» a-t-elle pris le dessus?

Les éditeurs de nouvelles ont été parmi les premiers à adopter AMP. Google s’est même associé à un important CMS (système de gestion de contenu), WordPress, pour promouvoir davantage AMP. Les éditeurs utilisent les services CMS pour télécharger, modifier et héberger du contenu, et WordPress détient environ 60% des parts de marché en tant que CMS de choix. Les éditeurs sont également en concurrence avec d’autres produits Google, tels que la recherche Google. Ainsi, certains éditeurs ont peut-être adopté AMP car ils pensaient que cela améliorerait le référencement (optimisation des moteurs de recherche) sur l’un des moteurs de recherche les plus utilisés du Web. Cependant, cet argument a été contesté par Google, et ils maintiennent que les performances sont prioritaires, peu importe ce qui est utilisé pour obtenir le résultat de cette page pour cette mesure de performance. Étant donné que l’algorithme de recherche Google est principalement secret, nous ne pouvons que faire confiance à ces déclarations au mot. Tangentiellement, la fonctionnalité « Top Stories » de la recherche sur mobile a récemment supprimé AMP.

Le projet AMP était plus fermé en termes de contrôle au début de son lancement malgré le fait qu’il se soit présenté comme un projet open source. Les éditeurs ont fini par signaler des vitesses plus élevées, mais cela a été laissé à un ensemble de mesures «le temps nous le dira». En conclusion, la mention «vous n’avez pas besoin d’AMP pour vous classer plus haut» est souvent en concurrence avec «utilisez simplement AMP et vous obtiendrez un rang supérieur». Ce qui peut être tentant pour les éditeurs qui tentent d’atteindre la barre de performances pour obtenir la priorité de leur contenu.

La communauté Web d’abord

Nous devrions nous concentrer moins sur la question de savoir si AMP est ou non un bon outil pour les performances, et plus sur la façon dont ce cadre a été façonné par la propriété initiale de Google. La couche de cache appartient à Google et, même si elle n’est pas requise, la plupart des implémentations utilisent cette fonctionnalité de cache. Les préoccupations relatives à l’analyse ont été résolues et ils ont également fait la courtoisie d’autoriser d’autres grands fournisseurs d’annonces dans le modèle AMP concernant le contenu publicitaire. Ce n’est qu’une simple concession, car Google Analytics détient une part de marché si importante du Web mesuré.

Si Google était simplement une entreprise de performances Web, ce serait encore trop centraliser les décisions du Web. Mais ce n’est pas seulement une entreprise à fonction unique, c’est un conglomérat géant qui contrôle déjà le plus grand système d’exploitation mobile, navigateur Web et moteur de recherche au monde. La gestion du projet par le biais de la Fondation OpenJS est une approche plus bienvenue. La nouvelle structure de gouvernance se compose de groupes de travail, d’un comité consultatif et d’un comité technique de pilotage composé de personnes à l’intérieur et à l’extérieur de Google. Cela devrait amener plus de voix à la table et structurer l’AMP dans un meilleur processus pour les décisions futures. Cette décision aurait pour effet de dissocier Google AMP Cache, qui héberge les pages, du runtime AMP, qui est la source JavaScript pour traiter les composants AMP sur une page.

Cependant, tout cela est bien après que AMP ait été intégré dans les principaux sites d’actualités, le commerce électronique et même les organisations à but non lucratif. Ce nouveau modèle n’est donc pas une approche démocratique uniforme. Peu importe les intentions, bonnes ou mauvaises, ceux qui travaillent avec des entités puissantes doivent vérifier leur pouvoir à la porte s’ils veulent un Web plus équitable et utilisable. Ne pas reconnaître le pouvoir que l’on exerce, ne fait qu’imposer un faux sens de la démocratie qui n’existait pas.

De plus, le processus de standardisation Web lui-même est loin d’être parfait. Les organismes de normalisation sont fortement dominés par les membres des entreprises et les liens que l’on peut avoir avec eux offrent un immense capital social. Les personnes moins représentées n’ont pas le capital social pour rejoindre ou être membre. C’est un long chemin jusqu’à ce qu’un processus plus équitable se produise pour ces types d’organisations; jumelé au manque de diversité de ces types de groupes, au coût de l’adhésion et aux délais. Ces problèmes particuliers ne sont pas la faute de Google, mais Google dispose d’une immense puissance lorsqu’il s’agit de rejoindre ces groupes. Lorsque vous rejoignez des organisations de normalisation, il ne s’agit pas de gagner leur place, mais de décider s’ils doivent ou non relâcher leur règne.

À l’heure actuelle avec le projet AMP, Google ne peut pas libérer rétroactivement le contrôle qu’il avait dans l’adoption d’AMP. Et nous ne pouvons pas revenir à un site Web pré-AMP pour recommencer. Les discussions sur l’opportunité de supprimer le projet AMP, ou de le décourager pour un cadre différent, sont depuis longtemps passées. La décision des utilisateurs de se retirer ou non d’AMP a été décidée dans de nombreux coins du Web. Tout ce que nous pouvons faire maintenant, c’est apprendre du processus et essayer de nous assurer que l’AMP est développé dans le meilleur intérêt des utilisateurs et des éditeurs à l’avenir. Cependant, le Web ouvert ne devrait pas être altéré par les multiples leçons apprises sur le pouvoir et le contrôle des grandes entreprises technologiques qui ont besoin de réapprendre la responsabilité à chaque nouvelle entreprise.