Optimización de imágenes SEO: formatos, carga y tamaño

Cuando alguien busca «optimización de imágenes SEO» suele esperar una lista de plugins de compresión y un recordatorio de escribir el alt. Eso cubre una parte pequeña. Las que más rendimiento cuestan son otras: la portada que llega con loading="lazy" y retrasa el LCP, la foto de 4.000 píxeles que se muestra en un hueco de 400, o el banner puesto como fondo CSS que Google ni ve.

Aquí separo las decisiones que se toman con cada imagen (formato, tamaño, carga, estabilidad del diseño y descubrimiento), digo qué está documentado por Google y qué no, y enseño cómo lo tengo yo en cristofercruz.net, incluidos los huecos que me quedan. El texto alternativo tiene su propio artículo: texto alternativo (alt text).

Qué documenta Google sobre imágenes

La guía oficial de buenas prácticas de imágenes de Google Search es corta y conviene tenerla delante antes de leer cualquier artículo de terceros. Esto es lo que dice, ordenado por lo que afecta a la implementación.

Lo que no he encontrado en esa página ni en las de vista previa: un tamaño máximo de archivo recomendado en kilobytes, una preferencia de formato por ranking o una afirmación de que AVIF posicione mejor que WebP. Si lees una cifra mágica («menos de 100 KB»), es una regla de equipo, no una regla de Google. La guía sí recomienda medir la velocidad con PageSpeed Insights, y ahí está el vínculo real con el SEO: el peso y la carga de las imágenes afectan al LCP, y de eso hablo en el artículo de Core Web Vitals.

Formatos: WebP, AVIF y JPEG

La decisión práctica no es «cuál es mejor», sino cuál puedo servir con una reserva segura. WebP y AVIF comprimen mejor que los formatos antiguos en el uso habitual, y Google los indexa los dos. Con JPEG tienes compatibilidad universal, y con SVG un archivo que no pierde nitidez, pero solo para dibujos vectoriales.

Un dato para poner la adopción en perspectiva: el capítulo de Media del Web Almanac 2024 cuenta que, entre los recursos de imagen en móvil, WebP representaba el 12 % y AVIF el 1,0 %. Con esas cifras, pasarte a WebP no es ir tarde: la mayor parte de las imágenes todavía se sirve en otros formatos.

Una medición propia, con sus límites

Como no quiero citar porcentajes que no he medido, uso mis archivos. La portada de este artículo, una ilustración plana de 1600×900, ocupa 29.768 bytes en WebP y 105.296 bytes en JPEG progresivo: un 72 % menos. Ese número solo vale para este tipo de imagen, con bloques de color planos y bordes limpios, que comprimen muy bien en WebP. Con fotografías la diferencia puede ser menor, y el ajuste de calidad de cada archivo (84 en WebP, 86 en JPEG) no es idéntico. Para tu web, convierte tus tres o cuatro imágenes más pesadas y compara.

Cómo servir WebP o AVIF con reserva

Si necesitas dar AVIF o WebP a quien lo soporte y JPEG al resto, picture lo resuelve. El navegador usa el primer source cuyo formato soporte, y la etiqueta img es la reserva que Google exige:

<picture>
  <source type="image/avif" srcset="foto.avif">
  <source type="image/webp" srcset="foto.webp">
  <img src="foto.jpg" width="1600" height="1000" alt="Descripción">
</picture>

Si ya das WebP a todos, no necesitas picture. Todos los navegadores modernos lo soportan; solo hace falta la reserva si tu audiencia incluye navegadores antiguos que puedas medir.

Dimensiones, peso y compresión

El error de peso más frecuente que encuentro en auditorías no es el formato: es subir la foto original del móvil o de la cámara y dejar que el navegador la reduzca. El navegador descarga todos los píxeles aunque muestre un cuarto. Antes de pensar en AVIF, comprueba cuántos píxeles tiene el archivo y en qué hueco se muestra.

1. Mide el ancho máximo al que se muestra la imagen en tu diseño (en DevTools, el tamaño «renderizado»).
2. Exporta el archivo al doble de ese ancho como máximo, para pantallas de alta densidad, no más.
3. Prueba varios niveles de calidad con tus imágenes reales. No hay un número válido para todo.
4. Descarta el metadato que no necesites y vuelve a comparar.

Hay un dato que ayuda a no obsesionarse: según el mismo Web Almanac 2024, la imagen mediana en móvil pesa 12 KB. La mediana esconde a las que pesan mucho más, que son las que aparecen en los avisos de PageSpeed. Lo habitual no es que todas pesen demasiado, sino que una o dos hagan daño.

