Imágenes ligeras y sin saltos de diseño: formatos, tamaños y atributos

Una imagen mal servida puede estropear dos métricas a la vez: si pesa demasiado retrasa el LCP, y si llega sin hueco reservado empuja el texto hacia abajo y sube el CLS. Las dos cosas se arreglan en el HTML, sin herramientas exóticas. Hay que decidir tres cosas para cada imagen: en qué formato, a qué tamaño y con qué atributos.

Elegir formato por tipo de imagen

La guía de MDN resume la recomendación general: para imágenes de mapa de bits, preferir WebP o AVIF, que suelen comprimir mejor que JPEG, PNG y GIF; para diagramas, gráficas e iconos que deben verse nítidos a cualquier tamaño, SVG. MDN cita que el WebP con pérdida queda, de media, entre un 25 % y un 35 % por debajo de un JPEG de calidad visual parecida. Hoy los navegadores principales admiten WebP y AVIF, pero MDN sigue aconsejando ofrecer una alternativa en JPEG o PNG con <picture> cuando uses AVIF.

Criterio de taller: si la imagen tiene bordes nítidos y pocos colores, piensa primero en SVG o WebP sin pérdida; si tiene degradados y textura de foto, en AVIF o WebP con pérdida. Las ilustraciones de este sitio, por ejemplo, son SVG de pocos kilobytes.

El tamaño justo: srcset y sizes

El error más común no es el formato, sino servir una foto de 2400 píxeles a una columna que mide 800. El navegador la descarga entera y luego la reduce. Con srcset le ofreces varias versiones con su ancho real (descriptor w), y con sizes le dices qué ancho ocupará la imagen en la maqueta. Con esas dos pistas, y la densidad de píxeles de la pantalla, el navegador elige el archivo más pequeño que se verá bien.

<img
  src="/img/taller-1600.jpg"
  srcset="/img/taller-800.jpg 800w,
          /img/taller-1200.jpg 1200w,
          /img/taller-1600.jpg 1600w,
          /img/taller-2400.jpg 2400w"
  sizes="(max-width: 860px) 100vw, 800px"
  width="1600" height="1067"
  alt="Banco de trabajo con herramientas de encuadernación">

Ese sizes dice: en pantallas de hasta 860 px de ancho la imagen ocupa todo el viewport; en las demás, 800 px CSS. Si mientes en sizes (por ejemplo, dejas 100vw en una imagen que en escritorio ocupa media pantalla), el navegador descargará una versión más grande de la necesaria. Y sizes debe describir la maqueta real: si cambias el CSS de la columna, revísalo.

Para combinar formato y tamaño, usa <picture> con un <source type="image/avif"> y otro type="image/webp", cada uno con su srcset, y deja el <img> final con JPEG como alternativa. Los atributos width, height, alt, loading y fetchpriority van siempre en el <img>.

Cuántos bytes ahorras: un cálculo ilustrativo

Lo que este cálculo enseña: el ancho importa al cuadrado. Pasar de 2400 a 1600 px elimina más de la mitad de los datos aunque parezca un cambio modesto. En un móvil con red lenta, esos 267 KB pueden ser una parte apreciable del tiempo de LCP.

Reservar el hueco: width, height y aspect-ratio

Cuando el navegador encuentra un <img> sin dimensiones, no sabe cuánto espacio reservar hasta descargar los primeros bytes. Mientras tanto, el bloque mide 0 px de alto; cuando la imagen llega, empuja todo lo de debajo. Ese empujón es un desplazamiento de diseño que suma al CLS (cómo se calcula está en LCP, INP y CLS: qué miden).

web.dev recomienda incluir siempre width y height en imágenes y vídeos, o reservar el espacio con la propiedad CSS aspect-ratio. No fijan el tamaño en pantalla: el navegador usa los dos números para calcular la proporción y reservar el alto correcto antes de la descarga. Para que la imagen siga siendo adaptable, acompáñalos de este CSS:

img {
  max-width: 100%;
  height: auto;
}

Los valores deben corresponder a la proporción real de la imagen, normalmente su tamaño intrínseco (en el ejemplo, 1600 × 1067). Si en <picture> ofreces recortes distintos según el ancho de pantalla, cada <source> admite sus propios width y height. Para contenedores sin imagen propia (un iframe, un hueco para un anuncio), usa aspect-ratio o al menos una altura mínima razonable.

Prioridad de carga: lazy fuera, fetchpriority dentro

loading="lazy" pide al navegador que espere a que la imagen esté cerca del viewport para descargarla. Es útil para las imágenes de más abajo, pero web.dev es tajante con la imagen LCP: nunca debe llevar carga diferida, porque retrasa su petición hasta después de calcular el diseño. Ojo con los gestores de contenido y componentes de frameworks que ponen lazy a todas las imágenes por defecto.

A la inversa, fetchpriority="high" indica que esa imagen merece prioridad alta. Las imágenes no bloquean el renderizado y por eso no empiezan con la prioridad más alta; esta pista compensa eso. web.dev advierte de que marcar como prioritarias más de una o dos imágenes le quita utilidad. Además, el navegador debe poder encontrar la imagen en el HTML inicial: si la inserta JavaScript o es un fondo CSS, el navegador no la ve hasta tarde. En ese caso, una precarga con <link rel="preload" as="image" fetchpriority="high"> ayuda.

Lista de comprobación por imagen

Pasa esta lista por cada plantilla (portada, artículo, listado), no por cada imagen suelta: casi siempre los fallos se repiten en todas las páginas que comparten plantilla.

• El formato encaja con el contenido: foto en AVIF o WebP con alternativa; diagrama o logotipo en SVG.
• Hay versiones en varios anchos y srcset las describe con su ancho real en w.
• sizes refleja el ancho que ocupa la imagen en la maqueta actual, no un 100vw genérico.
• La versión más grande no supera el doble del ancho CSS máximo de la caja (salvo que necesites zoom).
• width y height están presentes y respetan la proporción, con height: auto en CSS.
• La imagen LCP no lleva loading="lazy", lleva fetchpriority="high" y aparece en el HTML inicial.
• Las imágenes por debajo del primer pantallazo llevan loading="lazy".
• El texto alternativo describe la imagen o está vacío (alt="") si es decorativa.