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 actuelle, 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 qu’on appelle Google Accelerated Mobile Pages (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 les principaux 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 de la communauté Web devrait être première étape de la création de normes Web, et pas seulement un obstacle de dernière minute pour Google à franchir.

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é à apparaître en 2016. Mais tout de suite, beaucoup ont observé que l’AMP empiétait sur le 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 à l’avant-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, par rapport à ce à quoi elle ressemble en utilisant AMP:

Balise d’image HTML:

Balise d’image AMP:

Depuis la vitesse de lancement des pages ont prouvé être plus rapides 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 ainsi qu’un chemin d’accès associé à la page sur laquelle vous vous trouvez:

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

Ceci, avec c’est SSL Le certificat clarifierait que vous voyez du 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

En utilisant des URL canoniques, les utilisateurs peuvent plus facilement vérifier que le site sur lequel ils se trouvent est celui qu’ils essaient de visiter. Mais les URL AMP ont brouillé les eaux et obligé les utilisateurs à adapter de nouvelles façons pour vérifier les origines du contenu original.

Quel contenu?

Un pas plus loin est leur structure pour les pages pré-rendues 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. Depuis que Google est devenu une partie tellement enracinée du Web moderne pour tant de personnes, toute technologie qu’ils déploient auraient immédiatement une grande partie des utilisateurs et des adoptants. C’est aussi couplé avec d’autres arguments d’autres équipes de produits au sein de Google ont fait 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 le soutien Échanges HTTP signésou « SXG », un sous-ensemble de Forfaits Web norme qui permet de découpler davantage la distribution du contenu Web de ses origines avec les échanges HTTP signés par cryptographie (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’une norme Web a été utilisée, mais le négatif ici est la vitesse d’adoption sans consensus général de autres principaux intervenants. Actuellement, SXG est uniquement pris en charge dans Chrome et Chrome navigateurs.

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 grand CMS (système de gestion de contenu), WordPress, pour promouvoir davantage l’AMP. Les éditeurs utilisent les services CMS pour télécharger, modifier et héberger du contenu, et WordPress détient 60% de part de marché comme CMS de choix. Les éditeurs sont également en concurrence avec d’autres produits Google, tels que la recherche Google. Alors peut-être que certains éditeurs ont adopté AMP parce qu’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, cette l’argument a été contesté par Google, et ils maintiennent que la performance est priorisée, peu importe ce qui est utilisé pour obtenir le résultat de cette page à cette mesure de performance. Depuis le L’algorithme de recherche Google est principalement secret, nous ne pouvons que faire confiance à ces déclarations au mot. Tangentiellement, la fonctionnalité « Top Stories » dans la recherche sur mobile a récemment abandonné AMP comme exigence.

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, l’énoncé «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 le fait que AMP soit 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. Il s’agit cependant d’une simple concession, car Google Analytics a une telle part de marché de la bande mesurée.

Si Google était simplement une entreprise de performance Web, ce serait encore trop de centralisation des 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 prétendument découpler Google AMP Cache, qui héberge des pages, à partir du runtime AMP, qui est la source JavaScript pour traiter les composants AMP sur une page.

Cependant, c’est bien après que AMP ait été intégré dans les principaux sites d’actualités, commerce électronique, et même sans but 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é ces types de groupes ont tendance à avoir, les frais d’adhésion et les délais. Ces problèmes particuliers ne sont pas la faute de Google, mais Google a 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 si elles doivent desserrer 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 passés depuis longtemps. 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.