CPU ⬜ Carré Petit Utile

Extrait de l'émission CPU release Ex0250 : Et l'URL disparu.

Donc en 2008, deux navigateurs web orienté innovation vont mélanger visuellement le concept de motif de recherche et d'URL. Et comme les moteurs de recherche cherchent encore leur modèle économique, ceux-ci séparent de moins en moins visuellement les résultats d'une recherche naturelle et les publicités contextualisées. Au départ, ces deux types de réponses sont séparées en deux colonnes distinctes, avec des codes couleurs différents, et un tag publicité bien lisible, mais vite, ces différences se gomment et le visiteur confond parfois les deux types de réponse.

Ce qui va faire le bonheur du cybersquattage par mots-clés, avec donc une complicité passive des régies publicitaires automatisées.

Des personnes voulant bien faire expliquent à leurs proches qu'il faut toujours faire attention au nom de domaine dans l'URL d'une page… mais… nous avons beau tenter de sensibiliser le grand-public sur des notions de sécurité informatique, malheureusement, nous ne sommes pas toujours aidés par les industriels. Encore une fois, des idées qui semblaient si utiles se sont montrées mitigées dans l'exécution.

Par exemple, il y a eu un mouvement initié par le navigateur Chrome de supprimer l'indication du protocole http:// ou https:// pour simplifier l'affichage dans la barre d'URL…
Bon ok, soit, c'est vrai que c'est une information trop technique, trop redondante pour le grand public. Sauf que, jusqu'en 2021, dans Chrome, pour différencier dans la barre d'URL le protocole en clair du protocole sécurisé, il affichait un cadenas au début de l'URL symbolisant un site en https: donc sécurisé… Et en 2021, Chrome supprime l'affichage du cadenas pour afficher un texte "non sécurisé" sur un site en protocole http: …

On était donc passé à l'époque du comportement visuel d'un site en http: à un site en https:… Bonjour la confusion, il a fallut ré-expliquer.

Et puis… Et puis Google Chrome cacha les URL réelles des versions AMP de sites web qu'ils hébergent pour des URL fictives.

Mais avant d'en parler, il faut que j'explique AMP : AMP signifie Accelerated Mobile Pages.

Google avait depuis longtemps constaté que si une page web met trop longtemps à s'afficher, disons 5 secondes, les utilisateurs quittent la page avant qu'elle ne s'affiche complètement. Pour que Google se targue de l'exactitude des réponses aux questions, il valait mieux mettre en avant, donc parmi les tout premiers résultats, les sites qui s'affichent le plus vite possible.

Ce rejet des sites web lents par le grand public était d'autant plus flagrant sur téléphone mobile. N'oublions pas qu'en dehors de la France, la plupart des pays paient le mégaoctet transféré à prix d'or auprès des opérateurs mobiles. Eh oui, Merci Free ;)

Sur son ordi de poche, l'utilisateur est beaucoup moins patient envers les sites mastosaures.

Google met donc en avant dans ses résultats de recherche naturels les sites dont l'affichage se fait le plus vite possible. Et pour aider les concepteurs de sites web, il existe un outil intégré dans Google Chrome pour avoir des métriques sur la vitesse d'affichage d'une page web côté client : Lighthouse. Pour info, les critères de scores changent régulièrement ; il faudra d'ailleurs retravailler un peu le site CPU.pm

À côté, en 2015, Google propose aussi un ensemble de recommandations pour construire les sites spécifiquement prévus pour téléphones mobiles. Les fameuses AMP, Accelerated Mobile Pages. Voilà, on y vient.
Pour rappel, à ce moment-là, si le mode de conception de site web recommandé était déjà le mobile-first, la plupart des sites lancés étaient d'abord conçus pour leur rendu sur ordinateur de bureau, et après coup, le donneur d'ordre se rendait compte qu'il était inutilisable sur son iPhone, donc une version mobile spécifique du même site était alors construite à côté.

Dans sa première version parue, AMP était une recommandation pour construire des pages web avec très peu de balises HTML, et quasiment pas de code javascript. Je mets de côté certains hacks qui ne sont que tolérés par le standard HTML ou l'Unicode, et qui selon Google passent crème sur la quasi-totalité de leurs smartphones de tests.
Donc premièrement, construire des pages HTML avec beaucoup moins de balises de type <div> emboîtées en très grand nombre pour satisfaire une mise en page tarabiscotée ; une maladie du webdesign appelée divite.
Deuxièmement, favoriser des pages web nécessitant beaucoup moins de javascript construisant le contenu de la page, donc faire en sorte que dans le HTML envoyé en version statique, on aie déjà un rendu quasi-définitif, sans attendre des requêtes intermédiaires type JSON. À l'époque, beaucoup trop de sites construits avec Angular ou déjà React étaient immondément lents à s'ouvrir, même sur un ordinateur de bureau.

Ce que Google a labélisé avec la dénomination AMP a beaucoup été changée à travers le temps :

