Vite est-il vraiment plus rapide que Webpack ?

Nov 28 2022
Ce n'est pas si simple pour les grandes bases de code
Vite a fait du bruit dans la communauté frontend. Les téléchargements sur npm ont quadruplé au cours de la dernière année et il ne cesse de gagner en popularité.
https://npmtrends.com/vite

Vite a fait du bruit dans la communauté frontend. Les téléchargements sur npm ont quadruplé au cours de la dernière année et il ne cesse de gagner en popularité.

La première chose que vous lisez à propos de Vite sur leur site Web, c'est que leur signifie «rapide» en français. Vite promet une augmentation significative des performances, alors comment Vite y parvient-il ?

Webpack et d'autres bundlers traditionnels fonctionnent avec l'approche séculaire consistant à lire tout votre code source et à le compiler dans quelques fichiers JS.

Cela fait plusieurs années que la prise en charge d'ESM est devenue disponible dans tous les navigateurs grand public, Vite a donc adopté une approche différente. Il alimente votre code source tel quel dans votre navigateur et lui permet de gérer lui-même l'importation de modules. Cela accélère considérablement le processus de construction, car le regroupement n'est plus nécessaire pour le travail de développement.

Mais comme toujours, il y a un hic.

Les navigateurs mettent du temps à résoudre les modules natifs. L'ouverture d'un seul bundle est beaucoup plus rapide que l'ouverture de centaines de dépendances. Alors, à quel point les performances sont-elles vraiment différentes? J'ai réalisé des projets fictifs avec un nombre différent de fichiers pour illustrer la différence de performances.

Analyse comparative

J'ai créé un script qui génère automatiquement un projet prêt à construire avec Vite et Webpack, et crée également un nombre prédéfini de composants fictifs qui sont tous rendus sur une seule page. Vous pouvez trouver le lien GitHub ici .

Je démarre un projet généré automatiquement avec npm startet j'enregistre deux métriques :

  1. Temps de construction tel que rapporté par le bundler.
  2. Temps de chargement indiqué par les outils de développement de Chrome.
  3. Oui, ce graphique n'est pas logarithmique et il est difficile de voir la différence exacte entre les bundlers pour les projets de plus petite taille. C'est parce que vous ne sentirez pas non plus la différence lorsque vous les utiliserez dans le monde réel !

Il n'est pas surprenant que les navigateurs ne soient pas conçus pour récupérer efficacement des milliers de fichiers en quelques secondes. Parce que vous ne devriez pas vraiment avoir 5000 fichiers dans un seul bundle JS.

Le fractionnement de code à la rescousse !

En réalité, vous devez charger le code JS au fur et à mesure, quand vous en avez besoin. Votre morceau initial doit être aussi petit que possible. Cela se fait souvent via le routage, lorsqu'un routeur gère les modules chargés paresseusement lorsque vous naviguez vers une route qui en a besoin. En savoir plus dans les documents React .

Avec Vite et le fractionnement de code, votre navigateur ne récupèrera les fichiers JS que par petits lots, ce qui se traduira par de bien meilleures performances.

Mais Webpack n'est pas aussi loin derrière qu'on pourrait le penser. Disponible depuis la version 5.20, Webpack peut différer la compilation des modules importés dynamiquement. Avec experiments.lazyCompilationl'option de configuration, vos performances de construction peuvent également être considérablement améliorées grâce au fractionnement de code.

Faisons le benchmark alors !

Cette fois, j'utilise les mêmes projets générés automatiquement, mais ces centaines de composants sont maintenant chargés paresseusement, donc le morceau initial est essentiellement un projet presque vide.

Voici les résultats:

C'est la même image que nous avions avec 10 fichiers dans le projet. Il y a une différence de moins d'une seconde, mais Vite gagne ici. Ce qui ne devrait surprendre personne ! Lorsque vous chargez presque tout paresseusement, votre temps de construction initial sera aussi court que possible. Et si vous pouvez garder tous vos morceaux raisonnablement petits, Vite continuera à vous offrir les avantages des constructions rapides.

Conclusion

Si vous pouvez séparer le code de votre application et garder vos petits morceaux, Vite vous fera gagner une demi-seconde ici et là.

Mais Webpack n'est pas aussi en retard qu'on pourrait le penser, notamment à cause d'innovations telles que lazyCompilationet swc-loader. Si votre build Webpack prend plus de 30 secondes, vous voudrez peut-être d'abord essayer d'optimiser votre configuration avec ces nouvelles options.

Webpack est toujours une bonne option si vous souhaitez bénéficier d'un support plus large pour les cas d'utilisation obscurs, ou si votre bloc initial est énorme et que vous ne pouvez pas le diviser.

Vite est l'approche la plus moderne, avec une installation et une configuration beaucoup plus faciles, et d'excellentes performances dès le départ.

En fin de compte, c'est toujours à vous et à vos besoins !