La boursouflure de JavaScript en 2024
(tonsky.me)- Il devient courant que des pages web téléchargent du JavaScript non compressé bien plus volumineux que leur contenu réel, ce qui alourdit la charge pour le navigateur, de la simple landing page aux applications professionnelles
- Les mesures ont été réalisées avec Firefox sur macOS, extensions et cache désactivés, en ne comptabilisant que JavaScript, afin de se concentrer sur le coût d’exécution du code en excluant images, vidéos et styles
- Wikipedia était à 0,2 Mo, mais même des pages simples montent à plusieurs mégaoctets, voire à deux chiffres, comme Linear à 3 Mo, Zoom et Vercel à 6 Mo, ou GitLab à 13 Mo
- Côté applications, Gmail atteint 20 Mo contre 2 Mo pour FastMail, soit un facteur 10, tandis que la quantité de code des outils de chat et de travail est particulièrement élevée, avec Jira autour de 50 Mo et Slack à 55 Mo
- Même après le téléchargement, JavaScript entraîne des coûts de parsing, maintien en mémoire et exécution ; une architecture qui nécessite d’énormes bundles de code pour afficher un petit contenu pèse donc directement sur les performances et la batterie
Méthode de mesure et critères de comparaison
- L’environnement de mesure était Firefox sur macOS, en partant du principe que les résultats seraient globalement similaires avec d’autres navigateurs
- Les conditions étaient les suivantes
- Mode normal, pas en navigation privée
- Toutes les extensions désactivées
- Mesure de JavaScript uniquement
- Taille non compressée
- Service Worker activé
- Chargement à froid avec cache désactivé
- Le contenu a été exclu de la comparaison, car il varie fortement selon les sites
- Les vidéos de YouTube et les messages texte de Slack ont par nature des tailles différentes
- JavaScript est utilisé comme indicateur commun pour comparer la complexité des interactions
- Le point central est la quantité de travail que le navigateur doit fournir pour parser et exécuter le code
- Comme point de référence, le blog tonsky.me lui-même a été mesuré à 0,004 Mo
Landing pages et contenu statique
- Parmi les exemples de pages ordinaires avec un peu d’interaction, Wikipedia se situe autour de 0,2 Mo
- Les landing pages plus lourdes sont les suivantes
- Linear : 3 Mo
- Zoom : 6 Mo
- Vercel : 6 Mo
- GitLab : 13 Mo
- Ces chiffres correspondent à la taille du seul code JavaScript, hors images, vidéos et styles
- Même des sites web qui affichent du texte statique téléchargent plusieurs mégaoctets de JavaScript
- Medium : 3 Mo
- Substack : 4 Mo
- Quora : 4,5 Mo
- Pinterest : 10 Mo
- Patreon : 11 Mo
- Il existe des cas où de gros bundles JavaScript sont utilisés pour afficher du contenu qui semblerait possible à servir sous forme de page statique
Recherche et applications à interaction simple
- Les applications centrées sur la recherche reposent surtout sur la saisie de requêtes et l’affichage de listes de résultats, mais leur taille JavaScript n’est pas faible
- StackOverflow : 3,5 Mo
- NPM : 4 Mo
- Airbnb : 7 Mo
- Booking.com : 12 Mo
- Google Search a été mesuré à 9 Mo, alors même que son écran est principalement constitué d’un champ texte et d’une liste de liens
- Même des services avec une UI de saisie simple utilisent plusieurs mégaoctets de JavaScript
- Google Translate : 2,5 Mo
- ChatGPT : 7 Mo
- Indépendamment du fait que la complexité de ChatGPT se trouve côté serveur, le navigateur reçoit 7 Mo de JavaScript
Services médias et e-mail
- La taille JavaScript des services vidéo est la suivante
- Loom : 7 Mo
- YouTube : 12 Mo
- Pornhub : 1,4 Mo
- Pour les services audio, SoundCloud et Spotify ont chacun été mesurés autour de 12 Mo
- Dans les services d’e-mail, l’écart est important
- Google Mail : 20 Mo
- FastMail : 2 Mo
- FastMail utilise 10 fois moins de JavaScript que Google Mail dans la même catégorie de services d’e-mail
- Les 20 Mo de Google Mail constituent un chiffre suffisamment élevé pour être comparé à des applications comme Figma, qui incluent un rendu personnalisé en C++/OpenGL
Outils de productivité et édition de documents
- Les applications de productivité embarquent elles aussi beaucoup de JavaScript au regard de tâches simples
- Todoist : 9 Mo
- Dropbox : 10 Mo
- 1Password : 13 Mo
- Trello : 13,5 Mo
- Discord : 21 Mo
- Dropbox utilise plus de 10 Mo pour afficher la liste des fichiers d’un dossier, 1Password pour une liste de mots de passe, et Trello pour afficher des cartes
- Les services d’édition de documents se situent à des niveaux à deux chiffres en mégaoctets
- Google Docs : 13,5 Mo
- Notion : 16 Mo
- L’édition de documents implique certes des fonctionnalités difficiles, comme le déplacement du curseur et la synchronisation, mais la taille JavaScript des services comparés reste élevée
Réseaux sociaux et cas extrêmes
- Les réseaux sociaux utilisent généralement autour de 12 Mo de JavaScript pour les likes, les fils, la messagerie, etc.
- Twitter : 11 Mo
- Facebook : 12 Mo
- TikTok : 12,5 Mo
- Instagram : 16 Mo
- LinkedIn : 31 Mo
- LinkedIn comprend à la fois blog, plateforme, recherche, messagerie et fonctions sociales, et a été mesuré à 31 Mo
- Les très grosses web apps relèvent presque d’une catégorie à part
- Jira : près de 50 Mo
- Slack : 55 Mo
- Slack est une application de chat qui gère listes d’utilisateurs, messages et réactions, mais télécharge 55 Mo de JavaScript
- react.dev commence initialement à 2 Mo, mais on observe que JavaScript continue d’augmenter lorsqu’on fait défiler la page de manière répétée
- Dans l’exemple, il a été possible de monter jusqu’à 100 Mo
- D’après une mise à jour, dans l’expérience utilisateur normale, l’éditeur de code intégré est mis en cache après le premier chargement, et le trafic réseau n’apparaît plus ensuite
- Toutefois, lors du défilement, 100 Mo de JavaScript peuvent continuer à être parsés, évalués et initialisés
Ce que signifient 10 Mo de code
- En 2015, la taille moyenne d’une page web se rapprochait des 2,5 Mo de la version shareware de Doom 1
- En 2024, Slack atteint, avec JavaScript seul, les 55 Mo correspondant à l’ensemble des ressources du Quake 1 original
- 10 Mo de code semblent être devenus un niveau ordinaire, mais en supposant une ligne moyenne de 65 caractères, cela représente environ 150 000 lignes
- Comme ce code est déjà minifié, il pourrait correspondre à plus de 300 000 lignes en version source
- Google Maps est souvent cité comme exemple emblématique de SPA, mais a été mesuré à 4,5 Mo, ce qui le rend plutôt léger au regard des web apps modernes
- Figma est une application frontend complexe, il est donc naturel que la taille de JavaScript téléchargée soit élevée, mais Gmail est comparable à Figma, LinkedIn atteint 1,5 fois ce niveau, et Slack 2,5 fois
Le coût payé par le navigateur
- Le problème ne s’arrête pas à la taille du téléchargement
- JavaScript doit être parsée, conservée en mémoire et exécutée par le navigateur, ce qui crée un coût durable
- Si l’on part du principe que la taille du contenu devrait être supérieure à celle du code, une architecture qui nécessite un JavaScript 1 000 fois plus gros pour rendre un billet de blog de 10 000 caractères est excessive
- Les sites cités comme bons exemples fonctionnent correctement avec seulement 0,1 Mo de JavaScript
- Dans le même environnement web, GitLab est comparé comme un cas nécessitant 13 Mo, soit plus de 500 000 lignes de JavaScript, pour afficher une landing page statique
1 commentaires
Avis sur Hacker News
Il suffit de comparer des choses comme 10 Mo ou 12 Mo avec Pornhub à 1,4 Mo, qui se soucie vraiment des performances.
Les sites porno ont toujours été de la vraie high-tech du Web, avec une bonne ingénierie, contrairement aux grandes entreprises de “tech” qui ressemblent à une blague.
Je n’ai presque aucun souvenir d’eux ayant raté l’UI/UX de base, la diffusion de contenu ou une conception de bon sens.
On a l’impression que, parce que dans les vraies applications Web un rechargement de page est un comportement indésirable, tout le monde s’est soudain mis à craindre les rechargements de page sur les sites Web.
J’ai travaillé 20 ans sur des applications d’entreprise, et j’ai vu des systèmes créés avant ma naissance ; dans ces systèmes, React était selon moi le meilleur front-end pour remplacer les terribles UI client/serveur d’avant.
Angular/Vue et autres s’inscrivent dans la même logique. Mais pour des pages Web ordinaires, c’est rarement nécessaire, sauf dans des cas comme Gmail ou Facebook, où l’interaction et les mises à jour en temps réel sont au cœur du produit.
Pour un site comme Pornhub, PHP suffit largement, et c’est pareil pour la plupart des sites Web. Il suffit de voir combien de gens préfèrent encore HN ou old.reddit.com, et je pense que beaucoup préféreraient aussi old.Facebook au nouveau Facebook devenu plus lent.
Pop-ups, pop-unders, envoi vers des sites agrégateurs similaires avec du faux contenu, ouverture de sites affiliés à la place du contenu, pollution des résultats de recherche, etc.
Le porno n’est pas une industrie qui tire la technologie autant qu’on le dit ; la légende urbaine Betamax contre VHS n’est pas vraie non plus, et l’idée qu’il aurait porté l’innovation sur Internet est exagérée.
Il existe quelques acteurs qui produisent des produits de qualité, mais ils ne représentent pas tout le secteur. Il y a beaucoup de fermes de liens, de contenu factice, de sites clonés, de publicité mensongère et de manipulation des résultats de recherche.
Si les grands sites actuels sont réactifs, cela ressemble à un résultat de la concurrence. Si l’UX est mauvaise, comme le porno gratuit abonde, les utilisateurs partent aussitôt ailleurs ; il faut donc optimiser pour la rétention.
Les autres sites Web ont d’autres incitations — actionnaires, fournisseurs de contenu, contrats d’exclusivité, position monopolistique — qui font qu’ils n’ont pas besoin d’optimiser l’expérience utilisateur autant que ça.
On passe un nombre incalculable d’heures à optimiser toutes sortes de choses : diffusion vidéo, live streaming (avant en Flash, maintenant en WebRTC), taille des pages, etc.
Je me demande pourquoi on regarde les données avant compression. Plusieurs des sites cités comme mauvais exemples deviennent facilement plus petits que les 1,5 Mo de GMaps une fois compressés.
Pour des apps dynamiques comme Spotify ou GMail, ça me va si la navigation après le chargement de la page est rapide.
Je préfère Discord, qui prend quelques secondes au démarrage pour se mettre à jour, à GitLab, qui vous fait attendre jusqu’à 2 secondes à chaque clic.
Je pense que la priorité actuelle donnée au cold start et au rendu statique dégrade au contraire l’expérience sur certains sites.
À titre d’essai, naviguez dans l’arborescence des fichiers sur GitHub : sur ma machine, c’est bien plus réactif que les autres parties de GitHub. Par coïncidence, c’est l’une des rares parties qui ne repose pas sur du rendu statique.
Je clique chaque jour sur des centaines de pages GitHub ; au lieu de me faire retélécharger tout le footer à chaque fois que je veux voir un pipeline, j’aimerais qu’ils m’envoient une seule fois une énorme quantité de JavaScript et qu’ils en mettent le plus possible en cache.
[1] : GMail et Spotify ne sont que des exemples, je ne les utilise pas réellement.
Ce problème revient souvent dans les discussions sur l’accessibilité : l’écart de performances CPU entre iOS et Android est important, et si l’on inclut les appareils bas de gamme utilisés par le grand public, certains appareils Android neufs vendus aujourd’hui sont plus lents qu’un iPhone de 2014.
Si les développeurs n’utilisent que le dernier iPhone ou des Android haut de gamme, ils passent facilement à côté de l’impact réel de l’obésité du code sur l’utilisateur médian.
https://infrequently.org/2024/01/performance-inequality-gap-...
La mise en cache réduit le coût en énergie et en temps du téléchargement et de la décompression, mais elle ne supprime pas le coût de l’utilisation effective.
D’après ma règle empirique personnelle, plus le JavaScript avant compression est gros, plus il y a de code que le CPU exécute en continu quand on bouge la souris, appuie sur une touche ou fait défiler la page.
Je préfère sacrifier un peu d’efficacité temporelle pour gagner en efficacité énergétique, et là où CSS peut remplacer ces comportements, je préfère le statique aux jolies animations.
Ou bien le vrai problème, encore plus important, ce sont peut-être les sites qui téléchargent davantage de fichiers pour de multiples actions au-delà d’un simple clic menant à une autre URL. C’est une obésité cachée, et c’est aussi très mauvais pour l’archivage.
J’aimerais qu’on évite de faire apparaître une autre “page” avec JavaScript tout en gardant la même URL dans la barre d’adresse. C’est vraiment mauvais aussi pour l’archivage.
Une autre règle empirique : plus le JavaScript avant compression est gros, moins il y a de chances que la version archivée du site fonctionne correctement.
La semaine dernière, mon Internet était lent ; quand je cliquais sur un fichier sur le site GitHub, il essayait de le charger par script puis échouait, et l’arborescence des fichiers ne fonctionnait littéralement pas.
En revanche, si je copiais l’URL du fichier et la collais dans la barre d’adresse du navigateur, elle se chargeait correctement.
Spotify a de gros problèmes de connectivité réseau. Même quand on télécharge un album, il panique complètement si le réseau change. Un simple mode hors ligne vaut mieux que ses tentatives permanentes de rester en ligne.
Il est difficile de juger toute cette architecture à partir de cet exemple ; c’est un peu comme pointer du doigt une très mauvaise SPA et dire que toutes les SPA sont nulles.
Tout logiciel reflète l’organisation qui l’a produit
La majeure partie des données transférées n’est probablement pas du JavaScript réellement nécessaire au fonctionnement de la page, mais des outils d’analyse et toutes sortes de scripts tiers
Seule la catégorie « elephant » correspond à des modules chargés paresseusement comme React
Beaucoup de ces choses sont pilotées par des équipes marketing qui ne connaissent pas ce problème ou ne s’en soucient pas
Souvent, les développeurs se sont contentés d’ajouter Google Tag Manager ou un autre service d’injection de scripts à la page. Dans certains cas, les développeurs ne font même pas cela : c’est un proxy dans l’infrastructure d’exploitation qui modifie la page
Une inquiétude plus significative est peut-être que le marketing ait davantage de contrôle sur le résultat que les personnes qui font réellement le travail
Dans le cas des pages « elephant », l’obésité se trouve dans l’organisation elle-même. Ce n’est pas le problème de quelques idiots, mais d’idiots à grande échelle
Dans mon précédent emploi, un département non technique avait la main sur Google Tag Manager, et il fallait surveiller en permanence les saletés injectées dans les pages de production
Je me suis vraiment battu très dur pour m’en débarrasser
Le Google de la recherche l’était davantage que Yahoo, et Chrome l’était aussi, à son lancement, par rapport à IE/Firefox
Chrome lui-même n’avait presque pas d’interface utilisateur, et c’était une fonctionnalité
Je reviens récemment d’un road trip en Nouvelle-Zélande, et dans une grande partie des zones rurales, il y a très peu de signal mobile, voire aucun
Avec l’itinérance en plus, on a l’impression d’ajouter encore une couche de lenteur, ce qui rend une grande partie du web vraiment pénible à utiliser
S’il y a un PM de Spotify, j’aimerais qu’il se penche sur l’UX hors ligne. Le hors ligne est l’une des fonctionnalités clés de l’offre Premium, mais en pratique l’application est vraiment très mauvaise sur beaucoup de points quand on essaie de l’utiliser hors ligne
Quand Spotify estime qu’il y a Internet, il demande au serveur tout le contenu des menus contextuels, attend une réponse pendant plusieurs secondes, puis parfois renonce à afficher le menu, et parfois revient à l’action qui aurait été immédiate en mode hors ligne
Je déteste vraiment ce lecteur
Dans les états intermédiaires, avec une latence très élevée ou beaucoup de pertes, il devrait en pratique se comporter comme s’il était hors ligne, mais Spotify pense être en ligne
Cela dit, ce problème est très courant et Spotify n’est pas le seul à échouer là-dessus ; il doit être difficile de fixer les bons seuils
Je ne comprends pas pourquoi Spotify me fait attendre 30 secondes pour charger quelque chose dans l’application quand il n’y a pas de signal. Je veux juste continuer à écouter un podcast téléchargé
Je me demande quelle décision d’ingénierie a rendu si complexe la pondération de ce scénario
Cet article passe complètement à côté du fait qu’il ne démonte pas vraiment pourquoi les fichiers JavaScript sont aussi gros dans de vraies applications web
Par exemple, si l’on regarde Google Translate de près, ce n’est pas une application où l’on interagit une seule fois puis c’est terminé. Il y a un dictionnaire, des suggestions alternatives, la translittération, la prononciation, plusieurs modes de saisie, etc.
Même en tenant compte de cela, 2,5 Mo restent trop, et je pense que certaines fonctionnalités optionnelles peuvent et devraient être chargées paresseusement, mais l’article est trop paresseux pour contribuer à une discussion plus approfondie
Combien de JavaScript faut-il vraiment pour
if data.transliteration show icon with audio embed?Je comprends, les images pouvaient être grosses et nombreuses, mais c’était un peu ironique
Je comprends que l’idée ici soit « il y a trop de JavaScript », mais il faut aussi parler de la part qui n’est que de la saleté de tracking
Le pire, c’est que certaines ne sont pas liées au code hôte mais chargées depuis l’extérieur, ce qui augmente la latence et les risques potentiels de sécurité
C’était un outil qui permettait aux marketeurs d’injecter n’importe quelle saleté dans une application web sans intervention des développeurs
Les relations se sont un peu dégradées, je n’ai pas gagné, et les performances restent médiocres
Ensuite, les problèmes de performance viennent de bibliothèques lourdes comme les cartes et les graphiques, ce qui se règle généralement avec un chargement paresseux intelligent
Parmi les cas que j’ai vécus : une toute petite fonctionnalité qui chargeait au démarrage une bibliothèque de scan de QR code et une bibliothèque de cartes ; toutes les chaînes d’internationalisation récupérées au démarrage via des requêtes en cascade, bloquant avant l’exécution du moindre JS ; Zendesk qui détruisait complètement les performances de la page, mais comme c’était une directive d’en haut, on n’a pu que le mettre en chargement différé
Ensuite viennent le code mal conçu qui déclenche trop d’éléments DOM, de rerenders ou de requêtes en cascade
Enfin vient la taille du code au niveau de l’application, qui peut aussi se corriger par du chargement paresseux, mais ce n’est généralement pas nécessaire avant que l’application devienne vraiment énorme
Par exemple, la landing page de GitLab passe de 13 Mo à « seulement » 6 Mo quand on bloque les scripts de tracking
Le département marketing doublera toujours l’obésité logicielle
Comparaison de la quantité de JavaScript chargée par des sites populaires lors d’un chargement à froid. Les points principaux sont les suivants
PornHub charge environ 10 fois moins de JS que YouTube (1,4 Mo contre 12 Mo)
Gmail a une empreinte difficile à comprendre (20 Mo). Fastmail est 10 fois plus léger avec 2 Mo, et Figma, qui est pourtant une appli plus complexe, est dans les mêmes eaux avec 20 Mo
Jira à 58 Mo, c’est énorme
Jira, une fois téléchargé, se chargera localement comme une appli hors ligne jusqu’à la prochaine mise à jour
Pornhub a de fortes chances d’être lancé en navigation privée, donc le cache n’aide pas
Jira aussi est horrible et lent
Toutes les pages de https://wordsandbuttons.online/ font toujours moins de 64 Ko, même avec des animations et des interactions
Par exemple, cette page https://wordsandbuttons.online/trippy_polynomials_in_arctang... fait 51 Ko
Le code n’est pas du tout économe non plus. 80 % est du copier-coller avec de petites variations, sans tentative astucieuse de le réduire. Tout est en vieux JS vanilla, sans compression ni suppression des espaces
Si on ouvre « View page source », le code est parfaitement lisible
Le secret, c’est une politique de zéro dépendance. Pas de tiers, pas de dépendance interne. Tout le code nécessaire arrive avec le fichier HTML
Paradoxalement, à long terme, le copier-coller n’est pas une cause de bloat, mais un garde-fou contre lui
Sur mobile, les bords sont littéralement invisibles
Les dépendances ne sont pas la cause, mais un symptôme. Les sites web et les entreprises n’ont plus vraiment d’incitation à réduire le bloat, donc les dépendances redondantes sont rarement nettoyées
Cela me rappelle l’article The Website Obesity Crisis de 2015 [1]. Depuis [2], la situation a empiré, et presque 10 ans ont déjà passé
Est-ce idiot de dire que, dans 10 ans, il sera impossible de naviguer sur le Web avec un PC des environs de 2015 ? Si rien ne change, c’est ce qui semble se profiler
Même avec un Firefox récent sur un vieux MacBook de 2013, il n’arrive pas à encaisser les 23,98 Mo de JavaScript d’une page https://civitai.com et se bloque environ 30 secondes en essayant de rendre ce front-end web catastrophique
Ce n’est pas seulement un problème du Web. Les applis mobiles tout-en-un sont devenues tellement grosses qu’elles ne se chargent pas non plus sur un téléphone de 2013, et la moitié d’entre elles sont écrites sur une stack de technologies web
Je ne comprends pas pourquoi des entreprises avec de gros budgets ne peuvent pas se permettre d’utiliser des applications natives
[1] https://idlewords.com/talks/website_obesity.htm
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
L’état du Web est vraiment triste
La plupart des gens qui ont une connexion fibre ne se rendent même pas compte à quel point le Web est devenu lent
Mais quand on est encore sur une connexion à 2 Mbit/s, c’est vraiment terrible. C’est mon cas, et c’est pénible
Du coup, ne pas utiliser de bloqueur de pub / de traqueurs est tout simplement impensable
J’aimerais voir ce test avec Ublock Origin activé
Je soupçonne que la majeure partie de ce code sert au suivi des utilisateurs et à la gestion des publicités
Je ne comprends pas l’idée selon laquelle, alors que nous avons des ordinateurs plus puissants et des réseaux plus rapides, il faudrait continuer à se concentrer sur le fait de rendre les applis et les sites web toujours plus petits
Grâce à la loi de Moore, les développeurs ont pu sacrifier l’optimalité, pousser plus loin et avancer vite, et c’est souvent ce qui s’est passé