srcset: los descriptores w y x, y por qué no son intercambiables

Servir una sola imagen a todo el mundo significa servir la peor imagen posible: o pesa de más para el móvil o se ve borrosa en el portátil de 2x. srcset existe para que tú declares un menú de candidatos y el navegador elija, porque el navegador sabe cosas que tú no sabes en tiempo de compilación: la densidad de píxeles real de la pantalla, el ancho de la ventana en ese instante y, en algunos casos, la preferencia de ahorro de datos del usuario. La parte difícil no es la sintaxis, son las dos formas incompatibles de expresar el menú.

Por qué el navegador tiene que decidir, y no tú

El servidor no sabe nada del cliente que va a pintar la imagen. La cabecera User-Agent no dice la densidad de la pantalla, y el ancho de la ventana llega demasiado tarde: cuando el JavaScript puede leer window.innerWidth, el escáner de precarga ya ha pasado por el HTML y ha decidido qué descargar. Ese escáner es la razón de que una solución en JavaScript sea estructuralmente peor: corre en un hilo aparte, lee el HTML en bruto antes de que exista el DOM, y arranca las descargas de imágenes y hojas de estilo cientos de milisegundos antes de que el parser principal llegue ahí. Una imagen que solo existe como data-src es invisible para el escáner y pierde esa ventaja.

srcset resuelve el problema moviendo la decisión al único sitio que tiene toda la información: el propio navegador, en el momento del escaneo. Tú declaras los candidatos, él aplica el algoritmo. Y aplica el algoritmo con datos que ni siquiera están expuestos a JavaScript de forma fiable, como el factor de zoom del sistema operativo o el ajuste de escala de la interfaz.

El atributo tiene dos gramáticas distintas, y mezclarlas en el mismo srcset es un error de sintaxis: el navegador descarta el atributo entero y cae a src. Un fallo silencioso, sin aviso en consola en la mayoría de los casos, que devuelve la página al comportamiento de 2010.

El descriptor x: densidad, y solo densidad

El descriptor x declara para qué densidad de píxeles está pensado cada candidato.

<img
  src="logo-1x.png"
  srcset="logo-1x.png 1x, logo-2x.png 2x, logo-3x.png 3x"
  width="180"
  height="48"
  alt="Logotipo de la empresa"
>

Aquí el navegador hace una cuenta trivial: mira su devicePixelRatio y coge el candidato cuyo descriptor sea igual o superior. Con un DPR de 2 coge logo-2x.png. Con un DPR de 3 coge logo-3x.png. Con un DPR de 1,5 —muy común en portátiles Windows con escalado del 150 por ciento— coge logo-2x.png, porque el algoritmo redondea hacia arriba para no degradar la nitidez.

El descriptor x es correcto solo cuando la imagen tiene un tamaño de maquetación fijo, independiente del ancho de la ventana. Un logotipo en la cabecera, un icono, un avatar de 40 por 40 píxeles CSS, la firma de un artículo. Si el tamaño de la imagen depende del viewport, el descriptor x es inservible, porque un candidato de 2x para una ventana de 400 píxeles es un candidato de 0,5x para una ventana de 1600.

Cuando omites el descriptor, el valor por defecto es 1x. Por eso srcset="a.png, b.png 2x" es válido: a.png se interpreta como a.png 1x. Y por eso srcset="a.png, b.png" es un error: dos candidatos declarando la misma densidad.

El descriptor w: el ancho intrínseco del fichero

El descriptor w no describe para qué pantalla sirve el candidato. Describe cuántos píxeles de ancho tiene el fichero, y punto. Es un dato objetivo del recurso, no una intención.

<img
  src="hero-800.jpg"
  srcset="
    hero-400.jpg   400w,
    hero-800.jpg   800w,
    hero-1200.jpg 1200w,
    hero-1600.jpg 1600w,
    hero-2400.jpg 2400w
  "
  sizes="(min-width: 1100px) 1000px, 100vw"
  width="1600"
  height="900"
  alt="Vista aérea del puerto al amanecer"
>

El cambio de mentalidad importa: con w no le estás diciendo al navegador cuándo usar cada fichero, le estás diciendo qué es cada fichero. El cuándo lo calcula él combinando esos anchos con sizes y con la densidad de la pantalla. Esa separación es deliberada: los mismos ficheros sirven para cualquier maquetación, y cambiar el CSS del componente no obliga a regenerar imágenes, solo a corregir sizes.

La consecuencia práctica es que un srcset con w no funciona sin sizes. Si lo omites, el navegador asume sizes="100vw", es decir, que la imagen ocupa todo el ancho de la ventana. En una galería de tres columnas eso significa descargar sistemáticamente el triple de píxeles de los necesarios. Es el error más caro de esta lección y tiene su propia lección: cómo el navegador elige un candidato.

Cuánto se ahorra de verdad

Merece la pena hacer la cuenta una vez para tener el orden de magnitud en la cabeza. Toma una imagen de cabecera a ancho completo, entregada en AVIF con calidad perceptual equivalente:

Servir el fichero de 2400w a todo el mundo, que es lo que hace una página sin srcset, cuesta 310 KB al móvil que solo necesitaba 52 KB. Son 258 KB de más. A la velocidad efectiva de una conexión móvil mediocre —pongamos 1,6 Mbps, que es lo que simula el estrangulamiento estándar de las herramientas de auditoría— eso es 1,3 segundos añadidos a un recurso que además suele ser el elemento del LCP. Y el usuario paga esos bytes de su tarifa de datos.

La cuenta inversa también es instructiva. Si tu imagen de cabecera ya se sirve con srcset correcto, el margen que queda por optimizar en esa imagen es de decenas de kilobytes, no de cientos. En ese punto conviene dejar de tocar la imagen y mirar el JavaScript.