Carga diferida

TL;DR — La carga diferida le dice al navegador que retrase la descarga de imágenes y elementos incrustados hasta que estés a punto de desplazarte hasta ellos, de modo que la página cargue más rápido al principio. La forma fácil y sin código es añadir loading="lazy" a un <img> o <iframe>. La única regla que debes recordar: no apliques carga diferida a la imagen grande en la parte superior de la página — eso hace que la página se sienta más lenta, no más rápida.

Qué es la carga diferida

Normalmente, cuando un navegador abre una página, intenta descargar todo lo que hay en ella — cada imagen, cada mapa o video incrustado — de inmediato. En una página larga con muchas imágenes, eso es mucha descarga para contenido que quizás nunca te desplaces a ver.

La carga diferida soluciona eso. Retrasa la carga de imágenes y elementos incrustados fuera de pantalla hasta que estés a punto de desplazarte para verlos. La página te muestra rápidamente lo que hay en la parte superior, y el resto se carga a medida que avanzas. Menos datos al principio significa una primera impresión más rápida, además de ahorro de ancho de banda y batería — lo cual importa más en los teléfonos.

La forma fácil: el atributo loading

Antes necesitabas una biblioteca de JavaScript para hacer esto. Ya no. Los navegadores modernos lo tienen integrado. Solo tienes que añadir un atributo:

<img src="photo.jpg" loading="lazy" alt="…">

Eso es todo. Funciona en <img> y <iframe> (piensa en videos de YouTube incrustados, Google Maps, widgets sociales) en todos los navegadores principales, sin JavaScript.

El único error que debes evitar

No apliques carga diferida a la imagen grande en la parte superior de la página — la imagen principal, lo primero que la gente ve. La carga diferida le dice al navegador “esto puede esperar”, así que una imagen superior con carga diferida se carga más tarde de lo que debería, y la página se siente más lenta. La propia guía de Google es omitir la carga diferida para cualquier cosa que sea visible de inmediato cuando se abre la página.

En resumen: aplica carga diferida al contenido debajo del pliegue, y carga el contenido encima del pliegue normalmente.

¿Perjudica al SEO?

Por sí solo, no. Google puede indexar imágenes y contenido con carga diferida sin problema cuando se hace de la forma normal. El problema solo comienza cuando una página oculta contenido detrás de desplazamiento o clics — porque los motores de búsqueda no se desplazan ni hacen clic. Si tus imágenes solo usan loading="lazy", estás bien. ¿Quieres los detalles sobre cómo ve Google realmente esto y cómo comprobarlo? Cambia a la pestaña Avanzado.

TL;DR — La carga diferida retrasa imágenes e iframes fuera de pantalla hasta que se acercan al viewport, reduciendo el peso inicial de la página (ayuda al LCP) y el trabajo inicial del hilo principal (ayuda al INP). El atributo nativo loading="lazy" en <img>/<iframe> ha reemplazado a la mayoría de las bibliotecas de JavaScript; solo lazy y eager son valores significativos (auto está obsoleto). Los errores perjudiciales: aplicar carga diferida a la imagen LCP/por encima del pliegue (retrasa la misma métrica que persigues), y ocultar contenido detrás de desplazamiento/clic — lo cual Googlebot nunca activa porque no interactúa con la página. No es un factor de clasificación directo; el efecto se transmite a través de Core Web Vitals y la rastreabilidad. Verifica en la herramienta Inspección de URLs de Search Console que las URLs de las imágenes estén en el atributo src del HTML renderizado.

Qué hace realmente la carga diferida

La idea es simple: solo cargar recursos cuando los necesitas, en lugar de cargar todo a la vez. En una página con muchos medios, descargar cada imagen y elemento incrustado de antemano mantiene al navegador ocupado obteniendo cosas que el visitante quizás nunca se desplace a ver — quemando ancho de banda, memoria y batería para nada. Retrasar los que están fuera de pantalla permite que el contenido por encima del pliegue se pinte antes. Martin Splitt hizo exactamente este punto en el episodio de Search Off the Record «Desmitificando la carga diferida»: el objetivo es evitar trabajo que no produce nada, porque las imágenes no críticas que la página podría prescindir solo mantienen ocupado al navegador.

Esto se conecta con las Core Web Vitals que la mayoría persigue. Menos bytes compitiendo por la red desde el principio significa que el elemento de Largest Contentful Paint puede renderizarse antes. Para los iframes — anuncios, widgets sociales, secciones de comentarios, mapas — diferirlos también reduce el trabajo del hilo principal durante el inicio, lo cual es una victoria para Interaction to Next Paint, no solo para LCP. La propia guía de web.dev de Google presenta los iframes con carga diferida como una mejora de INP durante la carga de la página.

