Soluciona 'Defer Offscreen Images': Guía de lazy loading para los Core Web Vitals

¿Qué es 'defer offscreen images'?

La advertencia defer offscreen images era una auditoría de Lighthouse que marcaba las páginas con imágenes a las que se les podía aplicar lazy loading. Lighthouse marcaba las imágenes que cumplían todos estos criterios:

• La imagen termina por debajo de 3 veces la altura del viewport.
  Cuando a una imagen no se le aplica lazy loading y termina por debajo de 3 veces la altura de la parte visible de la página, y comienza por debajo de la parte visible de la página.
• La imagen es mayor a 0.02 MB o tarda más de 50ms en cargar.
  Las imágenes que son pequeñas o en línea (inlined) son ignoradas. Los scripts de lazy loading a menudo usan pequeñas imágenes de marcador de posición (placeholder) que caen por debajo de este umbral.
• La imagen no tiene un atributo loading definido.
  Lighthouse ignora las imágenes que tienen el atributo loading="lazy" o loading="eager".

Esta auditoría fue eliminada en Lighthouse 13

A partir de Lighthouse 13 (octubre de 2025), esta auditoría ha sido eliminada por completo. El equipo de Chrome determinó que los navegadores modernos ya reducen la prioridad de las imágenes fuera de pantalla, por lo que la auditoría generaba más ruido que comentarios útiles.

Pero aquí está el detalle: la optimización en sí sigue siendo importante. Aplicar lazy loading a las imágenes fuera de pantalla reduce el ancho de banda, libera conexiones de red para recursos críticos y mejora tu Largest Contentful Paint (LCP). El hecho de que Lighthouse ya no lo marque significa que debes verificarlo tú mismo. Utiliza Real User Monitoring o audita manualmente tus páginas en busca de imágenes que carguen sin loading="lazy".

Un breve recordatorio: ¿qué es el lazy loading?

El lazy loading significa que las imágenes que no están en la parte visible de la página se cargan en un momento posterior, generalmente justo antes de que aparezcan al hacer scroll. El navegador solo obtiene la imagen cuando el usuario se acerca a ella. Esto ahorra ancho de banda y permite que el navegador se centre en los recursos que realmente importan para la renderización inicial.

¿Qué causa las imágenes fuera de pantalla con carga eager?

Las imágenes no se aplazan por defecto. Las imágenes fuera de pantalla que no se aplazan terminan en la página porque falta el atributo loading o la imagen no es gestionada por una biblioteca de lazy loading. Causas comunes:

• Plugins mal programados en tu CMS.
• Plugins que desactivan el lazy loading nativo.
• Imágenes de fondo (estas necesitan un enfoque diferente a loading="lazy").
• Constructores de páginas que generan mal HTML (por ejemplo: Elementor o WP Bakery).
• Texto copiado y pegado en un editor WYSIWYG (como TinyMCE).
• Mala programación de plantillas.

¿Cómo afectan las imágenes fuera de pantalla a tus Core Web Vitals?

Las imágenes fuera de pantalla no impactan directamente en las métricas de Lighthouse. Pero hacen que la renderización de una página web sea innecesariamente complicada. Tu navegador necesitará descargar más recursos antes de que la página pueda mostrarse en pantalla. Hay 3 problemas con las imágenes fuera de pantalla cargadas de forma temprana (eager):

• Más descargas antes de renderizar. Tu navegador necesitará descargar imágenes que el usuario ni siquiera puede ver aún.
• Los recursos críticos pierden prioridad. Las imágenes compiten por el ancho de banda con recursos que realmente se necesitan para la renderización, como tu CSS y tu imagen LCP.
• Mayor uso de memoria. Decodificar imágenes a las que el usuario aún no ha llegado al hacer scroll desperdicia memoria, especialmente en dispositivos móviles de gama baja.

Según el capítulo sobre el Peso de la Página del Web Almanac 2025, la mediana de las páginas móviles carga 15 imágenes. En el percentil 90, ese número salta a 52. En páginas con muchas imágenes, aplicar lazy loading a las que están fuera de pantalla puede marcar una verdadera diferencia. En los sitios monitorizados por CoreDash, el 76% de las páginas que aplican correctamente el lazy loading a las imágenes fuera de pantalla aprueban el LCP, comparado con el 59% de las páginas que no lo hacen.

Cómo solucionar 'defer offscreen images'

Para solucionar las imágenes fuera de pantalla con carga temprana, añade loading="lazy" a cada imagen que esté por debajo del pliegue (below the fold). El lazy loading nativo ahora está soportado por el 95% de los navegadores a nivel mundial, incluyendo Chrome, Firefox, Safari y Edge. No necesitas una biblioteca para esto.

<img loading="lazy"
     src="image.webp"
     alt="una imagen con lazy loading nativo"
     width="300" height="300">

Rastrea los orígenes de tus imágenes con carga eager. Comprueba qué imágenes cargan sin un atributo loading y averigua qué las está colocando en la página. Hay 5 sospechosos habituales:

1. Plugins mal programados en tu CMS.
   Algunos plugins añaden HTML directamente a la página y no usan los hooks correctos que habilitan el lazy loading.
2. Plugins que desactivan el lazy loading nativo.
   Algunos plugins desactivan el lazy loading nativo por defecto. Revisa la configuración de tus plugins.
3. Constructores de páginas que generan mal HTML.
   Los constructores de páginas como Elementor o WP Bakery a menudo crean código inflado que está lejos de ser perfecto. No hay una solución fácil para esto. La solución incluye limpiar tu código y cambiar tu flujo de trabajo.
