Proyecto de optimización del tiempo de construcción

Donde trabajo (en la startup Spot.IM , cuyo tamaño es entre pequeño y mediano), Webpack se usa para construir varios proyectos. Después de 4 años de trabajar en nuestro producto principal, cuando tantas personas han contribuido a su código que no se puede contar, el tiempo de su ensamblaje inicial alcanzó 90 segundos exorbitantes y el tiempo de reensamblaje: 14

Esto es aproximadamente 14 segundos para esperar después de cada clic en el botón "Guardar".

Habiendo recurrido a algunas optimizaciones simples, como cualquiera puede aplicar en su proyecto, pudimos reducir las cifras anteriores a 20 segundos para el ensamblaje y 1 segundo para reconstruir el proyecto.



En este artículo quiero hablar sobre algunos cambios simples, haciendo que el proyecto pueda mejorar significativamente su tiempo de montaje. Tenga en cuenta que si usa CreateReactApp (o algún otro generador de aplicaciones de moda), entonces este artículo puede no ser especialmente útil para usted. Pero si no usa algo así, entonces lo que estamos hablando aquí puede ser muy útil para usted.

Medir el tiempo necesario para construir un proyecto

Antes de realizar cualquier tipo de optimización, configuremos una medición de indicadores mediante la cual podamos juzgar los resultados del trabajo. Para hacer esto, use el paquete 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) 

Ponemos el archivo de configuración de Webpack en el contenedor SMP (iniciando el mecanismo para tomar medidas de rendimiento utilizando la variable de entorno), y luego pasamos el objeto de configuración de Webpack. Después de eso, tenemos a nuestra disposición un informe de aspecto agradable que nos permite saber cuánto tiempo se dedica a cada gestor de arranque durante el ensamblaje. Usando SMP, obtenemos el doble de beneficios. En primer lugar, después de hacer una cierta mejora, podemos descubrir de inmediato cómo afectó el tiempo de construcción del proyecto. En segundo lugar, tenemos inmediatamente a nuestra disposición un informe completo sobre cuánto tiempo lleva cada gestor de arranque (o, más precisamente, la "cadena del gestor de arranque").


Informe generado con speed-measure-webpack-plugin

Mejora del tiempo de construcción inicial de un proyecto

Después de comenzar a usar SMP, teníamos información sobre cómo cambia el tiempo de compilación del proyecto al realizar mejoras en el proceso de compilación. Lo primero que comenzamos a optimizar fue el tiempo de compilación inicial (es decir, el tiempo que tardó Webpack en compilar el paquete después de que se inicializó). Para acelerar el proceso de compilación inicial, decidimos usar el cache-loader arranque del cache-loader .

Cache-loader es un cargador que almacena en caché y guarda en el disco (o base de datos) los resultados del trabajo de los cargadores que lo siguen. Esto significa que la próxima vez que inicie Webpack, puede ver una mejora significativa en la velocidad de compilación, o al menos puede esperarlo.

Aquí hay un ejemplo:

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

Agregar cache-loader antes de css-loader (para CSS) y antes de babel-loader (para JS) nos permitió eliminar aproximadamente 75 segundos del tiempo dedicado a la construcción inicial del proyecto.

Ahora trabajemos en el tiempo de reensamblaje. Intentaremos mejorar este tiempo cambiando la propiedad devtool .

Tarjetas de código de paquete web

En la configuración de Webpack puede encontrar la propiedad devtool , que, de acuerdo con la documentación, "le permite elegir el estilo de creación de tarjetas de código utilizadas para mejorar las capacidades de depuración. Los puntos de ajuste pueden afectar en gran medida la velocidad de montaje y reensamblaje ".

En otras palabras, modificar la propiedad devtool afecta qué tarjeta de código estará disponible para el desarrollador después de construir el proyecto. Y esto, a su vez, depende de cuánto tiempo lleva crear una tarjeta de código de este tipo.

Los experimentos con esta propiedad son algo del campo que puede cambiar permanentemente la vida de un programador. Esto tiene un gran impacto en la velocidad de construcción del proyecto. Es decir, cambiamos el valor de devtool de source-map (probablemente este es el modo más lento) a eval-source-map y pudimos reducir el tiempo de reensamblado del proyecto de 14 a 3.5 segundos:

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

La propiedad devtool capaz de aceptar 12 variantes de valor. CreateReactApp, por ejemplo, utiliza cheap-module-source-map . Por lo tanto, si va a configurar esta propiedad, experimente y encuentre el valor que sea mejor para usted.

Cabe señalar que cuando se utilizan métodos rápidos para crear tarjetas de códigos, la calidad de las tarjetas resultantes se deteriora. Estos deterioros se pueden sentir al comenzar la depuración. Afortunadamente, los navegadores modernos siguen el ritmo del TC39. Como resultado (al menos durante el desarrollo) no hay una necesidad real de la transpilación de grandes cantidades de código. Si configura Babel para que esta herramienta transporte JavaScript a un nivel que la última versión del navegador entienda (como se hace en CRA ), entonces con la depuración de código todo debería estar bien, ya que los mapas de código no diferirán demasiado del código en sí.

Así es como debería verse babel.config.js si decide transponer el código a un estado que sea claro para las últimas versiones de varios navegadores:

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

Eso es todo Tres pasos simples, y el tiempo de construcción de nuestro proyecto se redujo considerablemente.

Me gustaría señalar que alguien que comienza a resolver un problema similar puede desear mirar primero la documentación de Webpack y leerla correctamente. Sin embargo, esta no es la única fuente de conocimiento.

Encontré otro enfoque para encontrar información valiosa sobre proyectos de construcción. Este enfoque ha demostrado su eficacia en la práctica. Consiste en analizar archivos webpack.config de proyectos de código abierto existentes. En particular, el archivo de proyecto CreateReactApp . Al leer detenidamente este archivo, puede descubrir muchas cosas útiles.

Resumen

Un lector atento podría notar que al principio se trataba de reducir el tiempo de reensamblaje a 1 segundo. Y el mejor valor de este indicador mencionado en el texto fue de 3,5 segundos. Obviamente, se omitió algo al describir el progreso de optimización del proceso de ensamblaje. Así es Fue posible mejorar el tiempo de reensamblado del proyecto a 1 segundo al ganar otros 2.5 segundos gracias a las optimizaciones sutiles, que dependen en gran medida de las características de un proyecto en particular, es decir, Spot.IM. Por lo tanto, no se proporciona una descripción de estas mejoras aquí.

Estimados lectores! ¿Optimizas el tiempo de construcción de tus proyectos?