Carga diferida nativa vs. impulsada por JavaScript

Hace unos años, los navegadores ganaron un atributo nativo loading para imágenes e iframes, así que puedes delegar todo el trabajo al navegador en lugar de configurar una API de JavaScript. En mi guía de SEO para JavaScript en Ahrefs hago la misma observación: desde que escribí ese artículo por primera vez, la carga diferida ha pasado mayormente de estar impulsada por JavaScript a ser manejada por los navegadores. Todavía te encontrarás con configuraciones impulsadas por JS, y para imágenes suelen estar bien — lo que compruebo es si el contenido real (no solo imágenes) se está cargando de forma diferida, porque esas configuraciones son las que han causado que el contenido no se recoja correctamente.

La versión nativa:

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

Siempre establece width/height explícitos (o una relación de aspecto) en las imágenes con carga diferida para que el navegador reserve el espacio antes de que la imagen se cargue — ese es el mayor riesgo de cambio de diseño con imágenes diferidas. Las dimensiones reservadas no son una garantía absoluta de CLS, sin embargo: si el diseño circundante o un recorte responsivo aún cambian después de que la imagen se cargue, todavía puedes ver un cambio, así que confirma con un seguimiento real de cambio de diseño en lugar de asumir que las dimensiones fijas por sí solas lo resuelven.

La carga diferida y los iframes necesitan una distinción más: loading="lazy" en un <iframe> solo difiere cuándo ocurren la obtención y la creación del embed. No establece su title, comportamiento de enfoque, sandbox, política de allow/permisos, referrerpolicy, manejo de consentimiento o dimensiones por ti — esos aún necesitan su propia atención, y un embed puede seguir haciendo trabajo (scripts, píxeles de seguimiento, diseño) una vez que se vuelve elegible para cargar. Y no asumas que “debajo del pliegue” se comporta igual en todas partes: el contenido con display: none, diapositivas de carrusel fuera de pantalla, elementos transformados y contenedores de desplazamiento anidados pueden intersectar el viewport de manera diferente que un elemento simple debajo del pliegue, así que prueba el diseño real y los controles de navegación en lugar de asumir equivalencia.

Los valores del atributo loading

Solo dos valores importan hoy:

• loading="lazy" — difiere el recurso hasta que esté cerca del viewport.
• loading="eager" — cárgalo inmediatamente, el comportamiento predeterminado. Úsalo para ser explícito sobre las imágenes por encima del pliegue.

Puedes ver loading="auto" en artículos más antiguos — está obsoleto en Chrome, así que no lo uses. No hay necesidad; omitir el atributo ya te da el comportamiento predeterminado (eager).

¿Qué tan cerca es “cerca”? loading="lazy" es una sugerencia, no una garantía controlada por el autor — la especificación deja la decisión real de cerca del viewport al navegador. Chromium intenta obtener un recurso diferido lo suficientemente temprano para que esté listo cuando te desplaces hasta él, y la distancia de activación varía según el navegador, la velocidad de conexión y el tipo de recurso; no es un valor de píxel fijo en el que puedas confiar o reproducir entre navegadores o versiones. No publiques — ni confíes en — un número específico de “carga N píxeles antes del viewport”; trata la ventana de cerca del viewport como definida por la implementación y confirma el comportamiento real con un seguimiento de red en el navegador/conexión que te importa en lugar de asumir una constante.

La carga diferida nativa también funciona bien con imágenes responsivas: se aplica a la selección normal de src y srcset/sizes, por lo que no pierdes el comportamiento de imagen responsiva al añadir loading="lazy". Si en su lugar ocultas la URL real solo en un atributo data-* para que un script la intercambie más tarde, la carga ahora depende de ese script: prueba el HTML renderizado y qué sucede si el script falla (más sobre esto en las pestañas Scripts y Solución de problemas).

El error número 1: cargar de forma diferida la imagen LCP / la imagen visible sin desplazamiento

Este es el fallo que veo con más frecuencia, y todas las fuentes coinciden en ello. Si cargas de forma diferida la imagen principal (hero) —o cualquier imagen que probablemente sea el elemento LCP—, le has dicho al navegador que espere por el píxel más importante para la velocidad de carga percibida. El navegador tampoco puede cargar de forma diferida una imagen hasta que sabe dónde se ubicará en la página, por lo que las imágenes diferidas visibles sin desplazamiento tienden a cargarse más lentamente que las que se cargan de inmediato. Eso retrasa directamente el Largest Contentful Paint, la métrica que Google dice que debería resolverse dentro de los primeros 2,5 segundos de carga.

Splitt expresó claramente la otra cara en el episodio de SOTR: si no estás usando la carga diferida donde deberías, eso probablemente perjudicará algún aspecto de Core Web Vitals —muy probablemente el LCP—. Así que tiene un doble filo. La regla:

