JavaScript Bloat in 2024

Je me sentais un peu déconnecté du développement front-end moderne. Je me souvenais également des articles sur le gonflement du web, comment la taille moyenne d’une page web approchait plusieurs mégaoctets !

Tout ce temps, j’étais sous l’impression que, par exemple, si la taille moyenne d’une page web est de 3 Mo, alors le bundle JavaScript devrait être d’environ 1 Mo. Le contenu devrait toujours prendre la majorité, non ?

Eh bien, la seule façon de le savoir est de tester. Faisons une vérification de la réalité !

J’écris ceci en 2024, peut-être une suite dans quelques années ?

Méthode

• Firefox sur macOS (mais devrait être similaire dans n’importe quel navigateur)
• Pas en mode incognito (je veux voir les chiffres à l’intérieur de l’application, et il y a plus de chances qu’elle ressemble à une expérience quotidienne réelle)
• Toutes les extensions désactivées
• Uniquement JavaScript
• Non compressé
• Service Workers activés (encore une fois, plus proche de la réalité)
• Tous les caches désactivés (chargement à froid)

Pourquoi seulement JavaScript ? Le contenu varie beaucoup d’un site à l’autre (les vidéos sur YouTube sont sûrement plus lourdes que les messages texte sur Slack), mais JavaScript est une mesure universelle de la « complexité des interactions ».

L’objectif principal est d’évaluer le travail que le navigateur doit faire pour analyser et exécuter le code.

Pour établir une base, commençons par ce blog :

Le chiffre ici serait de 0,004 Mo. J’ai également mis en évidence tous les éléments importants dont vous avez besoin pour reproduire cela chez vous.

Pages d’atterrissage

D’accord, commençons par quelque chose de simple, comme les pages d’atterrissage/applications non interactives.

Une page normale légèrement interactive ressemble à ceci - Wikipedia, 0,2 Mo :

Légèrement gonflé - comme ceci - Linear, 3 Mo :

Rappelez-vous : sans images, ni vidéos, ni même styles ! Juste du code JS.

Une mauvaise page d’atterrissage ressemble à ceci - Zoom, 6 Mo :

ou comme Vercel, 6 Mo :

Oui, c’est juste une page d’atterrissage. Pas d’application, pas de fonctionnalité, pas d’appels. 6 Mo de JavaScript juste pour ça.

Vous pouvez faire bien pire, cependant - Gitlab, 13 Mo :

Encore juste la page d’atterrissage.

Sites Web principalement statiques

Rien de plus simple que d’afficher un mur de texte statique. Medium a besoin de 3 Mo juste pour cela :

Substack a besoin de 4 Mo :

Progrès ?

Quora, 4,5 Mo :

Pinterest, 10 Mo :

Patreon, 11 Mo :

Et tout cela aurait pu être une page statique…

Recherche

Lorsque l’interactivité de votre application se limite principalement à la recherche. Tapez la requête - affichez la liste des résultats. Combien cela pèse-t-il ?

StackOverflow, 3,5 Mo :

NPM, 4 Mo :

Airbnb, 7 Mo :

Booking.com, 12 Mo :

Mais Niki, la réservation est compliquée ! Regardez tous ces filtres. Toutes ces fenêtres contextuelles sur les gens près de vous qui volent vos vacances !

D’accord, d’accord. Quelque chose de plus simple alors. Google. Et Google ? Un champ de texte, liste de liens. Pas vrai ?

Eh bien, cela vous coûtera un énorme 9 Mo :

Juste pour afficher une liste de liens.

Applications simples à une seule interaction

Google Traduction n’est que deux champs de texte. Pour cela, vous avez besoin de 2,5 Mo :

ChatGPT n’est qu’un champ de texte. 7 Mo :

Je veux dire, bien sûr, ChatGPT est complexe. Mais sur le serveur, pas dans le navigateur !

Vidéos

Loom - 7 Mo :

YouTube - 12 Mo :

Comparez cela avec des gens qui se soucient vraiment des performances - Pornhub, 1,4 Mo :

Audio

Je suppose que l’audio nécessite simplement 12 Mo quoi qu’il arrive :

SoundCloud :

Spotify :

Email

D’accord, la vidéo et l’audio sont probablement lourds (même si nous ne mesurons pas le contenu, juste le JS, souvenez-vous !). Passons à des tâches de bureau plus simples.

Google Mail n’est que (juste !) 20 Mo :

C’est une boîte aux lettres !!! Comment diable est-elle presque aussi grande que Figma, qui embarque un rendu personnalisé complet en C++/OpenGL pour leur application ?

Et si vous pensez : le courrier électronique est aussi compliqué. Beaucoup d’UI, beaucoup d’interactivité. Peut-être que 20 Mo c’est correct ?

Non !

Juste non. Voyez, FastMail, même principe, mais seulement 2 Mo. 10× moins !

Productivité

D’accord, peut-être que l’e-mail est trop compliqué ? Et quelque chose de plus simple ? Comme une liste de tâches à faire ?

Eh bien, voici Todoist, 9 Mo :

Afficher une liste de fichiers dans des dossiers nécessite 10 Mo dans Dropbox :

Liste de mots de passe ? Ce sera 13 Mo sur 1Password :

Des cartes ? Ajoutez 0,5 Mo de plus, jusqu’à 13,5 Mo. Trello :

D’accord, peut-être que les listes de tâches à faire sont aussi complexes ? Et discuter ?