Y ojo con optimizar a ciegas: la guía de LCP de web.dev advierte de que reducir el tiempo de descarga de una imagen puede no mejorar el LCP, porque el tiempo ahorrado reaparece como retraso de renderizado si algo más bloquea la pintura. Comprueba primero en qué fase pierde tiempo tu LCP antes de comprimir.

srcset, sizes y picture para móvil y escritorio

Con srcset le das al navegador varios archivos del mismo contenido, y con sizes le dices a qué ancho se va a mostrar la imagen. El navegador combina esa información con la pantalla del dispositivo y elige uno. Lo que no controlas es cuál elige; lo que controlas es que las opciones sean razonables.

<img src="foto-800.webp"
     srcset="foto-480.webp 480w, foto-800.webp 800w, foto-1600.webp 1600w"
     sizes="(max-width: 900px) 100vw, 800px"
     width="1600" height="1000" alt="Descripción">

Dos reglas que se olvidan. Si usas descriptores de anchura (w), necesitas sizes; y no puedes mezclar descriptores w y de densidad (2x) en el mismo srcset. Además, picture con media solo hace falta cuando quieres otro recorte para móvil (dirección de arte), no para ahorrar peso: para eso basta srcset. Con la indexación mobile-first la versión que cuenta es la móvil, así que comprueba que sirve las mismas imágenes; la paridad entre versiones la repaso en mi guía de SEO móvil.

Si la imagen es la del LCP

Una imagen responsive que además es la principal puede precargarse con imagesrcset e imagesizes en un link rel="preload" dentro del HTML, de modo que el navegador aplique la misma lógica de selección que con srcset. Añade fetchpriority="high" también en el link.

width y height contra el CLS

Una imagen sin dimensiones ocupa 0 píxeles hasta que se descarga, y cuando llega empuja todo lo que tiene debajo. Eso es un salto de diseño. Con width y height en la etiqueta, el navegador calcula la proporción y reserva el hueco desde el primer pintado, aunque luego el CSS cambie el ancho con width:100%; height:auto.

El Web Almanac 2024 mide que solo el 32 % de las etiquetas img en móvil declaran a la vez width y height. Es el arreglo más barato de todo este artículo y casi nadie lo hace. Si prefieres CSS, aspect-ratio consigue lo mismo, y incluso una proporción equivocada produce menos salto que no declarar nada. Los umbrales de CLS y cómo se mide los tienes en el artículo de Core Web Vitals.

Lazy loading, la imagen LCP y fetchpriority

loading="lazy" pospone la descarga de una imagen hasta que está cerca de entrar en pantalla. Es lo correcto para todo lo que queda por debajo de la primera pantalla y lo incorrecto para la imagen que el navegador pinta primero. Google lo dice así en su guía de carga diferida: no apliques lazy loading al contenido que probablemente sea visible nada más abrir la página.

La guía de web.dev para optimizar el LCP es tajante: nunca pongas lazy loading en la imagen LCP, porque retrasa la petición hasta que el diseño confirma que está en pantalla. Pide además fetchpriority="high" en esa imagen, con una advertencia: ponerlo en más de una o dos imágenes deja de servir para algo. Y la imagen debe ser descubrible en el HTML inicial; si la pones con JavaScript, con data-src o como fondo CSS, el navegador tarda más en encontrarla.

El problema es frecuente: el Web Almanac 2024 encontró que el 9,5 % de las imágenes responsables del LCP en móvil llevaban loading="lazy", y lo califica de antipatrón que hace las páginas mucho más lentas. Suele venir de un plugin o un tema que aplica lazy a todas las imágenes por defecto.

Lazy loading y rastreo

El lazy loading nativo no suele dar problemas con Googlebot porque no depende de scroll ni de clics, y Google recomienda el nativo o IntersectionObserver. La comprobación que propone es mirar el HTML renderizado en la Inspección de URL: si las URLs de las imágenes aparecen en el src de las etiquetas img, el montaje funciona. Si las imágenes solo aparecen tras un evento o en atributos como data-src sin JavaScript que los pase a src, Google puede no verlas. Con los embeds ocurre lo mismo, y cómo aplicarlo a vídeos y mapas lo cuento en lazy loading en iframes.

Nombres de archivo y URLs estables

El nombre del archivo es una pista menor, pero gratis. Google pide nombres cortos y descriptivos, y que la extensión sea la del formato real: un .jpg que en realidad es WebP es un error de configuración. Yo uso minúsculas, guiones y el tema de la imagen: imgseo-carga.webp mejor que captura-final-2.webp.

La URL importa más que el nombre. Google documenta que referenciar la misma imagen con la misma URL en todas las páginas le permite cachearla y reutilizarla. Dos consecuencias prácticas:

