Solucionar 'Defer Offscreen Images': Guía de Lazy Loading para Core Web Vitals
Difiere las imágenes fuera de pantalla (offscreen images) y mejora los Core Web Vitals

'Defer offscreen images' en resumen
Al cargar cualquier página con imágenes fuera de pantalla (offscreen), un navegador a menudo necesitará descargar más imágenes de las estrictamente necesarias. Esto causa un retraso en el renderizado de la página.
Soluciona esto agregando loading="lazy" a todas las imágenes debajo de la mitad de la página (below-the-fold). El lazy loading nativo es compatible con todos los navegadores principales con una cobertura global del 95%.
Última revisión por Arjen Karel en febrero de 2026

¿Qué es 'defer offscreen images'?

La advertencia de defer offscreen images era una auditoría de Lighthouse que señalaba las páginas con imágenes a las que se les podía aplicar lazy load. Lighthouse señalaba las imágenes que cumplían con todos estos criterios:
- La imagen termina por debajo de 3 veces la altura del viewport.
Cuando una imagen no tiene lazy load 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 50 ms en cargar.
Las imágenes que son pequeñas o están en línea (inlined) son ignoradas. Los scripts de lazy loading a menudo usan imágenes de marcador de posición (placeholder) pequeñas que caen por debajo de este umbral. - La imagen no tiene un atributo de carga (loading) definido.
Lighthouse ignora las imágenes que tienen el atributoloading="lazy"oloading="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 quitan prioridad a las imágenes fuera de pantalla, por lo que la auditoría generaba más ruido que comentarios útiles.
Pero aquí está el asunto: la optimización en sí todavía importa. Aplicar lazy load 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 señale significa que debes verificarlo tú mismo. Usa Real User Monitoring o audita manualmente tus páginas en busca de imágenes que se carguen sin loading="lazy".
Un recordatorio rápido: ¿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 se desplacen a la vista. El navegador solo obtiene la imagen cuando el usuario se acerca a ella. Esto ahorra ancho de banda y permite que el navegador se concentre en los recursos que realmente importan para el renderizado inicial.
¿Qué causa las imágenes fuera de pantalla cargadas de forma eager?
Las imágenes no se difieren por defecto. Las imágenes fuera de pantalla que no se difieren terminan en la página porque falta el atributo loading o la imagen no es manejada por una biblioteca de lazy loading. Causas comunes:
- Plugins mal codificados en tu CMS.
- Plugins que desactivan el lazy loading nativo.
- Imágenes de fondo (Background images) (estas necesitan un enfoque diferente al de
loading="lazy"). - Constructores de páginas (Page builders) que generan HTML deficiente (por ejemplo: Elementor o WP Bakery).
- Texto que se copia y pega en un editor WYSIWYG (como TinyMCE).
- Mala codificació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 el renderizado de una página web sea innecesariamente complicado. Tu navegador necesitará descargar más recursos antes de que la página pueda mostrarse en la pantalla. Hay 3 problemas con las imágenes fuera de pantalla cargadas de forma eager:
- Más descargas antes del renderizado. Tu navegador necesitará descargar imágenes que el usuario ni siquiera puede ver todavía.
- A los recursos críticos se les quita prioridad. Las imágenes compiten por el ancho de banda con recursos que realmente se necesitan para el renderizado, como tu CSS y tu imagen LCP.
- Mayor uso de memoria. Decodificar imágenes a las que el usuario aún no se ha desplazado desperdicia memoria, especialmente en dispositivos móviles de gama baja.
De acuerdo con el capítulo Page Weight del Web Almanac de 2025, la página móvil mediana carga 15 imágenes. En el percentil 90, ese número salta a 52. En páginas con muchas imágenes, el lazy load de las que están fuera de pantalla puede hacer una gran diferencia. En los sitios monitoreados por CoreDash, el [CD:placeholder]% de las páginas que aplican correctamente el lazy load a las imágenes fuera de pantalla pasan el LCP, en comparación con el [CD:placeholder]% de las páginas que no lo hacen.
Cómo solucionar 'defer offscreen images'
Para solucionar las imágenes fuera de pantalla cargadas de forma eager, agrega loading="lazy" a cada imagen que esté por debajo del scroll (below the fold). El lazy loading nativo ahora es compatible con 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 nativa con lazy load"
width="300" height="300">
Rastrea los orígenes de tus imágenes cargadas de forma eager. Verifica qué imágenes se cargan sin un atributo loading y descubre qué las está colocando en la página. Hay 5 sospechosos habituales:
-
Plugins mal codificados en tu CMS.
Algunos plugins agregan HTML directamente a la página y no usan los ganchos (hooks) correctos que habilitan el lazy loading. -
Plugins que desactivan el lazy loading nativo.
Algunos plugins desactivan el lazy loading nativo por defecto. Revisa la configuración de tu plugin. -
Constructores de páginas que generan HTML deficiente.
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. -
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. Estos editores podrían no agregar lazy loading a tus imágenes. - Mala codificación de plantillas.
Incluso cuando el lazy loading está habilitado, es posible que a las imágenes codificadas de forma rígida (hardcoded) en tus plantillas aún no se les aplique el lazy load. Revisa tus plantillas en busca de imágenes fuera de pantalla y aplícales lazy load.
No apliques lazy load a tu imagen LCP
Esta es la regla más importante del lazy loading: nunca apliques loading="lazy" a tu imagen de Largest Contentful Paint. La imagen LCP es casi siempre la imagen hero o el elemento visible más grande en el viewport. Según el Web Almanac de 2025, el 16% de las páginas móviles todavía aplican lazy load a su imagen LCP. Ese único atributo puede agregar de 200 a 500 milisegundos a tu LCP.
En su lugar, haz lo contrario para tu imagen LCP. Asegúrate de que se cargue lo más rápido posible con fetchpriority="high":
<img fetchpriority="high"
loading="eager"
src="hero.webp"
alt="Hero image"
width="1200" height="600">
Si accidentalmente aplicaste lazy load a tu imagen LCP, lee cómo solucionar una imagen LCP cargada con lazy load. Para obtener una guía completa sobre cómo optimizar imágenes, consulta optimizar imágenes para Core Web Vitals.
Cheatsheet para la carga de imágenes
No todas las imágenes deben tratarse de la misma manera. Aquí se explica cómo manejar los 4 escenarios más comunes:
| Tipo de imagen | loading | fetchpriority | Por qué |
|---|---|---|---|
| LCP / hero image | eager |
high |
Esta es la imagen más importante. Cárgala primero. |
| Above the fold (no LCP) | eager |
(por defecto) | Visible al cargar, pero no es el elemento LCP. |
| Below the fold | lazy |
(por defecto) | Aún no visible. Diferir hasta que el usuario se desplace. |
| CSS background image | IntersectionObserver | loading="lazy" no funciona en imágenes de fondo. Usa un enfoque diferente. |
|
Lazy loading nativo vs scripts de lazy loading
Usa el loading="lazy" nativo. En 2026, no hay razón para agregar una biblioteca JavaScript de lazy loading para elementos <img> estándar. El lazy loading nativo es compatible con todos los navegadores principales, incluido Safari (desde la versión 15.4), cubriendo el 95% de los usuarios a nivel mundial. Requiere cero JavaScript, no agrega gastos generales (overhead) y funciona de forma predeterminada (out of the box).
Las bibliotecas como lazysizes eran esenciales antes de que los navegadores admitieran el lazy loading nativo. Ya no se mantienen y ya no son necesarias para la mayoría de los sitios. Los únicos escenarios en los que podrías seguir necesitando una solución JavaScript:
- CSS background images. El lazy loading nativo solo funciona en elementos
<img>e<iframe>. Para las imágenes de fondo necesitas IntersectionObserver ocontent-visibility: auto. - Umbrales de carga personalizados. Chrome comienza a cargar imágenes "lazy" aproximadamente 1250 px por debajo del viewport en conexiones rápidas y 2500 px en conexiones lentas. No puedes personalizar esta distancia. Si necesitas un control más estricto, un IntersectionObserver con un
rootMarginpersonalizado te lo proporciona.
Si realmente necesitas una biblioteca, usa vanilla-lazyload en lugar de lazysizes. Se mantiene activamente, usa IntersectionObserver y admite imágenes de fondo.
Prevenir el layout shift en imágenes con lazy load
Incluye siempre los atributos width y height en las imágenes con lazy load. Sin dimensiones explícitas, el navegador no sabe cuánto espacio reservar. Cuando la imagen finalmente se carga, empuja el contenido circundante hacia abajo, causando Cumulative Layout Shift (CLS). Según el Web Almanac de 2025, el 62% de las páginas móviles todavía tienen al menos una imagen sin dimensiones.
<!-- Malo: causa layout shift --> <img loading="lazy" src="photo.webp" alt="Foto"> <!-- Bueno: las dimensiones reservan espacio --> <img loading="lazy" src="photo.webp" alt="Foto" width="800" height="600">
Soluciones alternativas cuando no puedes usar lazy load
A veces no es posible diferir las imágenes fuera de pantalla. Es posible que no tengas acceso a la plantilla o que tu CMS no admita el lazy loading. Hay algunas soluciones alternativas para disminuir el impacto. Estas 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. Usa técnicas de compresión modernas 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 comprime a aproximadamente 1.3 bits por píxel en comparación con 2.0 para JPEG según el capítulo Media del Web Almanac de 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 desplazamiento infinito (infinite scroll). El desplazamiento infinito es básicamente lazy loading, solo que no para imágenes sino para partes enteras de la página web. Para las páginas con muchos elementos repetidos (piensa en Pinterest), el desplazamiento infinito puede acelerar considerablemente la carga inicial.
Para consideraciones específicas para dispositivos 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 la pantalla.
Independientemente del enfoque que tomes, verifica que funcione con usuarios reales. Configura Real User Monitoring para rastrear si tus cambios realmente mejoran el LCP y los Core Web Vitals generales en el campo (in the field).
I have done this before at your scale.
Complex platforms, large dev teams, legacy code. I join your team as a specialist, run the performance track, and hand it back in a state you can maintain.
Discuss Your Situation