4. Texto copiado y pegado en un editor WYSIWYG.
   La mayoría de los editores WYSIWYG como TinyMCE hacen un mal trabajo al limpiar el código pegado, especialmente cuando se pega desde otra fuente de texto enriquecido como Microsoft Word. Es posible que estos editores no añadan lazy loading a tus imágenes.
5. Mala programación de plantillas.
   Incluso cuando el lazy loading está habilitado, las imágenes codificadas (hardcoded) en tus plantillas podrían seguir sin tener lazy loading. Revisa tus plantillas en busca de imágenes fuera de pantalla y aplícales lazy loading.

No apliques lazy loading a tu imagen LCP

Esta es la regla más importante del lazy loading: nunca apliques loading="lazy" a tu imagen Largest Contentful Paint. La imagen LCP es casi siempre la imagen principal (hero image) o el elemento visible más grande en el viewport. Según el Web Almanac 2025, el 16% de las páginas móviles todavía aplican lazy loading a su imagen LCP. Ese único atributo puede añadir de 200 a 500 milisegundos a tu LCP.

En su lugar, haz lo contrario para tu imagen LCP. Asegúrate de que cargue lo más rápido posible con fetchpriority="high":

<img fetchpriority="high"
     loading="eager"
     src="hero.webp"
     alt="Imagen hero"
     width="1200" height="600">

Si por accidente aplicaste lazy loading a tu imagen LCP, lee cómo solucionar una imagen LCP cargada con lazy loading. Para una guía completa sobre la optimización de imágenes, consulta optimizar imágenes para los Core Web Vitals.

Hoja de referencia para la carga de imágenes

No todas las imágenes deben ser tratadas de la misma manera. Aquí se explica cómo manejar los 4 escenarios más comunes:

Lazy loading nativo vs scripts de lazy loading

Usa loading="lazy" nativo. En 2026, no hay razón para añadir una biblioteca JavaScript de lazy loading para los elementos <img> estándar. El lazy loading nativo es compatible con todos los navegadores principales, incluyendo Safari (desde la versión 15.4), cubriendo al 95% de los usuarios a nivel mundial. Requiere cero JavaScript, no añade sobrecarga (overhead) y funciona de forma predeterminada.

Bibliotecas como lazysizes eran esenciales antes de que los navegadores soportaran el lazy loading nativo. Ya no se mantienen y no son necesarias para la mayoría de los sitios. Los únicos escenarios en los que aún podrías necesitar una solución en JavaScript:

• Imágenes de fondo CSS. El lazy loading nativo solo funciona en los elementos <img> y <iframe>. Para las imágenes de fondo necesitas IntersectionObserver o content-visibility: auto.
• Umbrales de carga personalizados. Chrome comienza a cargar las imágenes "lazy" aproximadamente 1250px por debajo del viewport en conexiones rápidas y a 2500px en conexiones lentas. No puedes personalizar esta distancia. Si necesitas un control más estricto, un IntersectionObserver con un rootMargin personalizado te lo proporciona.

Si necesitas una biblioteca, usa vanilla-lazyload en lugar de lazysizes. Se mantiene activamente, usa IntersectionObserver y soporta imágenes de fondo.

Previene el layout shift en las imágenes con lazy loading

Incluye siempre los atributos width y height en las imágenes con lazy loading. Sin dimensiones explícitas, el navegador no sabe cuánto espacio reservar. Cuando la imagen finalmente carga, empuja el contenido circundante hacia abajo, causando Cumulative Layout Shift (CLS). Según el Web Almanac 2025, el 62% de las páginas móviles todavía tienen al menos una imagen sin dimensiones.

<!-- Mal: causa layout shift -->
<img loading="lazy" src="photo.webp" alt="Foto">

<!-- Bien: las dimensiones reservan el espacio -->
<img loading="lazy" src="photo.webp" alt="Foto" width="800" height="600">

Soluciones alternativas cuando no puedes usar lazy loading

A veces no es posible aplazar las imágenes fuera de pantalla. Es posible que no tengas acceso a la plantilla o que tu CMS no soporte lazy loading. Existen algunas soluciones alternativas para disminuir el impacto. Están lejos de ser perfectas y podrían introducir nuevos desafíos.

• Comprime tus imágenes. Las imágenes más pequeñas tienen un impacto menor en el rendimiento de carga que las imágenes grandes. Utiliza técnicas modernas de compresión para reducir el tamaño del archivo.
• Usa formatos de imagen más rápidos. Cambia de PNG y JPEG a WebP o AVIF. WebP se comprime a aproximadamente 1.3 bits por píxel en comparación con los 2.0 de JPEG, según el capítulo de Multimedia del Web Almanac 2024.
• Divide las páginas grandes en varias páginas. Dividir las páginas grandes reduce la cantidad de imágenes que necesitan cargarse a la vez.
• Implementa el scroll infinito. El scroll infinito es básicamente lazy loading, solo que no para imágenes sino para partes enteras de la página web. En páginas con muchos elementos repetidos (piensa en Pinterest), el scroll infinito puede acelerar considerablemente la carga inicial.

Para consideraciones específicas de móviles, las imágenes fuera de pantalla son un problema aún mayor porque las conexiones móviles son más lentas y los viewports móviles son más pequeños, lo que significa que más imágenes terminan fuera de pantalla.

Cualquiera que sea el enfoque que adoptes, verifica que funcione con usuarios reales. Configura un Real User Monitoring para rastrear si tus cambios realmente mejoran el LCP y los Core Web Vitals en general en el campo.