• Si cambias el archivo, cambia también su URL (un hash o una versión en el nombre) y no esperes a que cada caché lo detecte. Esto enlaza con la política de caché que describo en caché SEO.
• Evita parámetros aleatorios o de sesión en la URL de la imagen: cada variante es una URL distinta. Google no lo documenta con estas palabras, pero se deduce de la recomendación de URL estable.

Si localizas el sitio, Google recomienda traducir también los nombres de archivo y codificar en URL los caracteres no latinos.

Google Imágenes, Discover y max-image-preview:large

Para aparecer en Google Imágenes hacen falta pocas condiciones, todas técnicas: la imagen en una etiqueta img con src, accesible para el rastreo (sin bloqueo en robots.txt) y en una página que la contextualice. Para Discover, la documentación añade requisitos de tamaño.

max-image-preview

La directiva max-image-preview acepta tres valores: none (sin vista previa), standard (una vista previa de tamaño por defecto) y large (una vista previa más grande, hasta el ancho de la ventana). Si no la indicas, Google puede mostrar una vista previa de tamaño por defecto. Para Discover, la documentación pide imágenes grandes habilitadas con max-image-preview:large o con AMP, de al menos 1.200 px de ancho y más de 300.000 píxeles en total, con proporción 16:9, y recomienda indicar la imagen con og:image o marcado schema.org, evitando logos y imágenes llenas de texto.

La directiva va en una metaetiqueta robots o en la cabecera X-Robots-Tag; tienes el detalle en el artículo sobre X-Robots-Tag. Ten presente que habilita la posibilidad, no la garantiza: Google no promete mostrar vista previa grande ni aparecer en Discover.

Sitemap de imágenes

Un sitemap de imágenes lista, dentro de cada url, las imágenes de esa página con image:image e image:loc. Cada url puede contener hasta 1.000 imágenes, y las URLs pueden estar en otro dominio (por ejemplo un CDN) si verificas ambos dominios en Search Console. Google retiró de su documentación las etiquetas image:caption, image:geo_location, image:title e image:license, así que no las uses en sitemaps nuevos.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://example.com/pagina/</loc>
    <image:image>
      <image:loc>https://example.com/img/foto.webp</image:loc>
    </image:image>
  </url>
</urlset>

Es útil cuando las imágenes se cargan de formas que Google podría no descubrir, y prescindible cuando todas están en etiquetas img de páginas ya rastreadas. Sobre sitemaps en general, tienes sitemaps XML.

CDN de imágenes

Un CDN de imágenes crea las variantes bajo demanda: tú subes un original y pides tamaño, formato y calidad mediante parámetros en la URL. Muchos incluyen un modo automático que elige el formato según el navegador, de manera que un mismo enlace puede devolver AVIF a un navegador, WebP a otro y JPEG a uno muy antiguo. El detalle que no se explica en las guías de SEO: el tipo real lo marca la cabecera content-type, así que una URL terminada en .jpg puede devolver WebP, y conviene que la extensión de la URL no mienta si el CDN te deja configurarlo, porque Google recomienda que coincida con el tipo real.

Un CDN merece la pena si tienes muchas imágenes, mucho tráfico internacional o varias versiones por imagen. Para un sitio pequeño con pocas imágenes y un build que las genera, puede ser más trabajo que beneficio. Si decides usarlo, verifica el dominio del CDN en Search Console, como indica Google, y comprueba con curl -I qué content-type y qué política de caché devuelve.

Cómo lo tengo yo en cristofercruz.net

Esto es lo que he comprobado leyendo el código del sitio, con sus carencias.

WebP con hash y caché de un año

Casi todo mi catálogo de imágenes es WebP (las de contenido, las portadas y los retratos), con PNG para logotipos y flechas de marca. Un script de build copia cada imagen a assets/cache con un hash de contenido de 12 caracteres en el nombre y guarda la correspondencia en un manifiesto que las plantillas consultan. Las reglas del servidor dan Cache-Control: public, max-age=31536000, immutable a los archivos con ese hash, y siete días a los que no lo llevan. En los artículos, el renderizador reescribe las rutas de /assets/ de cada img a su versión con hash.

La regla del año solo reconoce js, woff2, webp, svg, png y jpg; si algún día uso avif o jpeg, tendré que añadirlos.

width, height, lazy y la imagen principal

Las imágenes de las plantillas que he revisado (cabecera, pie, tarjetas del blog, retratos de las páginas de ciudad y figuras de los artículos) declaran width y height, y las que quedan fuera de la primera pantalla llevan loading="lazy" y decoding="async". En la home, el retrato principal es la imagen crítica: está precargado con imagesrcset e imagesizes, tiene srcset con versiones de 480 y 800 píxeles de ancho, fetchpriority="high" y no lleva loading="lazy".

