bundle-size

---
name: bundle-size
description: "Analizar y reducir el tamaño de bundles frontend. Activar cuando el bundle sea grande, se quiera reducir tamaño, aplicar tree shaking, configurar lazy loading, usar webpack analyzer o analizar el peso de la aplicacion."
---

# 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.