Un byte de JavaScript frente a un byte de imagen

Casi todos los equipos que empiezan a preocuparse por el rendimiento atacan primero las imágenes, porque son lo más grande de la lista de recursos y porque optimizarlas no exige tocar la arquitectura. Es una elección racional y suele estar equivocada. Un kilobyte de JavaScript y un kilobyte de imagen se parecen en el informe de red y no se parecen en nada más: uno se descodifica fuera del hilo principal y desaparece del presupuesto, el otro se parsea, se compila, se ejecuta y deja residuo permanente. Esta lección pone los dos lado a lado con números.

El experimento

Dos recursos del mismo peso transferido, servidos a la misma página, medidos en el mismo dispositivo. Uno es una fotografía de 1600 por 900 en AVIF que pesa 300 KB. El otro es un módulo de JavaScript minificado y comprimido con Brotli que pesa 300 KB.

El dispositivo de referencia es un Android de gama media de los que se venden por debajo de 250 euros, que es aproximadamente lo que emula el estrangulamiento de CPU a 4x sobre un portátil de desarrollo. Las cifras que siguen son órdenes de magnitud reproducibles, no constantes universales: al final de la lección tienes el procedimiento para medir las tuyas, y medirlas es el punto, porque el número de tu equipo convence infinitamente más que el mío.

El desglose lado a lado

Las filas que importan son cuatro, y merecen desarrollarse una a una.

La relación de compresión. Una imagen en AVIF, WebP o JPEG ya está comprimida en su formato; la compresión HTTP encima no le hace nada, y por eso los servidores bien configurados ni siquiera lo intentan. Los 300 KB que viajan son los 300 KB que hay. El JavaScript, en cambio, es texto: Brotli le saca un factor de 3 a 4, así que esos mismos 300 KB en la red son más de un megabyte de texto que el motor tiene que leer carácter a carácter. Ya solo en volumen de trabajo, hay un factor de tres y medio antes de empezar.

El hilo donde ocurre. La decodificación de una imagen se hace en un hilo secundario en todos los navegadores modernos, y con decoding="async" el pintado ni siquiera espera a que termine. Su coste no aparece en el tiempo de bloqueo y no retrasa ninguna interacción. Todo el trabajo de JavaScript posterior a la descarga —parseo, compilación y ejecución— ocurre en el hilo principal, que es el mismo que responde al usuario. Son 300 KB que no cuestan nada frente a 300 KB que congelan la página durante casi un segundo.

El residuo. La imagen, una vez pintada, se puede descartar de memoria y volver a descodificar si hace falta; el navegador lo gestiona solo y libera bajo presión. El bytecode del módulo se queda vivo mientras la pestaña exista, ocupando entre dos y cuatro veces el tamaño del fuente descomprimido. Y no hay forma de pedirle al motor que lo suelte.

La segunda visita. Aquí está el argumento que cierra la discusión. En una visita repetida con la caché caliente, la imagen cuesta exactamente cero: sale del disco, se pinta, no hay nada más que hacer. El JavaScript ahorra la descarga y parte de la compilación gracias a la caché de código, pero la ejecución se repite entera, siempre. Ese medio segundo largo lo paga el usuario en cada visita, para siempre, cada vez.

La equivalencia práctica

De la tabla sale un factor de conversión mental que es útil aunque sea tosco: en términos de trabajo del hilo principal, un kilobyte de JavaScript cuesta del orden de 20 a 50 veces lo que un kilobyte de imagen. Con la segunda visita en cuenta, el factor se dispara porque el denominador tiende a cero.

Traducido a decisiones concretas:

• Quitar 50 KB de JavaScript de la ruta crítica libera entre 100 y 250 milisegundos de hilo principal en un móvil de gama media. Cada visita.
• Quitar 500 KB de imagen ahorra 2,5 segundos de descarga en una red lenta, mejora el LCP si esa imagen era el elemento mayor, y no libera prácticamente nada de hilo principal.

Las dos cosas hay que hacerlas, y son problemas distintos. El error es tratarlas como si fueran el mismo problema medido en la misma unidad. La imagen es un problema de ancho de banda; el JavaScript es un problema de CPU. Y el ancho de banda ha mejorado un orden de magnitud en quince años mientras que el rendimiento monohilo de los teléfonos baratos apenas se ha movido.

De ahí sale la regla de prioridad que ordena el trabajo:

1. Si el problema es el LCP, ataca primero la imagen del elemento mayor y su descubrimiento. La red domina.
2. Si el problema es el INP o la sensación de página congelada, ataca el JavaScript. La CPU domina, y ninguna cantidad de optimización de imágenes lo va a arreglar.
3. Si el problema es que la página va lenta en móvil y bien en tu portátil, es JavaScript. Siempre.

Medir esto en tu propia página

El argumento convence cuando los números son de tu producto. El procedimiento es de veinte minutos.

Primero, el desglose de bytes de tus scripts frente a tus imágenes, con la relación de compresión real:

const porTipo = { script: { t: 0, d: 0 }, img: { t: 0, d: 0 } };
for (const r of performance.getEntriesByType('resource')) {
  const k = r.initiatorType === 'script' ? 'script'
          : (r.initiatorType === 'img' || /\.(avif|webp|jpe?g|png)$/.test(r.name)) ? 'img'
          : null;
  if (!k) continue;
  porTipo[k].t += r.transferSize;
  porTipo[k].d += r.decodedBodySize;
}
console.table({
  script: { transferido_KB: (porTipo.script.t / 1024) | 0, procesado_KB: (porTipo.script.d / 1024) | 0 },
  imagen: { transferido_KB: (porTipo.img.t / 1024) | 0, procesado_KB: (porTipo.img.d / 1024) | 0 },
});

La columna procesado_KB de la fila de scripts es la cifra que hay que llevar a la reunión. Suele ser tres o cuatro veces mayor de lo que todo el mundo tenía en la cabeza.

Segundo, el tiempo de hilo principal. Graba un perfil de carga con la CPU estrangulada a 4x y usa el resumen por categoría: la porción de «scripting» frente a la de «pintura» y «renderizado». En una aplicación con marco es habitual ver una relación de ocho a uno a favor del scripting.

Tercero, y es el que produce el silencio en la sala: repite la medición con la caché caliente. Recarga sin vaciar caché y vuelve a mirar el resumen. Las imágenes desaparecen del perfil. El scripting se queda casi igual.