El treemap: de dónde sale cada kilobyte de tu paquete

Saber que tu paquete pesa ochocientos kilobytes no sirve de nada; saber que trescientos de esos kilobytes son una librería de fechas con todos sus idiomas incluidos sí. El mapa de árbol del informe de auditoría hace exactamente esa descomposición: dibuja cada fichero como un rectángulo proporcional a su tamaño y, si hay mapas de origen, lo subdivide en los módulos que lo componen. Es la vista que convierte una discusión sobre el peso en una lista de decisiones concretas.

Qué dibuja

Cada rectángulo es un fichero de JavaScript, con área proporcional a su tamaño. Al pulsar sobre uno, se subdivide en los módulos que lo componen, también proporcionalmente, y esos módulos se agrupan por su ruta de origen: las dependencias de terceros por un lado, tu código por otro, con su estructura de carpetas.

Esa jerarquía es lo que permite responder la pregunta útil, que no es cuánto pesa el paquete sino qué proporción de él es cada cosa. Un vistazo basta para ver si tu código es el diez o el ochenta por ciento del total, y qué dependencia domina.

El desglose por módulo requiere mapas de origen. Sin ellos, el mapa muestra los ficheros y nada más, lo que es mucho menos útil. Publicar mapas de origen en producción es una decisión con implicaciones —expone la estructura de tu código— y hay una alternativa que resuelve casi todo: generarlos y no publicarlos, sino subirlos a tu sistema de monitorización de errores, y ejecutar la auditoría con desglose en un entorno de preproducción donde sí estén disponibles.

La vista de bytes no usados

El mapa puede colorear cada región según qué proporción de su código se ejecutó durante la carga auditada. Esa información viene del mismo mecanismo de cobertura que se trata en el nivel siguiente, y tiene sus mismas limitaciones, que hay que tener presentes para no tomar decisiones equivocadas.

Mide una sola sesión. El código de una funcionalidad que el usuario no usó durante la auditoría aparece como no usado, y no lo es: simplemente no hizo falta todavía.

Un porcentaje alto de no usado no significa código muerto. Significa código que no era necesario en ese momento, que es una afirmación distinta y que apunta a una solución distinta: no borrarlo, sino cargarlo más tarde.

Con esas dos salvedades, la vista es extraordinariamente útil para una pregunta concreta: ¿qué está en el paquete de arranque y no debería estar? Un módulo grande con el noventa y cinco por ciento sin ejecutar durante una carga normal es un candidato claro a carga bajo demanda.

Los cuatro hallazgos típicos

La dependencia desproporcionada. Una librería que ocupa una fracción enorme del paquete para hacer algo pequeño. Los casos habituales son manipulación de fechas, utilidades genéricas de las que se usan tres funciones, y librerías de componentes importadas enteras. Las salidas son sustituir por una alternativa más ligera, usar la capacidad nativa equivalente si existe, o importar solo lo que se usa si la librería lo permite.

El módulo duplicado. La misma librería aparece dos o tres veces, en versiones distintas, porque dos dependencias tuyas la requieren con rangos incompatibles. Se ve inmediatamente en el mapa como rectángulos con el mismo nombre en sitios distintos. Es peso puro y a veces también bugs, cuando dos partes del sistema usan instancias distintas de algo que debería ser único.

El fragmento cargado siempre y usado casi nunca. Un módulo grande que forma parte del paquete inicial y que solo hace falta en una pantalla concreta. La solución es la importación dinámica en el punto donde se necesita.

El poli-relleno innecesario. Código de compatibilidad para navegadores que ya no están en tu público objetivo, y transformaciones de sintaxis que ya no hacen falta. Suele salir de una configuración de compilación que nadie ha revisado en años, y su corrección es cambiar una línea en la lista de navegadores soportados.

Medir sin la herramienta

Para una comprobación rápida, o para vigilar el peso sin ejecutar la auditoría entera:

// Inventario del JavaScript cargado, con transferido y descomprimido
(() => {
  const scripts = performance.getEntriesByType('resource')
    .filter(e => e.initiatorType === 'script' || /\.m?js(\?|$)/.test(e.name));

  const filas = scripts.map(e => {
    let origen; try { origen = new URL(e.name).origin; } catch { origen = '-'; }
    return {
      fichero: e.name.split('/').pop().split('?')[0].slice(0, 42),
      origen: origen === location.origin ? '(propio)' : origen.replace(/^https?:\/\//, ''),
      transferidoKB: Math.round((e.transferSize || 0) / 1024),
      descomprimidoKB: Math.round((e.decodedBodySize || 0) / 1024),
      ratio: e.decodedBodySize
        ? +(e.decodedBodySize / Math.max(1, e.transferSize)).toFixed(1)
        : null,
      msDescarga: Math.round(e.duration)
    };
  }).sort((a, b) => b.descomprimidoKB - a.descomprimidoKB);

  console.table(filas);

  const suma = (c) => filas.reduce((s, f) => s + (f[c] || 0), 0);
  const propios = filas.filter(f => f.origen === '(propio)');
  const terceros = filas.filter(f => f.origen !== '(propio)');
  console.table([{
    ficheros: filas.length,
    transferidoTotalKB: suma('transferidoKB'),
    descomprimidoTotalKB: suma('descomprimidoKB'),
    propiosKB: propios.reduce((s, f) => s + f.descomprimidoKB, 0),
    tercerosKB: terceros.reduce((s, f) => s + f.descomprimidoKB, 0)
  }]);

  const sinComprimir = filas.filter(f => f.ratio !== null && f.ratio < 1.5 && f.descomprimidoKB > 20);
  if (sinComprimir.length) {
    console.warn('Ficheros grandes que parecen no estar comprimidos:');
    console.table(sinComprimir);
  }
})();

La comprobación final es la que más veces encuentra algo inesperado: un fichero grande cuya proporción entre descomprimido y transferido está cerca de uno no se está sirviendo comprimido, y activar la compresión en el servidor es una mejora de varios cientos de kilobytes por una línea de configuración.

De los hallazgos a un presupuesto

El mapa da una foto; lo que evita que el problema vuelva es un límite. La forma más simple y más eficaz es un presupuesto de tamaño comprobado en cada cambio, con dos propiedades que lo hacen funcionar en la práctica.

Que falle el proceso, no que avise. Un aviso se ignora en la tercera semana.

Que el límite sea por punto de entrada y no global. Un total agregado permite que una pantalla engorde mientras otra adelgaza, y esconde precisamente el problema.

Y una comprobación adicional que evita la discusión más común: mostrar la diferencia respecto a la rama principal en cada propuesta de cambio. Ver “este cambio añade cuarenta kilobytes” en el momento de revisar es infinitamente más eficaz que descubrirlo seis meses después en un mapa de árbol.