Solución:
Hay algunas cosas que se pueden hacer para reducir el tiempo de compilación.
Aumentar el límite de memoria del proceso de compilación.
El comando de compilación se ejecuta por nodo donde un solo proceso tiene un límite de memoria máximo de 1,76 GB en máquinas de 64 bits. Se puede aumentar agregando el --max-old-space-size argumento para el comando de construcción
Dado que este argumento debe pasarse al proceso del nodo en sí, el comando debe ejecutarse directamente con node. Un ejemplo de asignación de 4096 MB (4 GB) de RAM al proceso sería:
node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng build
El aumento del límite de memoria también evitará el error de “pila sin memoria”.
Parece haber un límite en la cantidad de memoria que usa el proceso. En un proyecto mío, el tiempo de construcción se redujo significativamente mediante un aumento de memoria a 12 GB, pero aumentarlo a 32 GB no dio más mejoras.
Corregir referencias a node_modules en archivos .scss
Hacer referencia a hojas de estilo externas de node_modules utilizando rutas relativas tiene un impacto negativo en el rendimiento del proceso de compilación y debe evitarse.
El proceso de construcción utiliza Webpack sass-loader, que admite una sintaxis en la que se hace referencia a la ubicación de node_modules con la tilde ~.
Usar la tilde en lugar de la ruta relativa reduce en gran medida el tiempo de construcción. Entonces, en lugar de importar hojas de estilo CSS externas con
import "../../../../../node_modules/x/whatever.css"
usar
import "~node_modules/x/whatever.css"
Optimizaciones de producción
De forma predeterminada, la compilación de producción utiliza la configuración de su angular.json expediente. Los valores predeterminados son
"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
}
No se desvíe de los valores predeterminados de la construcción de producción a menos que tenga una muy buena razón.
Estos son una gran parte de mantener bajo el tiempo de compilación (especialmente deshabilitar sourceMap y habilitar buildOptimizer).
Actualice su versión de CLI angular
El equipo de Angular CLI mejora continuamente la velocidad del proceso de construcción.
Es notorio que la mejora en el rendimiento de la compilación de la versión 6 a la 7 es sustancial, por lo que mantener el @angular/cli tener una biblioteca actualizada siempre es una buena idea.
Bibliotecas externas
Para tener una aplicación de creación rápida, debe tener mucho cuidado con las bibliotecas que importa.
Muchas bibliotecas populares como jQuery, lodash y moment son de tamaño muy grande y no están optimizadas adecuadamente para el proceso de construcción de Webpack.
Busque bibliotecas que admitan Tree-Shaking de Webpack para permitir que el proceso de compilación solo agrupe las partes de la biblioteca que realmente se utilizan en su aplicación.
Además, no caiga en la trampa de agregar una biblioteca de utilidades completa (como lodash) si solo necesita usar una única función de ella (como _get()).
Comprimir activos
La compresión de activos (a menudo imágenes) es en gran medida una tarea trivial (solo Google “comprime imágenes en línea”) y puede aumentar el rendimiento del proceso de compilación y la aplicación en sí.
Optimizaciones de hardware
Dado que Javascript es de un solo subproceso, los beneficios de tener varios núcleos de CPU no acelerarán el proceso de compilación.
De hecho, si monitorea su CPU durante la compilación, verá que un solo núcleo está por debajo del 100% de carga casi durante todo el proceso.
Si regularmente está construyendo su aplicación con la marca de producción como parte de su configuración de integración continua, puede considerar usar una máquina equipada con un alto rendimiento de un solo subproceso (para ver los puntos de referencia, consulte cpubenchmark.net)