Réduisez votre JavaScript : maîtriser les optimisations du bundler

Introduction

Au cours des 15 dernières années, l'écosystème JavaScript s'est développé rapidement, introduisant d'innombrables outils pour faciliter le développement. Mais ces outils ont un coût : des tailles de bundles croissantes. En fait, les données de HTTP Archive montrent que la quantité moyenne de JavaScript transférée par page est passée de 90 Ko en 2010 à 650 Ko en 2024 (source).

Malgré une adoption croissante et des progrès en matière de compression, cette tendance ne montre aucun signe de ralentissement. Alors que nous continuons à ajouter des fonctionnalités, le défi demeure : Comment pouvons-nous expédier moins de JavaScript ?

Curieusement, les solutions sont à la fois faciles et difficiles. La partie la plus facile réside dans les ajustements au niveau du projet qui peuvent générer des gains rapides. Le plus difficile est d'avoir un impact durable, ce qui nécessite un changement à l'échelle de la communauté pour améliorer les bundles, les bibliothèques et les outils.

Cet article se concentre sur les améliorations concrètes pour vos projets, couvrant :

• Bundlers : optimisation des outils de construction pour réduire la taille de sortie.
• Bibliothèques : Choisir et utiliser judicieusement les dépendances externes.
• Votre projet : Étapes pratiques pour réduire vos paquets.

Les prochains articles porteront sur les améliorations que nous pouvons apporter à l’ensemble de l’écosystème, mais pour l’instant, voyons comment ces facteurs contribuent aux paquets gonflés – et comment les gérer.

Pourquoi l'optimisation de JavaScript est importante

JavaScript est le moteur de l’interactivité Web moderne, mais il n’est pas gratuit. JavaScript est la ressource la plus coûteuse en calcul que votre navigateur doit gérer. C'est souvent le goulot d'étranglement qui détermine si une page semble rapide ou lente, car un ensemble volumineux peut bloquer le rendu et dégrader les performances globales.

Plus le package JavaScript est volumineux, plus il faut de temps pour charger, analyser, compiler et exécuter. Cela retarde tout le reste, comme l'affichage du contenu ou la possibilité pour les utilisateurs d'interagir avec la page. Pour quelqu’un qui utilise un ordinateur portable haut de gamme doté d’une connexion fibre optique, cela peut être un désagrément mineur. Mais pour quelqu'un qui utilise un téléphone à faible consommation ou un réseau irrégulier, cela peut faire la différence entre rester ou quitter complètement votre site.

La première étape pour réduire la taille du bundle JavaScript consiste à secouer l'arbre (ou « élimination du code mort »), ce que la plupart des bundles font immédiatement. Mais tous les bundlers sont-ils égaux ?

Regroupeurs

Le regroupement en JavaScript a parcouru un long chemin : de la concaténation manuelle et des exécuteurs de tâches aux regroupeurs sophistiqués. Aujourd’hui, les performances du bundler sont une priorité, les développeurs donnant la priorité à des builds plus rapides. Cependant, la vitesse de construction n’est pas tout. La taille des bundles qu'ils produisent est tout aussi importante, car des bundles plus petits se traduisent par des temps de chargement plus rapides pour les utilisateurs.

À la recherche de meilleures performances, nous sommes passés de l'écriture de bundlers en JavaScript à des langages comme Rust et Go. Ce changement nécessitait de les écrire à partir de zéro, de sorte que toutes les fonctionnalités et optimisations présentes dans les anciens bundles devaient être réimplémentées. À long terme, cela sera probablement payant. Cependant, à court terme, cela signifie qu'il leur manque certaines fonctionnalités que les bundlers JavaScript ont eu des années à développer, comme un bon secouement d'arbre. Et c'est précisément cette fonctionnalité qui peut nous aider à minimiser la taille du paquet.

Référence

Bien sûr, parler ne coûte pas cher, alors regardons les chiffres, d'accord ?

Comparons huit bibliothèques populaires et regroupons-les avec sept bundles populaires. Pour que les choses restent équitables, j'ai utilisé :

• Nœud 22.12.0
• Temps de construction autodéclarés
• Minutats de troisième exécution pour permettre aux caches de se réchauffer, en particulier pour des outils comme Parcel
• Configurations qui suppriment tous les commentaires, y compris les licences, puisque les bundlers les gèrent différemment

Vous pouvez consulter le référentiel de configuration de référence pour les configurations exactes.

Bundlers testés :

