Optimisation du temps de construction du projet

Là où je travaille (dans la startup Spot.IM , dont la taille se situe entre petite et moyenne), Webpack est utilisé pour construire différents projets. Après 4 ans de travail sur notre produit principal, alors que tant de personnes ont contribué à son code qu'il ne peut pas être compté, le temps de son montage initial a atteint 90 secondes exorbitantes, et le temps de remontage - 14.

Il faut environ 14 secondes pour attendre après chaque clic sur le bouton "Enregistrer".

Après avoir eu recours à quelques optimisations simples, telles que n'importe qui peut postuler dans leur projet, nous avons pu réduire les chiffres ci-dessus à 20 secondes pour l'assemblage et 1 seconde pour la reconstruction du projet.



Dans cet article, je veux parler de quelques changements simples, ce qui permet au projet d'améliorer considérablement son temps d'assemblage. Veuillez noter que si vous utilisez CreateReactApp (ou un autre générateur d'application à la mode), cet article peut ne pas vous être particulièrement utile. Mais si vous n'utilisez rien de tel, alors ce dont nous parlons ici peut vous être très utile.

Mesurer le temps de construction d'un projet

Avant de faire tout type d'optimisation, mettons en place une mesure d'indicateurs permettant de juger des résultats du travail. Pour ce faire, utilisez le package speed-measure-webpack-plugin (SMP):

const webpackConfig = require('./webpack.config') const SpeedMeasurePlugin = require('speed-measure-webpack-plugin') const smp = new SpeedMeasurePlugin({   disable: !process.env.MEASURE, }) module.exports = smp.wrap(webpackConfig) 

Nous plaçons le fichier de configuration Webpack dans l'encapsuleur SMP (en démarrant le mécanisme pour prendre des mesures de performances à l'aide de la variable d'environnement), puis nous transférons l'objet de configuration Webpack. Après cela, nous avons à notre disposition un rapport agréable qui nous permet de savoir combien de temps est consacré à chaque chargeur de démarrage pendant l'assemblage. En utilisant SMP, nous obtenons un double avantage. Premièrement, après avoir apporté une certaine amélioration, nous pouvons immédiatement découvrir comment cela a affecté le temps de construction du projet. Deuxièmement, nous avons immédiatement à notre disposition un rapport complet sur le temps que prend chaque bootloader (ou, plus précisément, la «chaîne de bootloader»).


Rapport généré avec le plug-in speed-measure-webpack

Amélioration du temps de construction initial d'un projet

Après avoir commencé à utiliser SMP, nous avions des informations sur la façon dont le temps de génération du projet change lors de l'amélioration du processus de génération. La première chose que nous avons commencé à optimiser était le temps de construction initial (c'est-à-dire le temps qu'il a fallu à Webpack pour construire le paquet après son initialisation). Pour accélérer le processus de construction initial, nous avons décidé d'utiliser le cache-loader démarrage du cache-loader .

Cache-loader est un chargeur qui met en cache et enregistre sur le disque (ou la base de données) les résultats du travail des chargeurs qui le suivent. Cela signifie que la prochaine fois que vous démarrez Webpack, vous pouvez constater une amélioration significative de la vitesse de construction, ou du moins vous pouvez l'espérer.

Voici un exemple:

 {  rules: [    {      test: /\.jsx?$/,      use: [        'cache-loader',        'babel-loader',      ],    },    {      test: /\.scss$/,      use: [        'style-loader',        'cache-loader',        'css-loader',        'postcss-loader',        'sass-loader',      ],    },  ] } 

L'ajout d'un cache-loader avant css-loader (pour CSS) et avant babel-loader (pour JS) nous a permis de supprimer environ 75 secondes du temps passé sur la construction initiale du projet.

Maintenant, travaillons sur le temps de remontage. Nous allons essayer d'améliorer ce temps en changeant la propriété devtool .

Cartes de code Webpack

Dans les paramètres du Webpack, vous pouvez trouver la propriété devtool qui, selon la documentation, «vous permet de choisir le style de création des cartes de code utilisées pour améliorer les capacités de débogage. Les points de consigne peuvent affecter considérablement la vitesse de montage et de remontage. "

En d'autres termes, la modification de la propriété devtool affecte la carte de code qui sera disponible pour le développeur après la construction du projet. Et cela, à son tour, dépend du temps qu'il faut pour créer une telle carte de code.

Les expériences avec cette propriété sont quelque chose de terrain qui peut changer de façon permanente la vie d'un programmeur. Cela a un impact énorme sur la vitesse de construction du projet. A savoir, nous avons changé la valeur devtool de source-map (probablement c'est le mode le plus lent) en eval-source-map et avons pu réduire le temps de réassemblage du projet de 14 à 3,5 secondes:

 {  devtool: process.env.NODE_ENV === 'development'    ? 'eval-source-map'    : 'source-map' } 

La propriété devtool capable d'accepter 12 variantes de valeur. CreateReactApp, par exemple, utilise une carte source de module bon marché . Par conséquent, si vous allez configurer cette propriété, testez et trouvez la valeur qui vous convient le mieux.

Il convient de noter que lors de l'utilisation de méthodes rapides de création de cartes de code, la qualité des cartes résultantes se détériore. Ces détériorations peuvent être ressenties en commençant le débogage. Heureusement, les navigateurs modernes suivent le TC39. En conséquence (au moins pendant le développement), il n'est pas vraiment nécessaire de transpiler de grandes quantités de code. Si vous configurez Babel pour que cet outil transporte JavaScript à un niveau que la dernière version du navigateur comprend (comme cela est fait dans CRA ), alors avec le débogage de code, tout devrait bien se passer, car les mappages de code ne différeront pas trop du code lui-même.

Voici à quoi devrait ressembler babel.config.js si vous décidez de transposer le code dans un état clair pour les dernières versions des différents navigateurs:

 module.exports = {  presets: [    [      '@babel/preset-env',      {        targets: [          'last 1 chrome version',          'last 1 safari version',          'last 1 firefox version',        ].join(', '),      },    ],  ],  // ... } 

C’est tout. Trois étapes simples et le temps de construction de notre projet a été considérablement réduit.

Je voudrais noter que quelqu'un qui commence à résoudre un problème similaire peut avoir envie de consulter d'abord la documentation Webpack et de la lire correctement. Cependant, ce n'est pas la seule source de connaissances.

J'ai trouvé une autre approche pour trouver des informations précieuses sur les projets de construction. Cette approche a fait ses preuves dans la pratique. Il consiste à analyser les fichiers webpack.config des projets open source existants. En particulier, le fichier de projet CreateReactApp . En lisant attentivement ce fichier, vous pouvez découvrir beaucoup de choses utiles.

Résumé

Un lecteur attentif a pu constater qu'au tout début il s'agissait de réduire le temps de remontage à 1 seconde. Et la meilleure valeur de cet indicateur mentionné dans le texte était de 3,5 secondes. De toute évidence, quelque chose a été omis lors de la description de la progression de l'optimisation du processus d'assemblage. Il en est ainsi. Il a été possible d'améliorer le temps de remontage du projet à 1 seconde en gagnant 2,5 secondes supplémentaires grâce à des optimisations subtiles, qui dépendent largement des caractéristiques spécifiques du projet, à savoir Spot.IM. Par conséquent, une description de ces améliorations n'est pas fournie ici.

Chers lecteurs! Optimisez-vous le temps de construction de vos projets?