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. El empaquetado es útil, pero a medida que tu app crezca, también lo harán tus paquetes. Debes supervisar los tamaños de los paquetes para asegurarte de que no crezcan demasiado y afecten el tiempo que tarda en cargarse tu aplicación. Webpack admite la configuración de presupuestos de rendimiento basados en el tamaño de los recursos y puede controlar los tamaños de los paquetes por ti.

Para verla en acción, aquí tienes una app que cuenta los días que faltan para Año Nuevo. Está compilado 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 agrupada con webpack.

1. Haz clic en Remix to Edit para que el proyecto se pueda editar.
2. Haz clic en Terminal (nota: Si no se muestra 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 es más grande que 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 recursos 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 no solo te advertirá, sino que también te dará una recomendación sobre cómo reducir el tamaño de tus paquetes. Puedes obtener más información sobre las técnicas recomendadas en Fundamentos de la Web.

Cómo establecer un presupuesto de rendimiento personalizado

Un presupuesto de rendimiento adecuado dependerá de la naturaleza de tu proyecto. Siempre es mejor hacer tu propia investigación. Una buena regla general es entregar menos de 170 KB de recursos comprimidos o minimizados de la ruta de acceso crítica.

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 lo siguiente:

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

El nuevo presupuesto de rendimiento se establece en bytes:

• 100,000 bytes para recursos 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 pistas son los siguientes:

1. warning (opción predeterminada): Muestra un mensaje de advertencia amarillo, pero la compilación se completa. Es mejor usarlo en entornos de desarrollo.
2. error: Muestra un mensaje de error rojo, pero la compilación sigue pasando. Se recomienda este parámetro de configuración para las compilaciones de producción.
3. false: No se muestran advertencias ni errores.

Optimizar

El objetivo de un presupuesto de rendimiento es advertirte sobre 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 tiempos de carga más rápidos. (Muchos de ellos se documentan aquí mismo en Optimización de tu código JavaScript). 🤓)

Los frameworks y las bibliotecas facilitan la vida de los desarrolladores, pero a los usuarios finales no les importa 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 frameworks grandes del cliente suelen ser difíciles de reemplazar, por lo que es importante usarlos con prudencia. Con un poco de investigación, a menudo puedes encontrar alternativas más pequeñas a las bibliotecas populares que funcionan igual de bien (date-fns es una buena alternativa para moment.js). A veces, tiene más sentido no usar ningún framework o biblioteca si tienen un impacto significativo en el rendimiento.

Quitar el código no utilizado es una buena forma de optimizar las apps que incluyen bibliotecas grandes de terceros. La guía para quitar código sin usar explica este proceso en detalle, y aquí tienes una forma rápida de volver a escribir 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');

Borra esta línea:

const moment = require('moment');

Se requiere un poco de matemática, 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.

¡Listo! Redujiste el tamaño en 223 KiB (230 KB) y la app está dentro del presupuesto.🎉

Supervisar

Configurar un presupuesto de rendimiento en webpack solo requiere un par de líneas de código, y te advertirá si alguna vez (accidentalmente) agregas una dependencia grande. El dicho dice "ojos que no ven, corazón que no siente", pero webpack puede asegurarse de que conozcas las implicaciones del rendimiento en todo momento.