• esbuild (0.24.0)
• Colis (2.13.2)
• Déroulant (0.15.0-snapshot-993c4a1-20241205003858)
• Consolidation (4.28.0)
• Rspack (1.1.5)
• Vite (6.0.3)
• webpack (5.97.1)

Notez qu'au moment de la rédaction, Rolldown est toujours en version alpha, il est donc désavantagé et ses résultats s'amélioreront probablement avec le temps.

Bibliothèques testées :

• chart.js
• ckeditor5
• d3
• handsontable
• Luxon
• mobx
• tippy.js
• zod

Ces bibliothèques varient en taille et en fonctionnalités – certaines peuvent fonctionner presque comme des applications autonomes.

Vitesse de construction

Commençons par la vitesse de construction, car c'est quelque chose qui semble intéresser beaucoup les développeurs. En regroupant toutes ces bibliothèques, esbuild est le gagnant, avec un temps de construction de 192 ms. En le comparant au temps de construction le plus lent de 7,23 secondes, c'est plus de 37 fois plus rapide.

Sur la base de ces résultats, nous pouvons regrouper les bundlers en trois catégories :

1. Blazingly fast™ : esbuild, Parcel, Rolldown (<500 ms, avec esbuild sous 200 ms).
2. Plus rapide : Rspack (2,2 secondes).
3. Lent : Rollup, Vite, webpack (5 secondes chacun).

Les différences sont frappantes. Par exemple, Rolldown et Rspack sont respectivement 11,5 fois et 3,3 fois plus rapides que leurs anciens homologues, Rollup et webpack, tout en conservant une compatibilité ascendante théorique. Le passage à ces nouveaux bundles pourrait augmenter considérablement la productivité sur des projets plus importants.

Taille de sortie

En ce qui concerne la taille de sortie, les différences ne sont pas aussi drastiques que les temps de construction, mais elles comptent toujours.

Résultats agrégés

En regroupant les huit bibliothèques, Vite est le gagnant, avec une taille de sortie de 2 087 Ko. En le comparant à la plus grande taille de sortie de 2 576 Ko, cela représente une sortie plus petite de 23,5 %.

Une différence de 23,5 % dans la taille de sortie est substantielle : sur une connexion 3G lente, le téléchargement du plus petit paquet peut prendre environ 5,7 s, tandis que le plus grand se rapproche de 7 s. Les temps d'analyse et d'exécution évoluent également en fonction de la taille du bundle, de sorte que la différence dans le monde réel pourrait être encore plus perceptible.

Sur la base de ces résultats, nous pouvons à nouveau regrouper les sorties des bundlers en trois catégories :

1. Le plus petit : esbuild, Parcel, Rollup et Vite (~ 2 085 à 2 160 Ko).
2. D'accord : webpack (~2317 Ko).
3. Gros : Rolldown, Rspack (~2490–2580KiB).

Bibliothèques individuelles

Les résultats agrégés ne donnent pas une image globale car il est peu probable que vous utilisiez toutes les bibliothèques répertoriées ci-dessus dans votre projet. Ce qui est plus intéressant, c'est la façon dont ces bundlers gèrent les bibliothèques individuelles.

Pour les bibliothèques comme chart.js et mobx, le choix du bundler peut affecter considérablement la taille de sortie, avec des différences atteignant 70 %. Cela souligne l’importance de tester les bundles avec vos dépendances spécifiques. Dans la plupart des autres cas, la différence est beaucoup plus faible, de l'ordre de 20 à 30 %.

De plus, même si dans l'ensemble, le webpack s'est retrouvé au milieu, il a obtenu les meilleurs résultats dans 6 cas sur 8. Cependant, comme les résultats étaient bien pires lors du regroupement de handsontable et chart.js, cela s'est terminé là où il est arrivé. Cela signifie que, selon les bibliothèques que vous utilisez, webpack peut être un bon choix.