• Candidato probable u observado a LCP → carga inmediata (omite loading="lazy", o establece eager). Considera fetchpriority="high" en la imagen LCP.
• Debajo del pliegue → loading="lazy".

No todas las imágenes visibles sin desplazamiento son el candidato a LCP: identifica la real (un trace de Performance o PageSpeed Insights la nombrará) y verifica su tiempo de solicitud en lugar de tratar todas las imágenes de la primera pantalla por igual. Y estas son pistas separadas, no una sola configuración: loading="eager" (u omitir loading) solo significa que el navegador no diferirá el descubrimiento del recurso —no eleva por sí mismo la prioridad de búsqueda—. fetchpriority es una pista distinta y consultiva además de eso. Apilar un <link rel="preload"> con loading="lazy" en el mismo recurso envía al navegador una intención conflictiva, así que verifica el waterfall de red real en lugar de asumir que la combinación hace lo que esperas.

El anti-patrón general es activar la carga diferida para todas las imágenes del sitio —un valor predeterminado común en los CMS—. Como señaló Splitt, si cada imagen se carga de forma diferida, entonces las imágenes que son (o deberían ser) visibles de inmediato también se cargan de forma diferida, que es exactamente el caso que quieres evitar.

Cómo renderiza Googlebot el contenido con carga diferida

Esta es la realidad del rastreo que confunde a la gente: Googlebot no se desplaza y no hace clic. Renderiza tu página con un navegador sin interfaz, pero no simula que un usuario interactúe con ella. Google lo afirma directamente: sus métodos recomendados de carga diferida deliberadamente no dependen de acciones del usuario como desplazarse o hacer clic, porque Google Search no interactúa con tu página.

Por eso el cómo de tu implementación importa. El documento de Google enumera tres implementaciones que considera seguras: la carga diferida integrada del navegador para imágenes e iframes, la API IntersectionObserver (con un polyfill) o una biblioteca de JavaScript que carga datos a medida que entran en el viewport. Las tres se basan en la intersección con el viewport —no en un evento de desplazamiento o clic que Googlebot nunca disparará—.

El patrón de alto riesgo es una biblioteca de lazy loading de JS personalizada o de terceros. Si la biblioteca se comporta mal y la URL de la imagen nunca llega al atributo src, Google simplemente no recogerá esa imagen — Splitt describió exactamente este modo de fallo en el episodio de SOTR. No hay nada que indexar si la URL no está ahí. Esto es lo mismo que señalo en mi guía de SEO para JavaScript: el lazy loading de imágenes suele estar bien, pero el contenido cargado de forma diferida es donde se cuelan los problemas de indexación, y la solución es comprobar qué renderiza realmente Google.

El scroll infinito es un problema diferente

No confundas el lazy loading básico de imágenes/iframes con el scroll infinito o la carga paginada. Diferir imágenes es una cosa; cargar nuevos fragmentos de contenido mientras el usuario se desplaza es otra, y necesita su propia arquitectura. La guía de Google: dale a cada fragmento una URL persistente y única, mantén el contenido estable por URL (usa números de página absolutos como ?page=12, no valores relativos como ?date=yesterday), y actualiza la URL mostrada con la API History a medida que cada fragmento se convierte en el contenido visible principal para que pueda actualizarse, compartirse y enlazarse. Si omites eso, el contenido más profundo detrás de un scroll infinito puede que nunca se rastree o indexe de forma fiable.

Cómo probarlo

La ruta de verificación es la misma en el documento de Google y en mi propia metodología: usa la Herramienta de inspección de URLs de Search Console y mira el HTML renderizado. Si tus URLs de imágenes (o vídeos) aparecen en el atributo src de los elementos <img>/<video> en ese HTML renderizado, tu configuración funciona. Google lo dice claramente — comprueba el HTML renderizado para asegurarte de que tu contenido está en él: “Check the rendered HTML to make sure your content is in the rendered HTML” (traducción) «Comprueba el HTML renderizado para asegurarte de que tu contenido está en el HTML renderizado». Si la URL falta en src, ese es tu problema, y normalmente apunta a un disparador de scroll/clic o a una biblioteca rota.

Para una cuadrícula de productos con lazy loading, ve más allá de esta comprobación de presencia. Ejecuta la matriz de pruebas de SEO para scroll infinito con viewports estándar y altos, navegación nueva y redimensionado tras la carga, ejecuciones sin acción y con scroll incremental, recuentos de enlaces de producto únicos e inspección del árbol de accesibilidad. Redimensionar una página inicializada no equivale a navegar con el tamaño de viewport final porque los observadores y los cálculos por lotes pueden registrarse solo durante el inicio. Evidence for this claim Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Scope: Google Search guidance for JavaScript-driven lazy loading. Confidence: high · Verified: 2026-07-14 Google Search Central: Lazy-load content

