Le gonflement de JavaScript en 2024

Le problème de taille de JavaScript

• J’étais relativement peu au fait du développement frontend moderne, et je me souvenais d’articles sur l’ampleur du web, avec des pages atteignant plusieurs mégaoctets.
• J’avais l’impression que si la taille moyenne d’une page web est de 3 MB, le bundle JavaScript devait représenter environ 1 MB.
• J’ai donc mené une expérience pour vérifier ce qu’il en est réellement.

Méthode

• Utilisation de Firefox sur macOS (cela devrait être similaire sur d’autres navigateurs)
• Mode normal, pas en navigation privée (je voulais voir les chiffres à l’intérieur des applications, et cela me semblait plus proche de l’expérience réelle)
• Toutes les extensions désactivées
• Mesure du JavaScript uniquement
• Non compressé
• Service workers activés (pour une situation plus réaliste)
• Tout le cache désactivé (chargement depuis zéro)

Pages d’accueil

• Exemple de page typique avec un peu d’interaction : Wikipedia, 0.2MB
• Exemple de page légèrement gonflée : Linear, 3MB
• Exemples de mauvaises pages d’accueil : Zoom, 6MB ; Vercel, 6MB ; Gitlab, 13MB

Sites web principalement statiques

• Il est difficile de faire plus simple qu’un mur de texte statique.
• Medium a pourtant besoin de 3MB rien que pour cela.
• Substack demande 4MB, Quora 4.5MB, Pinterest 10MB et Patreon 11MB.

Recherche

• L’interaction de l’application se limite principalement à la recherche.
• StackOverflow nécessite 3.5MB, NPM 4MB, Airbnb 7MB et Booking.com 12MB.
• Google a besoin de 9MB pour afficher un simple champ de texte et une liste de liens.

Applications à interaction unique

• Google Translate a besoin de 2.5MB pour deux zones de texte.
• ChatGPT a besoin de 7MB pour une seule zone de texte.

Vidéo

• Loom demande 7MB, YouTube 12MB.
• Pornhub, un site attentif aux performances, ne demande que 1.4MB.

Audio

• SoundCloud et Spotify demandent tous deux 12MB.

E-mail

• Google Mail nécessite 20MB.
• FastMail offre la même fonctionnalité avec seulement 2MB.

Productivité

• Todoist demande 9MB, Dropbox 10MB, 1Password 13MB et Trello 13.5MB.
• Discord a besoin de 21MB pour le chat.

Édition de documents

• Google Docs nécessite 13.5MB, Notion 16MB.

Réseaux sociaux

• Twitter demande 11MB, Facebook 12MB, TikTok 12.5MB, Instagram 16MB et LinkedIn 31MB.

Catégorie des géants

• Jira nécessite presque 50MB, Slack 55MB.
• react.dev commence à 2MB, mais peut grossir sans limite à mesure qu’on fait défiler la page.

Est-ce que cela s’aggrave de plus en plus vite ?

• En 2015, la taille moyenne d’une page web se rapprochait de celle de la version shareware de Doom 1 (2.5MB).
• En 2024, Slack atteint 55MB, soit, en JavaScript seul, la taille du Quake 1 original.

Quelle taille représente 10MB ?

• 10MB ne semble plus si énorme ni si particulier aujourd’hui.
• En supposant en moyenne 65 caractères par ligne, cela signifie qu’environ 150,000 lignes de code sont envoyées pour chaque site web.
• Google Maps reste relativement modeste selon les standards actuels, avec 4.5MB.

Conclusion

• La taille du téléchargement n’est pas le seul problème.
• Le JavaScript doit être analysé par le navigateur, conservé en mémoire, puis exécuté.
• Le contenu devrait, selon moi, l’emporter sur la taille du code.
• Gitlab a besoin de 13MB de code, soit plus de 500K lignes de JS, pour afficher une page d’accueil statique.

Avis de GN⁺ :

1. Un diagnostic réaliste de l’état actuel du développement web, qui aide à comprendre l’impact de la taille du JavaScript des sites sur l’expérience utilisateur et les performances.
2. Un rappel, à destination des développeurs frontend, de l’importance de l’optimisation et de la nécessité d’éviter l’usage de ressources au-delà du nécessaire.
3. Des données intéressantes qui peuvent alimenter les discussions au sein de la communauté des développeurs autour des performances des sites web.

[GN⁺]

Commentaires sur Hacker News

• Les sites pour adultes sont en fait un cas où l’on se soucie vraiment des performances : Pornhub ne charge que 1,4 Mo de données. C’est bien meilleur que les performances montrées par certains grands groupes technologiques. Pornhub se trompe rarement sur les bases de l’UI/UX ou de la diffusion de contenu.
• En utilisant le roaming dans une zone rurale de Nouvelle-Zélande, l’expérience du web était très pénible. L’expérience utilisateur (UX) hors ligne de Spotify a elle aussi besoin d’être améliorée.
• Certains se demandent pourquoi on regarde des données non compressées. Des applications dynamiques comme Spotify et Gmail peuvent être pardonnées si la navigation est rapide après le chargement de la page. Certains sites privilégient le chargement initial au détriment de l’expérience utilisateur.
• Le logiciel reflète l’organisation qui l’a créé. La majeure partie des données transférées n’est pas du JavaScript nécessaire au fonctionnement réel de la page, mais des scripts d’analyse et de tiers. Les équipes marketing sont soit ignorantes de ces sujets, soit ne s’y intéressent pas.
• Il manque une analyse de la taille des fichiers JavaScript des applications web. Par exemple, Google Translate n’est pas une simple application interactive et inclut beaucoup de fonctionnalités, mais 2,5 Mo restent excessifs.
• Sur le site Wordsandbuttons.online, toutes les pages font moins de 64 Ko malgré les animations et l’interactivité. Cela est possible grâce à une politique sans dépendances tierces.
• Il faut discuter non seulement de l’usage excessif de JavaScript, mais aussi de la quantité de scripts de suivi.
• Une comparaison est faite entre la quantité de JavaScript chargée par des sites populaires. Par exemple, Pornhub charge environ 10 fois moins de JavaScript que YouTube.
• L’état actuel du web est profondément triste. Les personnes disposant d’une connexion internet rapide ne se rendent pas compte à quel point le web est devenu lent. Il est difficile d’imaginer ne pas utiliser de bloqueur de pub/trackers.
• On crée des frameworks et des abstractions complexes pour faciliter la maintenance, mais beaucoup de développeurs ne maîtrisent même pas les bases de JavaScript. On suringénierise les applications web et on ajoute trop de couches qui masquent le langage réel. Apprendre JavaScript lui-même et utiliser du JavaScript pur plutôt qu’un framework peut réduire fortement la taille d’une codebase JavaScript.