Configura presupuestos de rendimiento con webpack

Milica Mihajlija

Webpack combina todos los archivos importados y los empaqueta en uno o más archivos de salida, conocidos como paquetes. La creación de paquetes es excelente, pero a medida que crezca tu app, los paquetes también crecerán. Debes supervisar los tamaños de los paquetes para asegurarte de que no sean demasiado grandes y afecten el tiempo que tarda tu aplicación en cargarse. Webpack admite establecer presupuestos de rendimiento en función del tamaño del recurso, y puede supervisar los tamaños de los paquetes por ti.

Para ver cómo funciona, aquí tienes una app que cuenta los días que faltan para Año Nuevo. Se compila con React y moment.js. (Al igual que las apps del mundo real que dependen cada vez más de frameworks y bibliotecas. 😉)

Medir

Este codelab ya contiene la app empaquetada con webpack.

1. Haz clic en Remix to Edit para que el proyecto sea editable.
2. Haz clic en Terminal. (Nota: Si no aparece el botón Terminal, es posible que debas usar la opción Pantalla completa).
3. Para obtener una lista codificada por colores de los recursos y sus tamaños, escribe webpack en la consola.

webpack

El paquete principal se destaca en amarillo porque supera los 244 KiB (250 KB).

Estas advertencias están habilitadas de forma predeterminada en el modo de producción y el umbral predeterminado es de 244 KiB sin comprimir, tanto para los elementos como para los puntos de entrada (la combinación de todos los recursos que se usan durante la carga inicial de una página).

Webpack te advertirá no solo, sino que también te brindará una recomendación sobre cómo reducir tus paquetes. Puedes obtener más información sobre las técnicas recomendadas en Fundamentos de la Web.

Establece un presupuesto de rendimiento personalizado

Un presupuesto de rendimiento adecuado dependerá de la naturaleza de tu proyecto. Siempre es mejor investigar por tu cuenta. Una buena regla general es entregar menos de 170 KB de recursos de rutas críticas comprimidos o reducidos.

Para esta demostración simple, intenta ser aún más conservador y establece el presupuesto en 100 KB (97.7 KiB). En webpack.config.js, agrega el siguiente código:

module.exports = {
  //...
  performance: {
    maxAssetSize: 100000,
    maxEntrypointSize: 100000,
    hints: "warning"
  }
};

El nuevo presupuesto de rendimiento se establece en bytes:

• 100,000 bytes para elementos individuales (maxAssetSize)
• 100,000 bytes para el punto de entrada (maxEntrypointSize)

En este caso, solo hay un paquete que también actúa como punto de entrada.

Los valores posibles para hints son los siguientes:

1. warning (predeterminado): Muestra un mensaje de advertencia amarillo, pero la compilación es correcta. Es mejor usarlo en entornos de desarrollo.
2. error: Muestra un mensaje de error rojo, pero la compilación aún pasa. Esta configuración se recomienda para las compilaciones de producción.
3. false: No se muestran advertencias ni errores.

Optimiza

El propósito de un presupuesto de rendimiento es advertirte sobre los problemas de rendimiento antes de que sean demasiado difíciles de solucionar. Siempre hay más de una forma de compilar una app, y algunas técnicas permiten que los tiempos de carga sean más rápidos. (muchas de ellas se documentan aquí mismo en la sección Cómo optimizar tu JavaScript. 🤓)

Los frameworks y las bibliotecas facilitan la vida de los desarrolladores, pero a los usuarios finales no les importa realmente cómo se compilan las apps, solo que sean funcionales y rápidas. Si superas el presupuesto de rendimiento, es hora de pensar en posibles optimizaciones.

En el mundo real, los grandes frameworks del cliente suelen ser difíciles de cambiar, por lo que es importante usarlos con cuidado. Con un poco de investigación, a menudo puedes encontrar alternativas más pequeñas a las bibliotecas populares que también hagan el trabajo (date-fns es una buena alternativa para moment.js). A veces, tiene más sentido no usar un framework o una biblioteca si tienen un impacto significativo en el rendimiento.

Quitar el código que no se usa es una buena forma de optimizar las apps que incluyen grandes bibliotecas de terceros. En la guía para quitar código sin usar, se explica en detalle este proceso y se incluye una forma rápida de reescribir el código de cuenta regresiva sin usar moment.js.

En app/components/Countdown.jsx quita lo siguiente:

const today = moment();
const yearEnd = moment().endOf('year');
const daysLeft = yearEnd.diff(today, 'days');

Y borra esta línea:

const moment = require('moment');

Se necesitan algunos cálculos matemáticos, pero puedes implementar la misma cuenta regresiva con JavaScript estándar:

const today = new Date();
const year = today.getFullYear();
const yearEnd = new Date(year,11,31); //months are zero indexed in JS
const timeDiff = Math.abs(yearEnd.getTime() - today.getTime());
const daysLeft = Math.ceil(timeDiff / (1000 * 3600 * 24));

Ahora, quita moment.js de package.json y vuelve a ejecutar webpack en la consola para compilar el paquete optimizado.

¡Charán! Recortaste 223 KiB (230 KB) y la app está por debajo del presupuesto.🎉

Supervisión

Para configurar un presupuesto de rendimiento en webpack, necesitas solo un par de líneas de código y recibirás una advertencia si alguna vez agregas una gran dependencia (por accidente). El dicho "fuera de la vista, se olvida", pero webpack puede garantizar que estés al tanto de las implicaciones de rendimiento en todo momento.