• Par exemple, ils ont par la suite sorti une collection de webcomponents, trouvables sur leur site ://amp.dev, dont certains remplacent des tags HTML déjà existants afin d'avoir un look unifié, et surtout pour recommander des webcomponents de bannières publicitaires, donc favoriser la régie publicitaire de Google. Tiens Tiens.
• et de l'autre, Google propose d'héberger les pages AMP sur ses propres serveurs, ce qui est dénommé le programme Google AMP cache . Tiens Tiens Tiens.

Beaucoup de sites web réputés sont passés en AMP sur hébergement en Google AMP Cache parce que les serveurs Google sont ultra-rapides, parce que les javascripts sont sûrement pré-chargés dans le navigateur Chrome, mais aussi… parce que Google a proposé jusqu'en 2020 un bonus d'indexation supplémentaire pour les sites qui ont scrupuleusement suivi le style AMP. Oui, vous m'avez bien compris : Google proposait de mieux référencer dans ses recherches les sites web qui étaient hébergés à leur normes sur leurs serveurs, donc d'en faire leurs clients. Largement de quoi faire tiquer les autorités à la concurrence.

Mais c'est l'hébergement qui a posé un souci imprévu : les sites AMP hébergés par Google étaient dans un sous répertoire /amp du domaine google.com.

Comme le grand public était perdu se retrouvant sur google.com/amp plutôt que sur LaGazettedeMontpelliersurTarn.fr. Pour répondre aux interrogations des propriétaires des sites, l'idée qu'eu Google fut... dans le navigateur Chrome de remplacer dans la barre d'URL la réelle adresse web de la page AMP par le nom de domaine de la page d'origine, donc mettre l'URL canonique.

Plantage !

Google a annoncé en 2019 sa fonction de modification d'URL affichée pour les sites AMP, avec donc ce masquage du réel nom de domaine hébergeant. Et attention, en fanfare, ils en étaient si fiers et c'était si attendus par nombre de décideurs. Et, comment dire…

Alors là, je peux vous faire écouter un enregistrement d'un cri tribal déchirant l'obscurité d'une caverne gigantesque afin d'exprimer ma colère et mon désarroi.
Et mon courroux, coucou.
Mais afin de participer à votre élévation intellectuelle, j'estime plus expressif et littéraire de placer ici cette citation historique :

Timeo libri rex agitur, ça veut rien dire, mais c'est ce que j'ai trouvé de plus… aigre !
(Roi Loth, évangile selon Kaamelott, V^ème siècle après Jules César)

J'étais très loin d'être le seul d'avoir trouvé l'idée complètement stupide.

Très sincèrement, permettre à un site distant de manipuler ce qui est affiché par la barre d'URL d'un navigateur et plus précisément, le nom de domaine, ce que nous recommandons très exactement au grand-public de surveiller en cas de doute, l'idée est dangereusement débile.

Même si la fonction est limitée sur un nom de domaine opéré par Google, imaginez que nous ne sommes absolument pas à l'abri d'un bug dans Chrome. Et donc d'une tentative d'injection malicieuse d'une fausse URL. Et comme Chrome est le navigateur web le plus utilisé du marché, vous imaginez les conséquences désastreuses sur des injections réussies, par exemple sur des noms de domaines de banques.

Que l'équipe UX et l'équipe commerciale aient poussé cette idée de modification dynamique d'URL affichée jusqu'au développement, soit. Mais que l'équipe sécurité et prévention des risques n'a jamais pu faire contrepoids, inutile de vous dire que cela a instantanément fait perdre beaucoup de points au navigateur Chrome en termes de confiance sur les notions élémentaires de sécurité pour ses utilisateurs.

L'idée fut tellement stupide que 3 ans après le déploiement dans Google Chrome grand-public, la fonction semble avoir été supprimée du code du navigateur web sans aucune communication. Et de nos jours, en adaptant ma conférence d'origine pour cette émission radio, je ne trouve plus de sites web parlant de cette idée si géniale.

Quand t'es le moteur de recherche ultra-dominant, c'est plutôt facile d'effacer ses gaffes.

Mais [au moment de l'écriture de cette chronique] que reste-t-il en 2025 de AMP ?
D'abord, ça y est, la plupart des sites lancés sont conçus en mobile-first. On ne trouve plus de version de site différent suivant qu'on le consulte depuis un ordinateur de bureau ou depuis un smartphone. Enfin !
Ensuite, Google a retiré la possibilité de consulter la version mise en cache des sites web en 2024, donc l'hébergement par Google des sites AMP n'est plus sur google.com/amp mais sur ampproject.org. Et le nom de domaine du site d'origine n'est plus en path, mais en sous-domaine de ampproject.org, ce qui est presque un moindre mal.
Enfin, la plupart des spécifications AMP sont toujours disponibles ainsi que la collection de webcomponents. À mon avis, toutes ne sont pas à suivre, mais on peut y picorer les bonnes voire les très bonnes idées. À condition qu'elles respectent les standards et bonnes pratiques et qu'elles ne vous lient pas trop à Google, bien sûr.

Texte : Da Scritch,
Photo : Crime scene / Police scene tape, CC-By dpp-businesstax.com