La portada de cada artículo también lleva fetchpriority="high" y no es lazy. Tiene un detalle: por debajo de 900 píxeles de ancho la portada se oculta con CSS y el picture carga en su lugar un GIF de un píxel, así que en móvil no se descarga la portada.

max-image-preview:large

La plantilla imprime por defecto index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1. El listado del blog cambia a noindex, follow cuando hay filtro de categoría o búsqueda. El robots.txt no bloquea imágenes, CSS ni JavaScript (solo carpetas internas como /includes/ o /tools/).

El pipeline de imágenes del blog

Las figuras del blog las genero como HTML con SVG, las capturo con un navegador a 1600×1000, y las guardo como WebP con calidad 84; las portadas son de 1600×900 y se guardan en WebP y JPG (calidad 86, progresivo). Los scripts viven en tools/imagenes-blog, carpeta que el robots.txt bloquea y el servidor no sirve. Al preparar este artículo tenía 129 figuras con un peso medio de unos 53 KB, entre 36 y 68 KB cada una (6,7 MB en total).

Lo que no hago, o no he verificado

• No uso AVIF ni picture en ninguna plantilla.
• Las figuras de los artículos sirven un único archivo de 1600 píxeles, sin srcset: un móvil descarga el mismo que un monitor grande. Es una mejora pendiente, sobre todo en artículos con ocho figuras.
• Las tarjetas del blog muestran la portada de 1600×900 en un hueco de 800×450, es decir, descargan el doble de píxeles de los necesarios.
• No tengo sitemap de imágenes: sitemap.xml y el del blog solo listan páginas.
• La metaetiqueta og:image:width declara 1200×630 para todas las páginas, pero la portada de un artículo mide 1600×900. Es una incoherencia que debo corregir; el resto de tamaños y carencias están en mi guía de etiquetas Open Graph.
• No he verificado cómo muestran cada red social las vistas previas con imágenes WebP.

Cómo auditar las imágenes de una web

Mi orden de trabajo, de lo más rápido a lo más completo.

1. Código fuente

Con Ctrl+U, busca <img. Cada etiqueta debe tener src, width y height. La imagen principal no puede llevar loading="lazy", y las que están lejos de la primera pantalla deberían llevarlo. Si ves data-src sin src, apunta la página para el paso 4.

2. Cabeceras de la imagen

curl -sI https://tudominio.com/ruta/imagen.webp

Revisa content-type (que sea el formato real), content-length y cache-control. Si la imagen lleva hash en el nombre, espero un max-age largo; si no lo lleva, uno corto.

3. PageSpeed Insights

Identifica el elemento LCP y mira en qué fase pierde tiempo antes de tocar nada. Los avisos de tamaño de imagen, formato y carga diferida del informe te indican qué recursos pesan más.

4. Inspección de URL

En Search Console, prueba la URL en vivo y mira el HTML renderizado: las URLs de imagen deben aparecer en src. Si una imagen que debería indexarse no aparece ahí, Google tampoco la ve. Para tráfico de imágenes, filtra el informe de rendimiento por tipo de búsqueda «Imagen».

Por dónde empezar

1. Localiza la imagen LCP de tus cinco páginas más importantes y quítale loading="lazy" si lo lleva; añade fetchpriority="high".
2. Añade width y height a todas las etiquetas img que no los tengan.
3. Ordena tus imágenes por peso y rehaz las cinco más pesadas con las dimensiones reales y WebP.
4. Pon loading="lazy" en todo lo que esté fuera de la primera pantalla.
5. Si tus páginas tienen imágenes que Google podría no descubrir, crea un sitemap de imágenes; si no, no lo necesitas.
6. Comprueba que la política de meta robots incluye max-image-preview:large y que no bloqueas las carpetas de imágenes en robots.txt (más en robots.txt).
7. Vuelve a pasar PageSpeed Insights y compara el LCP.

Si quieres que lo revise con datos de tu web, entra en lo que hago en una auditoría SEO. Y si el cuello de botella es el flujo de imágenes de un blog o una tienda con mucho contenido, lo abordo dentro de un plan de marketing de contenidos.

Preguntas frecuentes

Referencias y fuentes

Documentación consultada para este artículo.

1. Prácticas recomendadas de SEO para imágenes Google Search Central
2. Image sitemaps Google Search Central
3. Robots meta tag, data-nosnippet y X-Robots-Tag Google Search Central
4. Google Discover y tu sitio web Google Search Central
5. Fix lazy-loaded content Google Search Central
6. Optimize Largest Contentful Paint web.dev · Google
7. Browser-level image lazy-loading for the web web.dev · Google
8. Web Almanac 2024: Media HTTP Archive