Eh bien, Discord a besoin de 21 Mo pour cela :

Édition de documents

D’accord, l’édition de documents est difficile, non ? Vous devez implémenter le déplacement du curseur, la synchronisation, etc.

Google Docs, 13,5 Mo :

Quelque chose de plus simple ? Notion, 16 Mo :

Réseaux sociaux

La taille typique du code dont les réseaux sociaux ont besoin pour que les boutons J’aime fonctionnent est de 12 Mo.

Twitter, 11 Mo :

Facebook, 12 Mo :

TikTok, 12,5 Mo :

Instagram est étonnamment plus grand que Facebook, malgré ayant environ 10× moins de fonctions. 16 Mo :

LinkedIn. Est-ce un blog ? Une plateforme ? Il a une recherche, une messagerie, des fonctions sociales. Quoi qu’il en soit, cela fera 31 Mo :

En passant, j’aimerais vous ajouter à mon réseau professionnel sur LinkedIn.

Éléphants - leur propre catégorie

Parfois, les sites web sont tellement stupides et absurdes qu’ils méritent leur propre catégorie.

Ici, Jira, un logiciel de gestion des tâches. Près de 50 Mo !

Expédient-ils tout le WASM compilé Electron ou quoi ?

Mais ce n’est pas la limite ! Slack ajoute 5 Mo de plus, jusqu’à 55 Mo :

Oui, c’est une discussion. Vous savez, liste d’utilisateurs, messages, réactions. Des choses que nous faisions sur du HTML brut, même avant l’invention de JS ?

C’est 55 Mo dans le monde d’aujourd’hui. C’est presque comme s’ils essayaient de voir combien de conneries supplémentaires ils peuvent mettre dans un navigateur avant qu’il ne casse.

Enfin, cela m’a soufflé l’esprit. D’une manière ou d’une autre, cela commence avec un modeste 2 Mo mais en faisant défiler de haut en bas, cela augmente indéfiniment. Juste pour le plaisir, je l’ai fait monter à 100 Mo (de JavaScript !), mais vous pouvez aller aussi loin que vous le souhaitez :

Qu’est-ce qui se passe là-bas ? Même s’il décharge et télécharge des parties de cet article de blog, comment cela peut-il augmenter si rapidement ? Le texte lui-même est probablement seulement de 50 Ko (0,05 Mo).

Mise à jour : On m’a fait remarquer que ce comportement n’est pas, en fait, représentatif de l’expérience utilisateur normale. Normalement, les éditeurs de code intégrés seront mis en cache après le premier chargement et les chargements ultérieurs seront servis à partir du cache disque. Donc, lorsque vous faites défiler, vous ne verrez aucun trafic réseau, mais ces 100 Mo de JS seront toujours analysés, évalués et initialisés encore et encore lorsque vous faites défiler.

À quelle vitesse déclinons-nous ?

Regardez comme c’est mignon ! En 2015, la taille moyenne d’une page web approchait la version shareware de Doom 1 (2,5 Mo) :

Eh bien, en 2024, Slack atteint 55 Mo, la taille du Quake 1 original avec toutes les ressources. Mais maintenant, c’est juste en JavaScript seul.

Pour une application de discussion !

À quel point 10 Mo sont-ils de toute façon ?

Pour être honnête, après avoir tapé tous ces chiffres, 10 Mo ne semblent même pas si gros ou spécial. Il semble que l’expédition de 10 Mo de code soit normale maintenant.

Si nous supposons que la ligne de code moyenne est d’environ 65 caractères, cela signifierait que nous expédions ~150 000 lignes de code. Avec chaque site web ! Parfois juste pour afficher du contenu statique !

Et ce code est déjà minifié. Donc c’est plus comme 300K+ LoC juste pour un site web.

Mais les sites web modernes sont-ils vraiment <em>si</em> complexes ? L’enfant chéri des SPAs, Google Maps, est assez modeste selon les normes modernes - c’est <em>toujours</em> juste 4,5 Mo :

Quelqu’un chez Google est sérieusement à la traîne. Écrit avec les technologies front-end modernes, il devrait faire au moins 20 Mo.

Et si vous, comme moi, pensiez que « Figma est une application front-end vraiment complexe, donc elle doit avoir une énorme taille de téléchargement JavaScript », eh bien, c’est correct, mais alors Gmail est à peu près aussi complexe que Figma, LinkedIn est 1,5× plus complexe et Slack est 2,5× plus ¯_(ツ)_/¯

Conclusion

Ce n’est pas seulement une question de tailles de téléchargement. J’accueille autant que le prochain la haute vitesse d’Internet. Mais le code - JavaScript - est quelque chose que votre navigateur doit analyser, garder en mémoire, exécuter. Ce n’est pas gratuit. Et ces gens parlent de performances et d’autonomie de la batterie…

Appelez-moi vieux jeu, mais je crois fermement que le contenu devrait l’emporter sur la taille du code. Si vous écrivez un article de blog de 10 000 caractères, vous n’avez pas besoin de 1000× plus de JavaScript pour le rendre.

Ce site le fait bien :

C’est 0,1 Mo. Et c’est suffisant !

Et pourtant, sur le même Internet, dans la même chronologie, Gitlab a besoin de 13 Mo de code, 500K+ LoC de JS, juste pour afficher une page d’atterrissage statique.

Baise-moi.

22 février 2024

Source de l’article