También puedes apoyarte en tus herramientas de rendimiento web: PageSpeed Insights señala las imágenes fuera de pantalla que deberías diferir. En mi guía de PageSpeed Insights en Ahrefs señalo que la auditoría de “diferir elementos fuera de pantalla” te dice que apliques lazy loading a las imágenes — una forma práctica de conectar el diagnóstico que ya ejecutas con la solución.

Honestidad sobre la señal de ranking

Sé claro sobre qué es y qué no es el lazy loading. Usarlo no es un factor de ranking directo, y no usarlo no es una penalización. La conexión con el ranking es indirecta: pasa a través de Core Web Vitals (principalmente LCP, a veces INP para iframes) y a través de la rastreabilidad, si una mala implementación oculta contenido. Splitt caracterizó el efecto en el ranking a través de Core Web Vitals como un factor diminuto y mínimo en la mayoría de los casos. Así que optimiza el lazy loading para la experiencia de carga de tus usuarios y para una indexación limpia — no porque esperes un aumento de ranking por el atributo en sí.

Dónde encaja

El lazy loading es una palanca más en el conjunto de herramientas más amplio de rendimiento web. Se combina con sugerencias de recursos (preload/preconnect para los recursos que sí quieres temprano), la estrategia de carga de fuentes, el almacenamiento en caché y una CDN — y se evalúa, en última instancia, a través de Core Web Vitals. Si aciertas con la división entre lo que está por encima y por debajo del pliegue, es una de las victorias más baratas disponibles.

Resumen de IA

Una versión condensada de la versión avanzada:

• Lazy loading difiere imágenes y iframes fuera de pantalla hasta que se acercan al viewport, reduciendo el peso inicial de la página y el trabajo de arranque. La forma nativa, sin JS, es loading="lazy" en <img> y <iframe>; ha reemplazado en gran medida a las bibliotecas JS. Es una pista del navegador, no una distancia o tiempo garantizado — el punto de activación varía según el navegador, la conexión y el tipo de recurso, así que no confíes en un número fijo de píxeles.
• Valores: solo lazy y eager importan. auto está obsoleto en Chrome.
• Vínculo con Core Web Vitals: menos bytes iniciales ayudan al LCP; diferir iframes reduce el trabajo del hilo principal al inicio, ayudando al INP. Establece width/height para que las imágenes diferidas no causen CLS — aunque las dimensiones reservadas por sí solas no garantizan cero desplazamiento si el diseño circundante aún cambia.
• Error #1: aplicar lazy loading a la imagen probable/observada de LCP, no solo a cualquier imagen sobre el pliegue. Retrasa la Largest Contentful Paint, que Google dice que debería resolverse en 2,5 s. eager/omitir loading solo afecta el descubrimiento — no eleva por sí mismo la prioridad de descarga; fetchpriority es una pista separada, y apilar preload con loading="lazy" en el mismo recurso entra en conflicto. El lazy loading generalizado en todo el sitio es el anti-patrón común de los CMS.
• Los iframes tienen su propio contrato: loading="lazy" solo difiere el momento de descarga/creación — title, sandbox, política de permisos, política de referrer, consentimiento y dimensiones aún deben establecerse de forma independiente, y los diseños ocultos/de carrusel/transformados pueden intersectar el viewport de manera diferente a un elemento simple bajo el pliegue.
• Googlebot no se desplaza ni hace clic. Cualquier contenido bloqueado detrás de eventos de desplazamiento/clic puede pasar desapercibido. Los métodos seguros de Google — lazy loading nativo, IntersectionObserver o una biblioteca JS bien comportada — se basan todos en la intersección con el viewport.
• Mayor riesgo: bibliotecas de lazy loading JS personalizadas/de terceros. Si la URL nunca llega a src, Google no indexará la imagen (según Martin Splitt).
• El scroll infinito es distinto: necesita URLs paginadas únicas + History API.
• Verifica en URL Inspection de Search Console → HTML renderizado → URLs de imágenes presentes en el atributo src.
• No es un factor de ranking directo. El efecto es indirecto, a través de Core Web Vitals y la rastreabilidad, y Splitt llamó al efecto de ranking de Core Web Vitals diminuto.

Documentación oficial

Orientación de fuentes primarias de los motores de búsqueda y de web.dev de Google.

Google — Search Central

