Télécharger les sites web qui utilisent Snap.svg

À propos de Snap.svg

Qu’Adobe publie une bibliothèque JavaScript open source n’est pas la première chose que la plupart des gens associent à l’entreprise. La bibliothèque Snap.svg est arrivée en 2013, à ce moment où les navigateurs venaient enfin de s’accorder sur une implémentation exploitable des graphiques vectoriels, et avant que la compilation systématique dans un bundle de framework ne devienne la norme. Écrite en JavaScript et publiée par Adobe sous licence Apache 2.0, elle succédait à une bibliothèque vectorielle antérieure du même auteur et s’adressait à un web où une page chargeait un script et manipulait directement le document.

Le web a évolué, et c’est précisément ce qui rend le décompte intéressant. En octobre 2026 nous voyons encore Snap.svg sur 7 204 sites. Très peu sont des réalisations récentes. Une bibliothèque de cette génération survit parce qu’elle est transportée à l’intérieur d’autre chose, un thème, un vieux panneau d’administration, une infographie interactive construite par une agence depuis fermée, une page d’atterrissage que personne n’a ouverte depuis sa mise en ligne. Sa présence est donc un indice fiable sur l’âge et l’état de maintenance d’un front end, un signal souvent plus précieux que la fonction même de la bibliothèque.

La géographie suit la même logique. La concentration en dit moins sur les endroits où la bibliothèque a été appréciée que sur ceux où réside la longue traîne des sites commerciaux anciens, car les domaines commerciaux anglophones sont fortement représentés dans la couche du web qu’on a laissée tranquille pendant des années. L’attribution par pays est déduite des données d’hébergement et d’enregistrement plutôt que déclarée par les sites eux-mêmes.

Le public de cette liste découle de la même lecture. Les chercheurs en sécurité et en dépendances s’y intéressent parce qu’une bibliothèque client non maintenue est une question de chaîne d’approvisionnement, et un fichier de population leur permet de mesurer l’ampleur avec laquelle une dépendance figée est encore livrée. Les agences s’y intéressent parce qu’un site qui fait tourner une bibliothèque vectorielle d’une autre époque est une conversation de refonte en attente. Les auteurs de thèmes et d’extensions s’y intéressent parce que leurs propres produits sont souvent la raison de sa persistance, et une liste de domaines concernés montre jusqu’où voyage une dépendance embarquée. Quiconque étudie le cycle de vie du code front end s’y intéresse parce qu’il s’agit là de l’une des expériences naturelles les plus propres sur la durée de survie réelle d’une dépendance JavaScript après son heure de gloire.

Les réserves honnêtes valent dans les deux sens. Le bundling masque la bibliothèque, donc le nombre réel de pages qui l’incluent encore est supérieur à ce que nous pouvons voir. En même temps, un script peut être chargé sans jamais être appelé, si bien que sa présence ne prouve pas que le site s’en serve pour dessiner quoi que ce soit. Aucun de ces deux problèmes ne se résout en inspectant un domaine de plus près, ce qui est précisément l’argument en faveur du travail sur la population entière. Un fichier téléchargeable permet de traiter les questions qui comptent ici. Quelle est la taille de la traîne restante, à quelle vitesse se réduit-elle, et quels systèmes de contenu et quelles versions de serveur l’accompagnent quand on recoupe les mêmes domaines.