web-dev-qa-db-fra.com

Amélioration du temps de génération de la production pour l’application Angular 7

Le développement de mon application pour la production est très long avec ng build --prod

Parfois, il échoue même avec

ERREUR FATAL: Mark-compacts inefficace près de la limite de tas Échec d'allocation - La mémoire JavaScript est insuffisante

Est-ce que je peux faire quelque chose pour réduire le temps de construction?

angularangular-cliangular7ng-build
10
Daniel

Certaines choses peuvent être faites pour réduire le temps de construction.

Augmenter la limite de mémoire du processus de construction

La commande de construction est exécutée par noeud, un processus unique ayant une limite de mémoire maximale de 1,76 Go sur des ordinateurs 64 bits. Il peut être augmenté en ajoutant l’argument --max-old-space-size À la commande de construction.

Étant donné que cet argument doit être transmis au processus de noeud lui-même, la commande doit être exécutée directement avec noeud. Un exemple d'allocation de 4096 Mo (4 Go) de RAM au processus serait:

node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng build

L'augmentation de la limite de mémoire empêchera également l'erreur "mémoire insuffisante".

Il semble y avoir une limite à la quantité de mémoire utilisée par le processus. Un de mes projets a vu son temps de construction considérablement réduit par une augmentation de la mémoire à 12 Go - mais son augmentation à 32 Go n'apporte aucune amélioration supplémentaire.

Correction des références à node_modules dans les fichiers .scss

Référencer des feuilles de style externes à partir de node_modules en utilisant des chemins relatifs a un impact négatif sur les performances du processus de construction et doit être évité.

Le processus de construction utilise le sass-loader De Webpack, qui prend en charge une syntaxe dans laquelle l'emplacement de node_modules est référencé avec le tilde ~.

L'utilisation du tilde au lieu du chemin relatif réduit considérablement le temps de génération. Donc, au lieu d’importer des feuilles de style css externes avec

import "../../../../../node_modules/x/whatever.css"

utilisation

import "~node_modules/x/whatever.css"

Optimisations de production

Par défaut, la version de production utilise la configuration de votre fichier angular.json. Les valeurs par défaut sont

"production": {
  "fileReplacements": [
    {
      "replace": "src/environments/environment.ts",
      "with": "src/environments/environment.prod.ts"
    }
  ],
  "optimization": true,
  "outputHashing": "all",
  "sourceMap": false,
  "extractCss": true,
  "namedChunks": false,
  "aot": true,
  "extractLicenses": true,
  "vendorChunk": false,
  "buildOptimizer": true
}

Ne vous écartez pas des valeurs par défaut de la production, sauf si vous avez une très bonne raison.

Celles-ci contribuent grandement à maintenir le temps de construction au minimum (en désactivant particulièrement SourceMap et en activant buildOptimizer).

Mettez à jour votre Angular de la CLI

Le Angular CLI teamb améliore continuellement la vitesse du processus de construction.

Il est à noter que la mise à niveau des performances de construction de la version 6 à la version 7 est importante, il est donc toujours judicieux de maintenir la bibliothèque @angular/cli À jour.

Bibliothèques externes

Pour avoir une application de construction rapide, vous devez faire très attention aux bibliothèques que vous importez.

De nombreuses bibliothèques populaires telles que jQuery, lodash et moment sont de très grande taille et ne sont pas correctement optimisées pour le processus de construction de Webpack.

Recherchez les bibliothèques prenant en charge Tree-Shaking de Webpack pour permettre au processus de construction de regrouper uniquement les parties de la bibliothèque réellement utilisées dans votre application.

En outre, ne tombez pas dans le piège de l'ajout d'une bibliothèque d'utilitaires complète (telle que lodash) si vous n'avez besoin d'utiliser qu'une seule fonction de celle-ci (comme _get()).

Compression des actifs

La compression des ressources (souvent des images) est en grande partie une tâche triviale (il suffit de Google "compresser les images en ligne"), et cela peut augmenter les performances du processus de construction et de l'application elle-même.

Optimisations matérielles

Comme Javascript est un seul thread, les avantages d'avoir plusieurs cœurs de processeur n'accéléreront pas le processus de construction.

En fait, si vous surveillez votre CPU pendant la construction, vous verrez qu'un seul cœur est sous la charge de 100% presque tout au long du processus.

Si vous construisez régulièrement votre application avec l'indicateur de production dans le cadre de votre configuration d'intégration continue, vous pouvez envisager d'utiliser une machine dotée de performances élevées en un seul thread (pour les tests, reportez-vous à cpubenchmark.net ).

24
Daniel