Hacer cumplir los presupuestos de rendimiento con webpack

Como probablemente sepa, un único paquete monolítico de JavaScript (que alguna vez fue una práctica recomendada) ya no es el camino a seguir para las aplicaciones web modernas. Las investigaciones han demostrado que los paquetes más grandes aumentan el uso de memoria y los costos de CPU, especialmente en dispositivos móviles de gama media y baja.

webpack tiene muchas funciones para ayudarlo a lograr paquetes más pequeños y controlar la prioridad de carga de los recursos. El más atractivo de ellos es la división de código, que proporciona una forma de dividir el código en varios paquetes que luego se pueden cargar bajo demanda o en paralelo. Otro son los consejos de rendimiento que indican cuándo los tamaños de paquetes emitidos cruzan un umbral específico en el momento de la compilación para que pueda realizar optimizaciones o eliminar código innecesario.

El comportamiento predeterminado para las compilaciones de producción en el paquete web es mostrar una advertencia cuando el tamaño de un recurso o punto de entrada supera los 250 KB (244 KB), pero puede configurar cómo se muestran las sugerencias de rendimiento y los umbrales de tamaño a través del performanceobjeto en su webpack.config.jsarchivo.

Analizaremos esta característica y cómo aprovecharla como primera línea de defensa contra las regresiones de rendimiento.

Primero, necesitamos establecer un presupuesto personalizado.

Es posible que el umbral de tamaño predeterminado para activos y puntos de entrada (donde webpack busca comenzar a construir el paquete) no siempre se ajuste a sus requisitos, pero se puede configurar para que así sea.

Por ejemplo, mi blog es bastante mínimo y mi presupuesto es de unos modestos 50 KB (48,8 KB) tanto para activos como para puntos de entrada. Aquí está la configuración relevante en mi webpack.config.js:

module.exports = {  performance: {    maxAssetSize: 50000,    maxEntrypointSize: 50000,  }};

Las propiedades maxAssetSizey maxEntrypointSizecontrolan los tamaños de umbral para activos y puntos de entrada, respectivamente, y ambos se establecen en bytes. Este último garantiza que los paquetes creados a partir de los archivos enumerados en el entryobjeto (normalmente archivos JavaScript o Sass) no superen el umbral especificado, mientras que el primero impone las mismas restricciones a otros activos emitidos por el paquete web (por ejemplo, imágenes, fuentes, etc.).

Mostremos un error si se exceden los umbrales.

La advertencia predeterminada del paquete web se emite cuando se exceden los umbrales de presupuesto. Es lo suficientemente bueno para entornos de desarrollo pero insuficiente cuando se construye para producción. En su lugar, podemos desencadenar un error agregando la hintspropiedad al performanceobjeto y configurándola en 'error':

module.exports = {  performance: {    maxAssetSize: 50000,    maxEntrypointSize: 50000,    hints: 'error',  }}; 

Hay otros valores válidos para la hintspropiedad, incluidos 'warning'y false, donde falsedeshabilita completamente las advertencias, incluso cuando se infringen los límites especificados. No recomendaría usarlo falseen modo de producción.

Podemos excluir ciertos activos del presupuesto.

webpack impone umbrales de tamaño para cada tipo de activo que emite. Esto no siempre es bueno porque se generará un error si alguno de los activos emitidos supera el límite especificado. Por ejemplo, si configuramos el paquete web para procesar imágenes, obtendremos un error si solo una de ellas cruza el umbral.

La assetFilterpropiedad se puede utilizar para controlar los archivos utilizados para calcular sugerencias de rendimiento:

module.exports = {  performance: {    maxAssetSize: 50000,    maxEntrypointSize: 50000,    hints: 'error',    assetFilter: function(assetFilename) {      return !assetFilename.endsWith('.jpg');    },  }};   

Esto le indica a webpack que excluya cualquier archivo que termine con una .jpgextensión cuando ejecute los cálculos para obtener sugerencias de rendimiento. Es capaz de utilizar una lógica más compleja para cumplir con todo tipo de condiciones para entornos, tipos de archivos y otros recursos.

Limitaciones

Si bien esta ha sido una buena solución para mí, una limitación con la que me he encontrado es que se aplican los mismos umbrales de presupuesto a todos los activos y puntos de entrada. En otras palabras, todavía no es posible establecer varios presupuestos según sea necesario, como límites diferentes para JavaScript, CSS y archivos de imagen.

Dicho esto, hay una solicitud de extracción abierta que debería eliminar esta limitación, pero aún no está fusionada. Definitivamente algo a tener en cuenta.

Conclusión

Es muy útil establecer un presupuesto de rendimiento y aplicarlo con webpack es algo que vale la pena considerar al inicio de cualquier proyecto. Llamará la atención sobre el tamaño de tus dependencias y te animará a buscar alternativas más ligeras siempre que sea posible para evitar excederte en el presupuesto.

Dicho esto, ¡el presupuesto por resultados no termina aquí! El tamaño de los activos es solo uno de los muchos factores que afectan el rendimiento, por lo que aún queda trabajo por hacer para garantizar que se ofrece una experiencia óptima. Realizar una prueba de Lighthouse es un excelente primer paso para conocer otras métricas que puede utilizar, así como sugerencias para mejorar.

¡Gracias por leer y feliz codificación!