WebAssembly introduit un nouveau runtime dans le navigateur, qui fonctionne aux côtés du runtime JavaScript et en étroite collaboration avec lui. Il est relativement léger en comparaison, avec un petit jeu d'instructions et un modèle d'isolation strict (WebAssembly n'a pas d'E/S par défaut). L'HTTP Archive a publié son rapport sur les technologies Web pour 2022, appelé Web Almanac, basé sur une enquête portant sur plus de 8 millions de sites Web. Parmi ses conclusions, on trouve que « WebAssembly n'est pas largement utilisé, et plutôt que de voir une croissance de l'utilisation, nous assistons à une légère régression. »WebAssembly est un format binaire et, par conséquent, une grande partie des informations contenues dans la source - langage de programmation, structure de l'application, noms de variables - sont obscurcies ou entièrement perdues lors du processus de compilation. Cependant, les modules ont souvent des exportations et des importations, qui nomment les fonctions de l'environnement d'hébergement - le moteur d'exécution JavaScript du navigateur - qui décrivent l'interface du module.
La plupart des chaînes d'outils WebAssembly créent une petite quantité de code JavaScript, à des fins de "liaison", ce qui facilite l'intégration des modules dans les applications JavaScript. Ces liaisons ont souvent des noms de fonctions reconnaissables qui sont présents dans les exportations ou les importations des modules, ce qui donne un mécanisme fiable pour identifier le langage qui a été utilisé pour créer le module.
L'une des principales motivations du développement de WebAssembly était de fournir une cible de compilation pour un large éventail de langages de programmation (C++, Rust, Go, etc.), ce qui permet aux développeurs d'écrire de nouvelles applications Web ou de porter des applications existantes avec un ensemble d'outils plus large.
LikelyEmscripten (63,8% sur le bureau et 61,1% sur le mobile), Inconnu (11,7% et 16,9%), Emscripten (13,3% et 11,8%), Rust (8,0% et 6,0%), Blazor (2,7% et 3,5%) et Go (0,6% et 0,7%).
Parmi les exemples les plus connus de WebAssembly, citons son utilisation dans Google Earth, où l'application de bureau C++ est maintenant disponible dans le navigateur, Figma, un outil de conception basé sur un navigateur qui a bénéficié d'améliorations significatives des performances grâce à cette technologie, et plus récemment Photoshop qui utilise WebAssembly pour des raisons similaires.
Les sites Web concernés sont ceux analysés par le rapport Chrome UX de Google, qui couvre les sites accessibles au public qui sont « suffisamment populaires », bien que le nombre minimum exact de visiteurs ne soit pas divulgué. Selon l'enquête mensuelle de Netcraft, il existe plus de 1,1 milliard de sites, bien que beaucoup soient inactifs, de sorte que ce rapport ne se base que sur les plus actifs.
« Lors de l'enquête de septembre 2022, nous avons reçu des réponses de 1 129 251 133 sites répartis sur 271 625 260 domaines uniques et 12 252 171 ordinateurs connectés au Web. Ce mois-ci, les trois indicateurs ont diminué depuis le mois d'août, avec une perte de 5,82 millions de sites, 115 512 domaines uniques et 113 356 ordinateurs connectés au Web », Netcraft.
Nginx a connu la plus forte augmentation du nombre d'ordinateurs connectés au Web, avec un gain de 28 887 (+0,56 %). OpenResty a connu la deuxième plus forte augmentation, avec 6 008 ordinateurs connectés au Web (+3,54 %), 339 813 domaines (+0,86 %) et 149 893 sites actifs (+2,35 %). Google a enregistré une forte croissance dans tous les indicateurs, avec une augmentation de 5 127 ordinateurs connectés au Web, 211 135 (+8,83 %) domaines et 895 225 (+4,71 %) sites actifs.
Parmi le million de sites les plus actifs, Apache a perdu 0,21 % de sa part de marché. Malgré cela, il reste le serveur web le plus utilisé dans le million de sites les plus fréquentés. Nginx a également poursuivi sa tendance à la baisse à long terme, mais n'a perdu que 0,14 point, ce qui a permis de réduire encore l'écart entre Apache et Nginx. L'écart se situe désormais à 4 499 sites, soit une diminution de 13,8 % depuis le mois dernier. Pendant ce temps, la croissance de Cloudflare se poursuit, sa part de marché dans le million de sites les plus importants ayant augmenté de 0,25 %.
Apache a également subi une perte de part de marché globale, perdant 414 684 sites actifs (-0,94 %) et 18 156 ordinateurs (-0,49 %). Les seuls autres développeurs à perdre des sites actifs sont Microsoft et Nginx, avec des pertes respectives de 58 443 (-1,01 %) et (-0,10 %).
Il existe toutefois une réserve importante, notamment en ce qui concerne la technologie utilisée dans les applications web. Les robots d'exploration du Web ne se connectent généralement pas à une application Web, ils ne voient que le contenu public d'un site Web, de sorte que l'enquête ne couvre pas l'utilisation de la technologie Web dans ces applications. Cela pourrait fausser les résultats lorsqu'il s'agit de technologies plus centrées sur les applications, notamment WebAssembly.
Néanmoins, le blogueur technologique Colin Eberhardt, qui a rédigé l'analyse de WebAssembly dans le rapport, ne se retient pas, notant que la quantité de wasm (code WebAssembly compilé) dans les pages Web est minuscule. « Nous avons trouvé 3 204 requêtes WebAssembly confirmées sur ordinateur de bureau et 2 777 sur le mobile. Ces modules sont utilisés dans 2 524 domaines sur ordinateur de bureau et 2 216 domaines sur mobile, ce qui représente 0,06 % et 0,04 % de tous les domaines sur ordinateur de bureau et mobile respectivement », écrit-il.
Cela représente une baisse modeste du nombre de modules que nous avons découverts dans le crawl, soit une réduction de 16 % pour les requêtes de bureau et de 12 % pour les requêtes mobiles. Cela ne signifie pas nécessairement que WebAssembly est en déclin. Pour interpréter ce changement, il convient de noter ce qui suit :
- Bien que vous puissiez utiliser WebAssembly pour créer toutes sortes de contenus Web, son principal avantage se trouve dans les applications professionnelles plus complexes, avec des bases de code importantes, qui datent souvent de plusieurs années (par exemple Google Earth, Photoshop, AutoCAD). Ces applications Web ne sont pas aussi nombreuses que les sites Web et ne sont pas toujours disponibles pour le crawl de l'Almanach, qui est principalement basé sur les pages d'accueil où WebAssembly peut être moins répandu ;
- Une grande partie de l'utilisation de WebAssembly que nous voyons provient d'un nombre relativement faible de bibliothèques tierces. Par conséquent, un petit changement dans l'une de ces bibliothèques aura un impact significatif sur le nombre de modules que nous trouvons.
Nous avons trouvé un peu moins (-13 %) de modules WebAssembly servis aux navigateurs mobiles. Ce n'est pas une réflexion sur les capacités de WebAssembly des navigateurs mobiles, qui ont généralement un excellent support. Cela est plutôt dû à la pratique standard de l'amélioration progressive, où les fonctionnalités les plus avancées qui nécessitent WebAssembly ne sont pas prises en charge par les utilisateurs mobiles.
L'analyse de ces données montre que la part la plus importante, et de loin, revient à un produit appelé Amazon IVS (Interactive Video Service), un module de bibliothèque utilisé par le service AWS Chime pour optimiser les communications vidéo. Plutôt que d'être un choix conscient du développeur, il s'agit simplement d'une conséquence de l'utilisation de ce service AWS particulier. L'apparition du framework Blazor de Microsoft en troisième position pour l'utilisation la plus répandue de Wasm est peut-être plus significative, puisqu'il s'agit d'un code écrit par le développeur pour un site spécifique.
Eberhardt considère cependant qu'« il n'y a tout simplement pas de raison impérieuse d'utiliser WebAssembly pour le moment », la raison étant que le code Wasm ne peut pas remplacer JavaScript, mais seulement le compléter. Il pense que l'avenir de WebAssembly n'est peut-être pas « une technologie web de niche, mais un runtime tout à fait courant sur un large éventail d'autres plateformes ».
Il y a beaucoup d'autres choses intéressantes dans le rapport complet, qui mérite d'être examiné de près par les développeurs web désireux d'offrir les meilleures performances et la meilleure expérience à leurs utilisateurs. La plupart des 26 chapitres ont été publiés, mais nous attendons les rapports sur des sujets tels que la confidentialité, les données structurées et Jamstack.
Un point notable est que la plupart du code des sites web d'aujourd'hui provient de tiers, soit dans des bibliothèques, soit dans des scripts tiers importés, soit parce que le site est basé sur un CMS (Content Management System). Il s'ensuit également que l'utilisation d'une technologie (comme celle de WebAssembly) peut changer radicalement si elle est adoptée par une bibliothèque ou un CMS largement utilisé.
Nous avons trouvé 3 204 demandes WebAssembly confirmées sur le bureau et 2 777 sur le mobile. Ces modules sont utilisés dans 2 524 domaines sur ordinateur et 2 216 domaines sur mobile, ce qui représente 0,06 % et 0,04 % de tous les domaines sur ordinateur et mobile respectivement.
Diagramme à barres montrant le nombre de réponses totales de Wasm sur les ensembles de données de bureau et mobiles ainsi que le nombre de fichiers uniques. Le nombre de fichiers uniques est beaucoup plus faible - seulement 383 sur 3 204 réponses totales sur le bureau et 310 sur 2 777 sur le mobile.
En effectuant un hachage des modules WebAssembly, nous pouvons déterminer combien de ces 3 204 modules - sur le poste de travail - sont uniques. En déduisant les modules, le nombre total est réduit d'environ un facteur 10, avec 383 modules uniques servis aux navigateurs de bureau et 310 aux navigateurs mobiles. Cela indique une quantité importante de réutilisation - différents sites Web utilisant le même code WebAssembly, très probablement par le biais de modules partagés.
Une proportion importante des requêtes wasm ont une origine croisée, ce qui renforce encore l'idée qu'elles sont réutilisées. Il est à noter que cette proportion a considérablement augmenté par rapport à l'année dernière (67,2 % contre 55,2 %).
Diagramme à barres montrant que 67,2 % de l'utilisation de WebAssembly sur les ordinateurs de bureau et 60,9 % sur les téléphones mobiles sont d'origine croisée.
Ces modules WebAssembly diffèrent considérablement en taille, le plus petit ne faisant que quelques kilo-octets et le plus grand pesant 7,3 méga-octets. Si l'on regarde plus en détail la taille non compressée, on constate que la taille médiane (50e percentile) est de 835 Ko. Les modules WebAssembly les plus petits sont probablement utilisés pour des fonctionnalités assez spécifiques, par exemple le remplissage des fonctionnalités du navigateur ou des tâches de cryptage simples. Les plus gros modules sont probablement des applications entières compilées en WebAssembly.
Diagramme à barres montrant la distribution des tailles de réponse non comprimées sur ordinateur de bureau et mobile aux percentiles 25, 50, 75 et 90. On constate notamment qu'aux centiles 10, la taille est de 23 Ko, la médiane d'environ 835 Ko, et aux centiles 90, de 4,87 Mo sur ordinateur de bureau et de 3,24 Mo sur mobile.
Source : HTTP Archive
Et vous ?
Quel est votre avis sur le sujet ? Partagez-vous l'avis selon lequel WebAssembly serait surestimé ? Trouvez-vous pertinents les résultats de cette enquête ?Voir aussi :
Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude Les premières ébauches publiques du travail sur WebAssembly 2.0 ont été publiées, les objectifs de conception incluent une sémantique rapide, sûre et portable « Pourquoi j'ai quitté l'équipe WebAssembly de Google, et comment cela m'a rendu malade », un témoignage de Katelyn Gadd, conceptrice de jeux et programmeuse d'outils