Las imágenes son, casi siempre, el elemento más pesado de una página web, y también el que más rápido se puede optimizar sin tocar una línea de lógica de negocio. Elegir bien el formato y la estrategia de carga afecta directamente al LCP (Largest Contentful Paint) y al CLS (Cumulative Layout Shift), dos de las métricas que Google usa para medir la experiencia de usuario y que también influyen en el SEO.

Formatos: WebP y AVIF frente a JPEG/PNG

WebP ofrece un tamaño de archivo bastante menor que JPEG con calidad visual equivalente, y ya tiene soporte prácticamente universal en navegadores modernos. AVIF comprime todavía mejor en muchos casos, a cambio de un tiempo de codificación algo mayor y de un soporte de navegador ligeramente más reciente. La estrategia más segura es servir AVIF o WebP con JPEG/PNG como fallback, usando la etiqueta <picture>:

<picture>
  <source srcset="foto.avif" type="image/avif">
  <source srcset="foto.webp" type="image/webp">
  <img src="foto.jpg" alt="Descripción de la imagen" width="800" height="600">
</picture>

Carga diferida (lazy loading) sin penalizar el LCP

El atributo nativo loading="lazy" evita que el navegador descargue imágenes que están fuera de la pantalla inicial, lo cual ahorra ancho de banda en páginas largas. El matiz importante: la imagen principal de la página (la que suele determinar el LCP, como la cabecera de un artículo) no debe llevar lazy — cargarla con prioridad normal (o incluso fetchpriority="high") es lo que mejora esa métrica. Aplicar lazy loading a todo por igual, incluida la imagen principal, es un error común que empeora el LCP en vez de mejorarlo.

Dimensiones explícitas para evitar saltos de layout

Cuando una imagen no tiene width y height (o un aspect-ratio en CSS), el navegador no puede reservar el espacio que va a ocupar antes de que termine de cargar, y el contenido de alrededor "salta" cuando la imagen aparece. Esto es exactamente lo que mide el CLS. La solución es simple: declarar siempre las dimensiones reales de la imagen, aunque el diseño final la escale con CSS.

Responsive images: no envíes un 4K a un móvil

srcset y sizes permiten que el navegador elija, entre varias versiones de la misma imagen, la que mejor se ajusta al tamaño real de pantalla del visitante:

<img
  srcset="foto-400.webp 400w, foto-800.webp 800w, foto-1600.webp 1600w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
  src="foto-800.webp"
  alt="Descripción">

Sin esto, es habitual que un móvil descargue exactamente la misma imagen de 1600px pensada para un monitor de escritorio, desperdiciando datos y tiempo de carga sin ningún beneficio visual.

Herramientas

Squoosh (de Google, gratuito) permite comparar formatos y niveles de compresión visualmente antes de exportar. Sharp es la librería de referencia en Node.js para automatizar conversión y redimensionado en un pipeline de build. Y Lighthouse, integrado en Chrome DevTools, señala exactamente qué imágenes están penalizando el LCP y el CLS en una página concreta.

En resumen

El orden de prioridad razonable es: usar formatos modernos con fallback, declarar siempre las dimensiones de la imagen, aplicar lazy loading solo a lo que está fuera de la pantalla inicial, y servir el tamaño de imagen adecuado a cada dispositivo con srcset. Ninguno de estos cambios requiere rediseñar nada — son ajustes puntuales que suelen notarse de inmediato en las métricas de Core Web Vitals.