• Corregir contenido con lazy loading — el documento definitivo: métodos de implementación seguros, la regla de “Google no interactúa con tu página”, los requisitos de scroll infinito/carga paginada y cómo verificar en el HTML renderizado.
• Entender los conceptos básicos de SEO en JavaScript — recomienda el lazy loading de imágenes como una práctica recomendada de ancho de banda/rendimiento y enlaza a la guía dedicada.
• Core Web Vitals — por qué aplicar lazy loading al elemento LCP es contraproducente (el objetivo de LCP es 2,5 s).

Google — web.dev (Aprende rendimiento)

• Cargar imágenes y elementos <iframe> con lazy loading — cuándo diferir y el beneficio de INP de los iframes con lazy loading.
• Lazy loading de imágenes a nivel de navegador para la web — el atributo nativo y por qué no aplicar lazy loading a imágenes en el viewport/LCP.
• ¡Es hora de aplicar lazy loading a iframes fuera de pantalla! — el caso específico de iframes (anuncios, widgets, mapas).
• Lazy loading a nivel de navegador para CMS — orientación para plataformas CMS.

Google — podcast

• Episodio 98 del pódcast de Google: «Desmitificando la carga diferida» (21 ago 2025) — John Mueller y Martin Splitt hablan sobre lazy loading, renderizado, indexación y Core Web Vitals. También está indexado en la página de Search Off the Record de Google.

Referencia para desarrolladores (no específica de SEO, pero autorizada sobre la API)

• MDN — Lazy loading (guía de rendimiento)
• MDN — HTMLImageElement: propiedad loading
• caniuse — Lazy loading mediante atributo para imágenes e iframes

Bing / Microsoft

• Bing no publica ningún documento dedicado al lazy loading. Sus directrices generales para webmasters cubren el rastreo y el renderizado de JS en términos generales. Bingbot renderiza con un navegador headless basado en Chromium y, al igual que Googlebot, no se desplaza ni hace clic, por lo que el mismo enfoque nativo de loading="lazy" / IntersectionObserver que satisface a Google debería satisfacer a Bing. Ese último punto es una inferencia del comportamiento general de renderizado de Bingbot, no una declaración de Bing con fuente sobre el lazy loading; trátalo en consecuencia.

Citas de la fuente

Declaraciones oficiales de la documentación de Google. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google — Search Central, “Fix Lazy-Loaded Website Content”

• “Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (traducción) «Diferir la carga de contenido no crítico o no visible, también conocido comúnmente como ‘lazy-loading’, es una práctica recomendada común de rendimiento y experiencia de usuario.» Ir a la cita
• “However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (traducción) «Sin embargo, si no se implementa correctamente, esta técnica puede ocultar contenido a Google sin querer. Este documento explica cómo asegurarse de que Google pueda rastrear e indexar contenido con lazy loading.» Ir a la cita
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (traducción) «Los métodos mencionados no dependen de acciones del usuario, como desplazarse o hacer clic, para cargar contenido, lo cual es importante porque Google Search no interactúa con tu página.» Ir a la cita
• “Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (traducción) «No añadas lazy loading a contenido que probablemente sea visible de inmediato cuando un usuario abre una página. Eso podría hacer que el contenido tarde más en cargarse y aparecer en el navegador, lo cual será muy perceptible para el usuario.» Ir a la cita
• “Give each chunk its own persistent, unique URL.” — sobre el desplazamiento infinito / carga paginada. (traducción) «Dale a cada fragmento su propia URL persistente y única.» Ir a la cita

Lista de verificación de lazy loading

Ejecuta esto antes de publicar un cambio de lazy loading:

• La imagen hero / LCP NO se carga de forma diferida — se carga de forma inmediata (omite loading="lazy"), idealmente con fetchpriority="high".
• loading="lazy" se aplica a imágenes e iframes que están debajo del pliegue.
• Las imágenes diferidas tienen width/height (o aspect-ratio) explícitos para que no provoquen cambios de diseño (CLS) cuando se cargan.
• Ningún contenido está bloqueado detrás de un evento de desplazamiento o clic — Googlebot no los activará. Usa carga diferida nativa o IntersectionObserver en su lugar.
• No estás usando el valor obsoleto loading="auto" — solo lazy/eager.
• Los iframes fuera de pantalla (inserciones, anuncios, mapas, widgets) usan loading="lazy" para reducir el trabajo del hilo principal al inicio.
• Los iframes con carga diferida siguen teniendo su propio title, sandbox, allow/política de permisos, referrerpolicy y dimensiones explícitas — loading="lazy" solo difiere el momento de la descarga, no esos atributos.
• Verificado en Inspección de URLs de Search Console → HTML renderizado que las URLs de imágenes/videos aparecen en el atributo src.
• Si usas una biblioteca de carga diferida de terceros con JS, confirmado que el src sigue apareciendo en el HTML renderizado.
• Para scroll infinito, cada fragmento tiene una URL paginada única, persistente y la API History actualiza la URL mostrada.
• Se abordan las advertencias de PageSpeed Insights sobre “diferir imágenes fuera de pantalla”.