De l’autre côté du spectre, nous avons Rolldown. Il a obtenu les pires résultats dans 7 cas sur 8 (rappelez-vous qu'il est toujours en alpha).
Rspack est une histoire similaire. Bien qu'il ait mieux fonctionné que Rolldown, il a quand même produit un bundle beaucoup plus volumineux que les autres bundlers.

Si vous envisagez de migrer vers un bundler plus récent, testez-le avec les bibliothèques que vous utilisez pour voir si la vitesse de construction plus rapide ne se fait pas au détriment d'une taille de sortie accrue.

Taille du paquet par rapport à la vitesse de sortie

Comme indiqué, les bundles les plus récents sont beaucoup plus rapides mais peuvent produire des bundles plus gros. Lors de la migration à partir d'un ancien bundler, ne comparez pas seulement les temps de construction, mais comparez également les tailles de bundles résultantes. Vous pourriez vous retrouver à échanger des builds plus rapides contre des bundles plus volumineux.

Par exemple, après qu'Angular soit passé de webpack à esbuild, certains développeurs ont signalé que la taille d'une application Angular vide avait augmenté d'environ 20 Ko. Cela met parfaitement en évidence le compromis entre vitesse de construction et taille du bundle.

Cela ne veut pas dire que vous ne devriez pas prêter attention à la vitesse de construction, car elle est importante pour la productivité et le bonheur des développeurs. Il existe également une corrélation entre le temps de construction du CI et le temps nécessaire pour fusionner le code.

Lorsque vous choisissez un bundler, examinez d'abord les fonctionnalités qu'il offre. Visez ensuite un équilibre entre la vitesse de construction et la taille du bundle. Sélectionnez le bundler qui peut produire éventuellement le plus petit paquet dans le temps qui vous convient.
Testez quelques bibliothèques représentatives de votre projet. Si vos dépendances constituent la majeure partie de votre base de code, les différences que vous voyez dans ces benchmarks peuvent être un bon indicateur de votre situation.

Bibliothèques

Les bibliothèques externes suivent sur notre liste, qui constituent souvent la majeure partie de votre offre JavaScript. Dans de nombreuses applications, sinon la plupart, sur lesquelles j'ai travaillé, elles représentaient la majorité de la taille du bundle. C'est pourquoi il est si important de les choisir (et de les utiliser) judicieusement.

De l'or mais vieux

Beaucoup d'entre nous ont installé des bibliothèques comme lodash, axios ou moment simplement pour utiliser une seule fonction, ce qui conduit à des applications surchargées. Ces bibliothèques sont formidables et historiquement importantes, mais à mesure qu'elles sont devenues plus populaires, des alternatives plus légères ont été créées et certaines de leurs fonctionnalités ont été ajoutées au langage lui-même.

Nous pouvons en profiter. Je pourrais lister des API natives ou des alternatives plus récentes et plus petites pour ces bibliothèques, mais il existe déjà de nombreux articles qui traitent de cela. Et il existe tellement d'autres bibliothèques qu'il serait impossible de toutes les couvrir.

C'est pourquoi je ne vous donnerai qu'un conseil général pour jeter un œil aux bibliothèques que vous utilisez et voir si vous pouvez les supprimer ou les remplacer par des API natives ou des alternatives plus petites. Le site Web YOU MIGHT NOT NEED * est une excellente ressource pour commencer.

Chemins d'installation optimisés

La plupart des bibliothèques ne sont pas optimisées en termes de taille par défaut, mais certaines proposent des chemins d'installation spéciaux ou des versions partielles. Même parmi les bibliothèques de notre test, chart.js, handsontable et ckeditor5 offrent un moyen de réduire la taille de la bibliothèque en incluant uniquement les parties dont vous avez besoin. Regardons ckeditor5 comme exemple.

Le chemin d'installation par défaut donne une taille de bundle comprise entre 660 et 800 Ko. Cependant, si nous utilisons le chemin d'installation optimisé, la taille du bundle tombe à 603-653 KiB, seul le bundle produit par Rolldown étant d'environ 750 KiB. Il s'agit d'une réduction de taille de 7 % à 23 %, selon le bundler.

Dépendances dupliquées

Une autre chose à surveiller sont les dépendances en double. Il s'agit d'un problème étonnamment courant dans les applications JavaScript. Par exemple, le widget intégré Bluesky avait deux versions de la bibliothèque de validation zod. La suppression du doublon a réduit la taille du paquet d'environ 9 %.

Ce problème ne se produit généralement pas parce que vous avez extrait deux versions différentes de la même bibliothèque, mais parce que vous et l'une des bibliothèques externes dépendez de la même bibliothèque, mais dans des versions différentes. Cela peut souvent être résolu en mettant à jour les bibliothèques dont vous dépendez.

Votre projet

Avec tout cela à l’esprit, nous pouvons enfin passer à la dernière pièce du puzzle : votre projet. Voici ce que vous pouvez faire pour réduire vos offres groupées et améliorer les performances.

Inspectez vos forfaits

La première étape est la visibilité. Sans comprendre ce qu’il y a à l’intérieur de vos paquets, réduire leur taille devient un jeu de devinettes. Pour cela, vous pouvez utiliser un analyseur et un visualiseur de bundle que j'ai créé appelé Sonda. Il fonctionne avec la plupart des bundles mentionnés ci-dessus (sauf Parcel) et affiche avec précision la taille des fichiers individuels qui contribuent au bundle.

Vous pouvez commencer par l'installer dans votre projet et inspecter visuellement certaines parties de votre bundle.

Une fois que vous avez bien compris le contenu des bundles et que vous avez identifié les parties qui peuvent être optimisées, vous pouvez cliquer sur les vignettes graphiques pour voir :

• tailles de fichiers avant et après compression,
• liste des fichiers qui importent le fichier sélectionné,
• et même inspecter des parties du code source inclus dans le bundle.

Sonda vous avertit également des dépendances en double afin que vous puissiez rapidement identifier et résoudre la racine du problème.

Idéalement, vous ne devriez pas seulement effectuer une inspection ponctuelle, mais mettre en place une surveillance continue dans le cadre de votre pipeline CI. Le suivi des changements au fil du temps, en particulier dans les grands projets, peut vous aider à éviter que de petits changements ne se transforment en boule de neige et en une surcharge importante au fil du temps.

Supprimer ou optimiser les bibliothèques externes

Le code le plus rapide est celui que vous n'expédiez pas. Dans la mesure du possible :

• Supprimez les bibliothèques pouvant être remplacées par des API natives.
• Remplacez les bibliothèques lourdes par des alternatives plus petites.
• Utilisez des chemins d'installation optimisés si la bibliothèque le prend en charge.

Utiliser le fractionnement du code

Si vous ne parvenez pas à supprimer une partie de votre application, essayez le fractionnement du code. Le fractionnement du code vous permet de différer le chargement de certaines parties de votre application jusqu'à ce qu'elles soient nécessaires, améliorant ainsi les temps de chargement initiaux.

Utilisez Dynamic import() pour charger des modules à la demande. Par exemple, si une fonctionnalité particulière n'est pas nécessaire jusqu'à ce que l'utilisateur clique sur un bouton, différez son chargement jusqu'à ce moment.

Les frameworks frontend modernes prennent en charge le chargement paresseux, ce qui rend plus facile que jamais l'intégration du fractionnement de code dans votre flux de travail.

Suivez les bonnes pratiques

Il s'agit d'un conseil général, mais il vaut la peine d'être répété. Suivez les bonnes pratiques, comme :

• Utilisez la dernière cible que vous pouvez afin que le code ne soit pas inutilement transpilé ou polyrempli. Certains polyfills peuvent ajouter beaucoup de code qui n'est pas du tout nécessaire dans les navigateurs modernes, mais de nombreux environnements les ajoutent toujours par défaut. Vous pouvez également configurer un rappel pour mettre à jour l'objectif chaque année.
• Mettez régulièrement à jour les dépendances, car de temps en temps, les versions les plus récentes sont plus petites ou plus rapides. Cela peut également vous éviter d'avoir à gérer des failles de sécurité ou des dépendances en double.
• Évaluez chaque dépendance que vous possédez déjà ou envisagez d'ajouter. Si vous ne pouvez pas justifier la taille, ne l'ajoutez pas et ne cherchez pas une alternative plus petite.

Rejoignez la communauté Performance des écosystèmes (e18e)

Si vous souhaitez rendre le Web plus rapide ou simplement apprendre de nouvelles choses, vous devriez envisager de rejoindre la communauté Ecosystem Performance. Nous nous concentrons sur trois domaines principaux :

• Nettoyer – Améliorer les packages en supprimant les dépendances redondantes ou en les remplaçant par des alternatives modernes.
• Accélération – Amélioration des performances des packages largement utilisés.
• Niveau supérieur : créer des alternatives modernes aux packages obsolètes.

Conclusion

J'espère que cet article illustre que vous pouvez proposer les mêmes fonctionnalités avec moins de code. La taille des bundles peut devenir incontrôlable si elle n'est pas gérée, mais même de petits changements peuvent améliorer considérablement les performances.

Commencez dès aujourd'hui : analysez vos bundles, testez un nouvel outil ou remplacez une bibliothèque lourde. L'impact vous surprendra.

---

J'espère que vous avez apprécié cet article. Si vous avez des questions ou des commentaires, ou si vous souhaitez en savoir plus sur un sujet spécifique, n'hésitez pas à me le faire savoir dans les commentaires ci-dessous. Si vous souhaitez en savoir plus sur le thème des performances JavaScript, du regroupement et du tree-shaking, vous pouvez me suivre ici ou sur BlueSky et rejoindre la communauté e18e.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!