Análisis y reducción de bundle size

Resumen

Este skill guía el proceso de analizar y reducir el tamaño de los bundles de una aplicación frontend. Cada kilobyte adicional en el bundle se traduce en mayor tiempo de descarga, más consumo de datos del usuario y mayor tiempo hasta la interactividad. En conexiones lentas o dispositivos modestos, un bundle sobredimensionado puede hacer que la aplicación sea inutilizable.

El proceso parte del análisis visual del bundle actual, identifica las causas del tamaño excesivo y propone soluciones concretas que se validan midiendo antes y después.

Proceso

1. Medir el tamaño actual del bundle. Antes de optimizar, registrar el estado de partida como baseline:

   • Tamaño total del bundle (sin comprimir y con gzip/brotli).
   • Tamaño de cada chunk o archivo generado por el bundler.
   • Tamaño del JavaScript, CSS e imágenes por separado.
   • Tiempo de carga en Lighthouse con throttling de red simulando 3G.

2. Generar el mapa visual del bundle. Usar la herramienta correspondiente al bundler del proyecto:

   • Webpack: webpack-bundle-analyzer genera un treemap interactivo del contenido del bundle.
   • Vite/Rollup: rollup-plugin-visualizer con formato treemap o sunburst.
   • Independiente del bundler: source-map-explorer analiza los source maps para mostrar qué ocupa espacio.

   Estas visualizaciones revelan de un vistazo qué dependencias y módulos dominan el tamaño.

3. Identificar los problemas habituales. Buscar estos patrones en el mapa visual:

   • Dependencias duplicadas: la misma librería aparece varias veces con versiones diferentes (por ejemplo, dos versiones de lodash por subdependencias incompatibles).
   • Imports completos de librerías grandes: se importa toda la librería cuando solo se usa una función (import _ from 'lodash' en lugar de import groupBy from 'lodash/groupBy').
   • Código muerto: módulos importados pero nunca referenciados en la ejecución real.
   • Polyfills innecesarios: polyfills para navegadores que ya no se soportan.
   • Assets no optimizados: imágenes o fuentes incluidas en el bundle en lugar de cargarse como recursos estáticos.
   • Librerías pesadas con alternativas ligeras: moment.js (300KB+) cuando date-fns o dayjs cubren el mismo caso de uso.

4. Aplicar las soluciones. Para cada problema identificado, actuar con la técnica adecuada:

   • Tree-shaking: asegurar que las dependencias usan módulos ES (ESM). Verificar que el bundler no desactiva tree-shaking por configuración incorrecta de sideEffects en package.json.

   • Code splitting: dividir el bundle en chunks que se cargan bajo demanda. Rutas diferentes = chunks diferentes. Componentes pesados que no son visibles inicialmente = lazy loading con React.lazy(), defineAsyncComponent() o import() dinámico.

   • Lazy loading: cargar componentes, rutas y módulos solo cuando el usuario los necesita. Implementar Suspense o equivalente para gestionar el estado de carga.

   • Alternativas ligeras: sustituir dependencias pesadas por alternativas que cubran el caso de uso real:

     Librería pesada	Alternativa ligera	Reducción aproximada
     moment.js	dayjs, date-fns	~95%
     lodash (completo)	lodash-es (cherry-pick)	~80%
     axios	fetch nativo + wrapper	~100% (elimina dep)
     numeral.js	Intl.NumberFormat	~100% (nativo)

   • Externalizar dependencias grandes: si una librería se usa en todas las páginas (React, Vue), servirla desde CDN o como chunk separado con caché larga.

   • Comprimir assets: configurar gzip o brotli en el servidor. Brotli ofrece entre un 15-25% mejor ratio que gzip.

5. Medir el resultado y comparar. Repetir las mediciones del paso 1 tras aplicar los cambios:

   • Comparar tamaño total, tamaño por chunk y tiempo de carga.
   • Verificar que la funcionalidad no se ha visto afectada.
   • Generar nuevo mapa visual para confirmar que los problemas se han resuelto.
   • Documentar los cambios realizados y la reducción conseguida.

6. Establecer presupuesto de bundle. Para evitar que el tamaño vuelva a crecer sin control:

   • Definir un límite máximo para el bundle principal (por ejemplo, 200KB gzip).
   • Configurar alertas en CI con bundlesize, size-limit o la funcionalidad de presupuesto del bundler.
   • Revisar el impacto en tamaño antes de añadir nuevas dependencias.

Que NO hacer

• No optimizar sin medir primero. Una reducción de 2KB en un bundle de 3MB no merece esfuerzo; una de 200KB en un bundle de 400KB es transformadora.
• No sacrificar la experiencia de desarrollo por una optimización marginal. Si una dependencia mejora significativamente la productividad del equipo, su tamaño puede ser aceptable.
• No asumir que el tree-shaking funciona sin verificarlo. Librerías que usan CommonJS, asignaciones a module.exports dinámicas o efectos secundarios en la raíz del módulo pueden anular el tree-shaking.
• No cargar todo de forma lazy. El chunk inicial debe contener lo necesario para el primer renderizado; el lazy loading excesivo genera cascadas de peticiones que empeoran la experiencia.