Antipatrones de carga diferida (mitos y errores)

Cada uno de estos es una creencia o hábito común, por qué es incorrecto y qué hacer en su lugar.

“La carga diferida siempre es buena, así que aplícala a cada imagen.” Por qué es incorrecto: la carga diferida en todo el sitio también afecta a tu imagen hero/LCP, lo que retrasa la Largest Contentful Paint — lo contrario de la mejora de velocidad que buscabas. Hazlo en su lugar: carga de forma diferida solo lo que está debajo del pliegue; carga las imágenes sobre el pliegue de forma inmediata.

“Google no indexa el contenido con carga diferida en absoluto.” Por qué es incorrecto: Google rastrea e indexa el contenido con carga diferida sin problemas cuando se hace con carga diferida nativa, IntersectionObserver o una biblioteca bien comportada. El riesgo es específico de configuraciones bloqueadas por desplazamiento/clic o rotas — según las propias palabras de Google, el problema ocurre cuando está “not implemented correctly.” (traducción) «no implementado correctamente». Hazlo en su lugar: usa un método de intersección con el viewport y verifica en el HTML renderizado.

“loading='auto' es un buen valor predeterminado.” Por qué es incorrecto: auto está obsoleto en Chrome; recomendarlo es un consejo desactualizado. Hazlo en su lugar: usa lazy para recursos fuera de pantalla, eager (o nada) para el resto.

“La carga diferida y el scroll infinito son la misma solución.” Por qué es incorrecto: son distintos. El scroll infinito además necesita URLs paginadas únicas y actualizaciones de la API History, o el contenido más profundo puede no rastrearse de forma fiable. Hazlo en su lugar: trata la carga paginada/infinita como su propia arquitectura con URLs por fragmento.

“loading='lazy' funciona en cualquier elemento.” Por qué es incorrecto: está especificado para <img> y <iframe>. El soporte para otros elementos no forma parte de la especificación principal de la misma manera. Hazlo en su lugar: usa el atributo en imágenes e iframes; maneja otros medios con una técnica adecuada (para video, una imagen de póster que carga el video al entrar en el viewport).

“La carga diferida perjudica el SEO.” Por qué es incorrecto: la carga diferida en sí no es una penalización. El efecto relevante para el ranking pasa por Core Web Vitals y es pequeño; la mala implementación es lo que perjudica, no la técnica. Hazlo en su lugar: impleméntala correctamente, excluye la imagen LCP y verifica lo que se renderiza.

Hoja de referencia de carga diferida

El atributo loading

Qué elementos lo soportan

• <img> — sí
• <iframe> — sí
• Otros elementos (video/audio) — no forman parte de la especificación principal de la misma manera; usa un patrón de imagen de póster + carga al ver para video.

Arriba vs. debajo del pliegue

• Arriba del pliegue / probable LCP → eager (nunca lazy). Añade fetchpriority="high" a la imagen LCP.
• Debajo del pliegue → lazy.

Impacto en Core Web Vitals

• Diferir imágenes fuera de pantalla → ayuda al LCP (menos bytes compiten al inicio).
• Diferir iframes fuera de pantalla → ayuda al INP (menos trabajo del hilo principal al inicio).
• Falta de width/height en imágenes lazy → puede dañar el CLS (desplazamiento de diseño al cargar).

Reglas que le importan a Googlebot

• Googlebot no se desplaza ni hace clic — nada de contenido bloqueado por scroll o clic.
• Métodos seguros: loading="lazy" nativo, IntersectionObserver, librería JS bien comportada.
• Verifica: URL Inspection → HTML renderizado → URL de la imagen en el atributo src.
• El scroll infinito ≠ lazy loading de imágenes — necesita URLs paginadas únicas + History API.

Antes / después

Correcciones concretas, planteadas como las encontrarías en una auditoría.

1. La imagen hero se carga con lazy (LCP retrasado)

Antes:

<img src="hero.jpg" loading="lazy" alt="Product hero">

Después:

<img src="hero.jpg" fetchpriority="high" alt="Product hero">

Por qué: el hero es el elemento LCP. Cargarlo con eager (y priorizar la descarga) permite que se pinte antes. Cargarlo con lazy hace lo contrario.

2. Lazy loading generalizado en todo el sitio desde un valor predeterminado del CMS

Antes: cada <img> de la plantilla lleva loading="lazy", incluido el logotipo del encabezado y la imagen destacada de la parte superior de la página. Después: la plantilla carga con eager las imágenes arriba del pliegue y solo aplica loading="lazy" a las imágenes renderizadas debajo del viewport inicial. Por qué: el lazy loading generalizado atrapa las imágenes visibles de inmediato, retrasando lo que el usuario (y el LCP) ve primero.

