Lazy loading y fetchpriority en imágenes

La idea básica

Al cargar una página, el navegador tiene que decidir en qué orden descarga decenas de recursos. Para las imágenes, dos atributos te permiten guiar esa decisión:

• loading="lazy": "no descargues esta imagen hasta que esté cerca de verse".
• fetchpriority="high": "esta imagen es importante, descárgala cuanto antes".

Son complementarios: lazy para lo que está por debajo del pliegue y prioridad alta para la imagen principal.

loading="lazy"

<img src="galeria-12.webp" loading="lazy" width="800" height="600" alt="…">

Con este atributo, el navegador retrasa la descarga hasta que la imagen se acerca a la ventana visible. Los umbrales los decide el navegador según la conexión (en Chrome, entre 1250 y 2500 px de distancia). Está soportado en todos los navegadores modernos y no necesita JavaScript.

Ventajas: ahorra datos a quien no hace scroll y libera ancho de banda para lo que sí importa al principio.

Dónde usarlo: galerías, imágenes de artículos más abajo del primer pantallazo, miniaturas de listados largos, avatares de comentarios, logotipos del pie de página.

El error más caro: lazy en la imagen principal

Si la imagen que se ve al cargar (el LCP) lleva loading="lazy", el navegador no la pedirá hasta haber calculado el diseño de la página, lo que puede retrasar el LCP varios cientos de milisegundos. Es uno de los fallos más comunes que detecta Lighthouse.

Muchos CMS y plugins añaden lazy a todas las imágenes de forma automática. Revisa que la primera imagen visible no lo lleve. WordPress, por ejemplo, ya omite el atributo en la primera imagen de contenido desde la versión 5.9, pero los temas y constructores visuales pueden saltarse esa lógica.

fetchpriority="high"

<img src="hero.avif" fetchpriority="high" width="1600" height="900" alt="…">

Por defecto, las imágenes empiezan con prioridad baja y se elevan cuando el navegador descubre que están en la ventana visible. fetchpriority="high" se salta esa espera. Está soportado en Chrome, Edge, Safari y Firefox.

Úsalo en una o dos imágenes como máximo por página: la imagen LCP y, como mucho, otra crítica. Si todo es prioritario, nada lo es.

También puedes usar fetchpriority="low" para rebajar imágenes visibles pero secundarias, como las diapositivas ocultas de un carrusel.

decoding="async"

<img src="foto.webp" decoding="async" …>

Indica que la decodificación de la imagen puede hacerse sin bloquear otras tareas de renderizado. El impacto es pequeño y los navegadores ya hacen mucho de esto por defecto, pero es inocuo en la mayoría de imágenes. ImageZap lo incluye en el código generado.

Resumen por tipo de imagen

Lazy loading con JavaScript

Antes del soporte nativo se usaban librerías que cambiaban data-src por src con un IntersectionObserver. Hoy rara vez son necesarias y tienen inconvenientes: el HTML inicial no contiene la URL real (peor para el descubrimiento) y dependen de que el JavaScript se ejecute. Si tu sitio todavía usa una, plantéate sustituirla por el atributo nativo.

Preguntas frecuentes

¿Lazy loading afecta al SEO?

El lazy nativo no: Google renderiza la página y ve las imágenes. Las soluciones con JavaScript que no ponen la URL en el HTML sí pueden dificultar la indexación.

¿Debo poner lazy en iframes?

Sí, loading="lazy" también funciona en <iframe>, útil para vídeos de YouTube y mapas incrustados.

¿fetchpriority sustituye a preload?

No. preload sirve para recursos que el navegador no descubriría pronto (fondos CSS, imágenes insertadas por JS). Si la imagen ya está en el HTML, basta con fetchpriority.

¿Cuántas imágenes deberían cargarse sin lazy?

Las que aparecen en el primer pantallazo en móvil y en escritorio. Normalmente, entre una y cuatro.