Optimización técnica de imágenes para SEO

Las imágenes suelen ser el recurso más pesado de cualquier página, y a la vez el que peor se optimiza por defecto: subir una foto de 4000×3000 píxeles directamente desde una cámara o un móvil a un CMS, sin redimensionar ni comprimir, es la causa individual más común de un LCP alto. La buena noticia es que, a diferencia de otros problemas técnicos, la optimización de imágenes tiene soluciones concretas y medibles, no ajustes de opinión.

Formatos: cuándo usar WebP, AVIF o seguir con JPEG/PNG

WebP ofrece una reducción de peso de entre el 25% y el 35% frente a JPEG con una calidad visual equivalente, y tiene soporte prácticamente universal en navegadores modernos, así que es la opción por defecto razonable para la mayoría de proyectos hoy. AVIF comprime todavía mejor (hasta un 50% menos que JPEG en algunos casos) pero exige más tiempo de CPU para codificar la imagen la primera vez, lo que importa si se generan miles de variantes automáticamente; su soporte en navegadores es amplio pero algo más reciente que el de WebP. PNG sigue siendo necesario cuando hace falta transparencia real sin las limitaciones de compresión con pérdida, como logotipos o iconografía con bordes definidos, y SVG es siempre superior a cualquier formato de píxeles para iconos y logotipos vectoriales, porque escala sin perder nitidez y pesa una fracción de lo que pesaría la misma imagen rasterizada.

srcset y sizes: servir el tamaño correcto a cada pantalla

Un error extendido es servir la misma imagen, al mismo tamaño de archivo, tanto a un móvil de 375 píxeles de ancho como a un monitor de escritorio de 2560. El atributo srcset permite declarar varias versiones de la misma imagen a distintos anchos, y sizes le dice al navegador qué ancho va a ocupar realmente en cada punto de ruptura, para que descargue solo la versión que necesita:

<img
  src="producto-800.webp"
  srcset="producto-400.webp 400w, producto-800.webp 800w, producto-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  width="800" height="800"
  alt="Silla nórdica de roble">

Sin este atributo, un usuario en móvil descarga habitualmente entre 3 y 6 veces más datos de los que su pantalla puede llegar a mostrar, lo que penaliza directamente el LCP en el dispositivo donde más impacta (el tráfico móvil suele ser mayoritario y el hardware, más limitado).

Lazy loading: útil casi siempre, contraproducente en un caso concreto

El atributo nativo loading="lazy" retrasa la descarga de una imagen hasta que está a punto de entrar en el viewport, ahorrando ancho de banda en imágenes que el usuario puede que nunca llegue a ver. El error que sí importa evitar es aplicarlo a la imagen candidata a LCP (normalmente la primera imagen visible, por encima del scroll): retrasar deliberadamente la carga de la imagen que la propia métrica de rendimiento está midiendo es contraproducente y empeora el LCP en vez de mejorarlo. La regla práctica es simple: loading="lazy" en todo excepto en la primera imagen visible de la página, que debe llevar loading="eager" (o simplemente no llevar el atributo, que es el valor por defecto) y, si es la candidata a LCP, además fetchpriority="high".

<!-- Primera imagen visible: carga inmediata y prioritaria -->
<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">

<!-- Imágenes más abajo en la página: carga diferida -->
<img src="producto-2.webp" loading="lazy" width="400" height="400" alt="...">

Compresión: calidad visual frente a peso de archivo

La compresión con pérdida (lossy) de JPEG o WebP permite elegir un nivel de calidad, normalmente entre 0 y 100; en la práctica, valores entre 75 y 85 son indistinguibles a simple vista de la imagen original para la mayoría de fotografías, pero reducen el peso del archivo de forma sustancial frente a una calidad de 95 o 100, que rara vez se justifica salvo en fotografía de producto donde el zoom es una función clave. Comprimir de más (por debajo de 60) sí introduce artefactos visibles (bloques, pérdida de detalle en zonas con textura), así que el objetivo no es minimizar el peso a toda costa sino encontrar el punto donde reducir más ya no aporta ahorro perceptible a cambio de una pérdida de calidad visible.

Dimensiones explícitas: la conexión con Core Web Vitals

Toda imagen debe declarar width y height (o su equivalente en CSS, aspect-ratio), no solo por buenas prácticas sino porque es la causa más común y más fácil de arreglar de un CLS alto, como se explica en la guía de Core Web Vitals: sin esas dimensiones, el navegador no puede reservar el espacio que va a ocupar la imagen antes de descargarla, y el contenido de alrededor se desplaza cuando termina de cargar.

Texto alternativo: SEO real, no solo accesibilidad

El atributo alt cumple una doble función que rara vez se entiende completa: describe la imagen a lectores de pantalla para usuarios con discapacidad visual (su propósito principal), y es prácticamente la única fuente de contexto textual que Google tiene para entender qué muestra una imagen y poder indexarla en Google Imágenes o asociarla a una búsqueda relevante. Un alt útil describe lo que se ve de forma concisa y específica ("silla nórdica de roble con respaldo curvo", no "imagen1" ni, en el otro extremo, un párrafo repleto de palabras clave sin relación con lo que muestra la imagen, que Google interpreta como spam).

CDN y caché: por qué importan tanto como el propio archivo

Incluso una imagen perfectamente optimizada sigue dependiendo de la latencia de red hasta el servidor que la sirve. Un CDN (red de distribución de contenido) replica las imágenes en servidores geográficamente cercanos al usuario, reduciendo esa latencia; combinado con cabeceras de caché agresivas (como se explica en la guía de caché HTTP y CDN), permite que la segunda visita de un usuario, o la visita de otro usuario a la misma página, cargue las imágenes prácticamente al instante desde una caché intermedia sin volver a pedirlas al servidor de origen.

Preguntas frecuentes