3. Carga de embeds fuera de pantalla al cargar la página

Antes:

<iframe src="https://maps.google.com/…" title="Store map"></iframe>

Después:

<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>

Por qué: el mapa está debajo del pliegue. Diferirlo elimina su costo de inicio y ayuda al INP, ya que los embeds hacen trabajo en el hilo principal mientras la página se carga.

4. El lazy loading con JS personalizado deja src vacío para Googlebot

Antes: una librería guarda la URL real en data-src y la intercambia en src en un evento de scroll — que Googlebot nunca dispara, así que el HTML renderizado muestra un src vacío o con placeholder. Después: usa loading="lazy" nativo (URL real en src desde el inicio), o una librería basada en IntersectionObserver, y luego confirma en URL Inspection que la URL está presente en el src renderizado. Por qué: si la URL no está en src en el HTML renderizado, Google no puede captar la imagen.

Encuentra imágenes que deberían (o no) cargarse con lazy

Un fragmento de la consola de DevTools que puedes pegar en cualquier página para auditar el atributo loading. Enumera las imágenes con su valor de loading y si están actualmente en el viewport — para que puedas detectar una imagen arriba del pliegue marcada como lazy, o una debajo del pliegue que no lo esté.

Chrome DevTools Console

// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
  const r = img.getBoundingClientRect();
  const inView = r.top < innerHeight && r.bottom > 0;
  const loading = img.getAttribute('loading') || '(none/eager)';
  // Flag the two mistakes: in-view + lazy, or off-view + not lazy
  const flag =
    (inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
    (!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
  console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});

Busca en tu código patrones de lazy-load arriesgados

Revisa tus plantillas/salida de build para detectar el valor obsoleto auto y el lazy loading con JS estilo data-src (que puede dejar src vacío para Googlebot).

macOS / Linux (bash)

# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src

# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./src

Windows (PowerShell)

# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'

# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='

Recuerda: data-src no es automáticamente un problema — es una señal para confirmar que la URL real termina en el src renderizado, lo cual verificas en URL Inspection de Search Console.

La imagen hero empieza a cargar más tarde tras activar el lazy loading

Síntoma: el LCP se vuelve más lento y la solicitud del hero comienza tarde en el waterfall.

Causa probable: una regla global del CMS añadió loading="lazy" a una imagen arriba del pliegue o LCP.

Corrección y confirmación: Elimina el atributo lazy de esa imagen, opcionalmente añade fetchpriority="high", y confirma que su solicitud comienza antes en un seguimiento coincidente.

La imagen diferida aparece pero desplaza la página

Síntoma: El contenido salta cuando una imagen diferida entra en el viewport.

Causa probable: La imagen no tiene dimensiones explícitas ni una relación de aspecto reservada.

Corrección y confirmación: Añade los atributos width y height o reserva la misma relación de aspecto en CSS. Recarga con las regiones de cambio de diseño habilitadas y verifica que la imagen ya no mueve el contenido circundante.

Google no ve el contenido diferido

Síntoma: Una inspección renderizada carece de la URL de la imagen o del contenido que aparece después de que un humano se desplaza.

Causa probable: Un controlador de desplazamiento o clic nunca se ejecuta para Googlebot, o una biblioteca de carga diferida deja la URL real en data-src en lugar del src renderizado.

Corrección y confirmación: Usa carga diferida nativa o una implementación basada en IntersectionObserver, luego inspecciona el HTML renderizado y confirma que la URL final y el contenido están presentes sin interacción.

El embed fuera de pantalla aún se carga inmediatamente

Síntoma: Un iframe debajo del pliegue aparece en el waterfall inicial a pesar de un cambio de carga diferida.

Causa probable: El atributo está ausente en el iframe desplegado, un contenedor crea el iframe de forma eager, o el embed está lo suficientemente cerca del viewport para el umbral de carga del navegador.

Corrección y confirmación: Inspecciona el DOM en vivo y el iniciador de la solicitud, prueba en una página larga con caché fría, y verifica que la solicitud se difiere hasta el umbral cercano al viewport del navegador.

Herramientas para implementación y prueba

• Paneles Elements y Network de Chrome DevTools: confirma el atributo loading desplegado, identifica qué script creó un iframe, y compara los tiempos de inicio de las solicitudes antes y después de un cambio.
• Panel Performance de Chrome DevTools: graba una carga y verifica que diferir un embed reduce el trabajo del hilo principal al inicio sin retrasar la imagen LCP.
• PageSpeed Insights: usa el diagnóstico de imagen fuera de pantalla como lista inicial, luego separa los candidatos verdaderamente debajo del pliegue del hero u otro contenido inmediato.
• Inspección de URLs de Search Console: inspecciona el HTML renderizado y verifica que las URLs de imágenes diferidas terminen en src y que el contenido con carga diferida exista sin un desplazamiento o clic.
• El viewport del navegador y el filmstrip: prueba más de un tamaño de viewport. Una imagen debajo del pliegue en escritorio puede estar por encima del pliegue en un dispositivo más pequeño o con otra forma.

