Analizar el bundle: qué pesa de verdad

Tu build escupe una carpeta de chunks —index-9f3a.js, vendor-a1b2.js, chunk-x7k.js— y una cifra total que no explica nada: 480 KB. ¿De quién son esos bytes? ¿Qué librería mete medio megabyte que nadie recuerda haber instalado? El primer acto de toda optimización seria no es tocar código, sino levantar un mapa. Un treemap reparte cada byte del bundle entre los módulos que lo produjeron, dibujando rectángulos cuya área es proporcional a su peso. Con rollup-plugin-visualizer dejas de intuir y empiezas a medir: la optimización sin perfilado previo es superstición.

Del build opaco al treemap

El visualizer es un plugin que se engancha al final de la generación del bundle: cuando Rollup o Rolldown han producido los chunks, recorre el bundle en el hook generateBundle, mide cada módulo y emite un HTML interactivo. No cambia tu salida; solo la fotografía. Como conserva la compatibilidad con la API de plugins de Rollup, funciona igual bajo Vite 8 con Rolldown que bajo el Rollup clásico.

// vite.config.ts — el visualizer solo corre en el build, como ultimo plugin
import { defineConfig } from "vite";
import { visualizer } from "rollup-plugin-visualizer";

export default defineConfig({
  build: {
    rollupOptions: {
      plugins: [
        visualizer({
          filename: "stats/treemap.html",
          template: "treemap",
          gzipSize: true,
          brotliSize: true,
          sourcemap: true,
          open: true,
        }),
      ],
    },
  },
});

Colocarlo dentro de build.rollupOptions.plugins garantiza que no se active en el dev server, donde no hay bundle que medir. La opción template elige la representación —treemap para peso por área, sunburst para jerarquía radial, network para el grafo de importaciones—; el treemap es el mejor punto de partida porque el ojo compara áreas mejor que ángulos. Activar sourcemap: true es clave: sin él, el visualizer atribuye bytes al chunk final; con él, usa los source maps para remontar cada byte hasta el módulo fuente que lo generó, incluso a través de la minificación.

Las tres tallas de un módulo

El treemap muestra tres cifras por módulo, y confundirlas lleva a optimizar el número equivocado. No son lo mismo, y solo una llega al usuario.

La talla stat es la más grande y la más traicionera: una dependencia puede ocupar 300 KB de fuente y aportar 4 KB al bundle porque tu código solo usa una función y el tree-shaking tira el resto. Optimizar mirando stat te hace perseguir fantasmas. La talla parsed importa para el coste de CPU —parsear y compilar JavaScript no es gratis—, pero la que gobierna el tiempo de red, y por tanto el presupuesto que defenderás en la siguiente lección, es la comprimida: gzip o, mejor, brotli, que es lo que sirve cualquier CDN moderno.

Leer el mapa y cazar al culpable

Un treemap se lee como un mapa catastral: cada rectángulo grande es un módulo o paquete que ocupa terreno, y el anidamiento refleja la jerarquía de carpetas de node_modules. Buscas los bloques grandes que no esperabas, y casi siempre son el mismo puñado de sospechosos que se repite en cualquier producto.

El flujo de trabajo es un bucle cerrado, no un acto único. Construyes, lees el mapa, identificas el módulo dominante, actúas —lo sustituyes por una alternativa ligera, lo difieres a un import() dinámico, o consolidas su versión duplicada— y vuelves a construir para confirmar que el rectángulo encogió. Cada iteración recorta el bloque más gordo que quede, siguiendo la ley de que el 20% de los módulos suele explicar el 80% del peso.

flowchart LR
build[npm run build] --> stats[visualizer emite el treemap]
stats --> leer[Localizas el modulo dominante]
leer --> accion[Sustituyes difieres o deduplicas]
accion --> build
style stats fill:#89b4fa,color:#11111b
style accion fill:#a6e3a1,color:#11111b