El performance de una aplicación Next.js no se reduce a Core Web Vitals. También importa el peso de tu bundle, es decir, cuánto código entregas al cliente, al servidor y al edge. Si trabajas con Next.js y quieres detectar dependencias pesadas antes de pasar a producción, Bundle Analyzer es la herramienta que necesitas para auditar tu proyecto y aplicar buenas prácticas de optimización.
¿Qué es Bundle Analyzer y para qué sirve en Next.js?
Bundle Analyzer es un plugin que se apoya en Webpack para mostrarte, de forma visual, qué módulos viajan a cada parte de tu aplicación. En Next.js esto cobra fuerza porque tu código se reparte en tres entornos distintos: cliente, servidor y edge.
¿Qué mide Bundle Analyzer? Mide el tamaño de tus dependencias y chunks divididos por entorno (cliente, servidor, edge), tanto en su tamaño original como en formato Gzip comprimido.
La instalación parte de un paquete npm y una pequeña configuración. La idea es envolver tu configuración existente con una función llamada withBundleAnalyzer, que se activa solo cuando una variable de entorno se lo indica [00:55].
¿Cómo configurar Bundle Analyzer paso a paso?
El flujo es directo y se resuelve con tres ajustes mínimos en tu proyecto:
- Instala la dependencia @next/bundle-analyzer desde la terminal.
- Envuelve tu configuración en next.config con la función withBundleAnalyzer, leyendo la variable de entorno ANALYZE [01:30].
- Crea un script en package.json llamado analyze que ejecute next build con ANALYZE=true [02:20].
Al correr npm run analyze, Next.js construye el proyecto y abre tres pantallas, una por cada entorno donde corre tu código.
¿Cómo interpretar el reporte de cliente, servidor y edge?
Cada pantalla representa un destino distinto del código. Saber leerlas te ayuda a tomar decisiones de arquitectura sin adivinar.
En la vista de cliente vas a ver dependencias como React DOM, el router de Next.js y todos tus chunks divididos por rutas. El chunking es la técnica detrás del code splitting, que parte el código en fragmentos para que el navegador los cargue progresivamente. En el ejemplo de la clase, el total ronda los 637 KB, y al pasarlo a Gzip baja a 199.71 KB, una cifra muy razonable para un sitio robusto [04:30].
La vista de edge muestra solo lo que se libera en edge computing. El chat construido en el proyecto vive ahí y pesa apenas 60.43 KB ya comprimido. La vista de servidor, con cerca de 367 KB, contiene rutas, endpoints y todo lo que ejecutan tus React Server Components [05:50].
¿Por qué Next.js separa el bundle en tres entornos? Porque cada uno tiene un runtime distinto: el cliente corre en el navegador, el servidor en Node y el edge en una red distribuida. Separar el código permite enviar solo lo necesario a cada destino.
¿Cómo detectar dependencias pesadas en tu proyecto?
La parte realmente útil del análisis está en identificar qué librerías inflan tu bundle. Para demostrarlo, en la clase se instala Moment, una librería de manejo de fechas conocida por su mal performance.
Con solo importar Moment y usar una línea como moment().format() dentro de un componente cliente como el shopping cart, el bundle del cliente sube unos 170 KB, y la versión Gzip crece alrededor de 20 KB adicionales [07:40]. Una sola dependencia mal elegida puede arruinar tu performance budget.
La solución es removerla con npm remove moment y volver a correr el análisis. Al hacerlo, Moment desaparece del reporte y el bundle vuelve a su tamaño original.
¿Qué es un performance budget y cómo aplicarlo?
El performance budget es el ejercicio de fijar límites claros para el peso y el rendimiento de tu aplicación. Combina dos frentes complementarios:
- Core Web Vitals: miden el comportamiento real de tu sitio en producción.
- Análisis de bundle: detecta cargas excesivas antes del despliegue.
- Automatización: integra estas mediciones en tu pipeline de continuous integration y continuous development.
En la clase el budget se hizo a ojo, pero existen herramientas que automatizan este ciclo dentro de tu pipeline para que cada pull request respete los límites de tamaño definidos por el equipo.
La idea es que el performance deje de ser una revisión manual y se convierta en un estándar del equipo. ¿Ya mediste el bundle de tu próximo deploy en Next.js? Cuéntame en los comentarios qué dependencia te sorprendió más al analizarla.