Diferimiento de imágenes debajo del pliegue

Prueba a ejecutar: Graba un seguimiento de Network con carga fría antes y después de añadir carga diferida nativa a una imagen muy por debajo del viewport inicial.

Resultado esperado: La solicitud de la imagen está ausente del waterfall crítico inicial y comienza cuando el viewport se acerca a ella.

Interpretación del fallo: El marcado desplegado carece del atributo, JavaScript crea o obtiene la imagen de forma eager, o la imagen de prueba está dentro del umbral cercano al viewport del navegador.

Ventana de monitoreo: Comprueba inmediatamente después del despliegue en tamaños de viewport representativos de móvil y escritorio.

Disparador de reversión: Revierte si una imagen visible en la carga inicial se difiere o si la imagen falla rutinariamente en aparecer antes de que el usuario la alcance.

Exclusión de la imagen LCP

Prueba a ejecutar: Compara seguimientos de rendimiento coincidentes y waterfalls de solicitudes para la imagen LCP de la página después de eliminar la carga diferida general.

Resultado esperado: La imagen LCP se carga de forma eager, su solicitud comienza antes, y LCP no retrocede.

Interpretación del fallo: Otra plantilla o capa de optimización vuelve a añadir el atributo, o el descubrimiento aún se retrasa por CSS, JavaScript o marcado.

Ventana de monitoreo: Comprueba ejecuciones de laboratorio repetidas inmediatamente, luego observa el LCP de campo durante la siguiente ventana de informes.

Disparador de reversión: Revierte el despliegue circundante si el cambio retrasa otros recursos críticos lo suficiente como para causar una regresión de LCP repetible.

Visibilidad del contenido renderizado

Prueba a ejecutar: Usa la Inspección de URLs para ver el HTML renderizado sin interactuar con la página y busca la URL de la imagen diferida y el contenido asociado.

Resultado esperado: La URL final aparece en src y el contenido importante está presente en el HTML renderizado.

Interpretación del fallo: La implementación depende de un evento de desplazamiento o clic, o el script de carga diferida falló durante el renderizado.

Ventana de monitoreo: Prueba cada plantilla afectada después del lanzamiento y después de cambiar la biblioteca de carga diferida o el pipeline de imágenes del CMS.

Disparador de reversión: Revierte si el contenido indexable o las URLs de imágenes desaparecen de la salida renderizada.

Ponte a prueba: Carga diferida

Cinco preguntas rápidas sobre diferir imágenes e iframes sin perjudicar las Core Web Vitals ni la indexación. Elige una respuesta para cada una y luego comprueba.

Recursos que valen tu tiempo

Mis escritos relacionados

• Problemas de SEO con JavaScript y buenas prácticas — donde cubro el cambio de la carga diferida impulsada por JS a la nativa del navegador, y por qué el contenido con carga diferida (no solo las imágenes) es el riesgo de indexación.
• Google PageSpeed Insights para profesionales del SEO y desarrolladores — conecta la auditoría de “diferir imágenes fuera de pantalla” con la carga diferida, además del resto del informe de PSI.
• Guía de SEO técnico para principiantes — donde el rendimiento y el renderizado encajan en el panorama general.

De la industria

• Corregir el contenido de sitios web con carga diferida (Google Search Central) — el documento definitivo de implementación y pruebas.
• Carga diferida de imágenes a nivel de navegador para la web (web.dev) — el atributo nativo y la advertencia de LCP, directamente del equipo de rendimiento de Google.
• ¡Es hora de aplicar carga diferida a los iframes fuera de pantalla! (web.dev) — el caso de los iframes y su beneficio de inicio/INP.
• Carga diferida desmitificada — Search Off the Record, ep. 98 (Google) — el episodio completo de Mueller y Splitt sobre carga diferida, renderizado, indexación y Core Web Vitals.
• Carga diferida explicada: acelera tu sitio y mejora la experiencia de usuario (Search Engine Land) — una guía industrial exhaustiva con notas específicas para CMS.
• Carga diferida (guía de rendimiento) (MDN) — la vista de referencia para desarrolladores de la API.
• Introducción a la carga diferida para mejorar el rastreo y la indexación (Oncrawl) — el ángulo de rastreo/indexación en profundidad.

Registro de cambios