Qué hace realmente la carga diferida con tu Largest Contentful Paint

La carga diferida es una decisión de programación, no un hechizo de velocidad

La carga diferida suele describirse como una mejora de rendimiento, lo cual es cierto del mismo modo que no hacer una maleta reduce el peso. Ayuda porque el navegador hace menos trabajo al principio.

Esa distinción importa para Largest Contentful Paint, normalmente abreviado como LCP. LCP mide cuándo se renderiza el elemento significativo más grande dentro del viewport. En muchas páginas, ese elemento es una imagen hero. En otras, es un encabezado grande, una imagen de póster, una foto de producto o un bloque de contenido.

La carga diferida cambia cuándo se solicitan los recursos. No hace que una imagen se decodifique más rápido, que un servidor responda más rápido ni que una fuente se renderice antes. Si aplicas carga diferida al elemento equivocado, especialmente al elemento que se convierte en LCP, le estás diciendo al navegador que espere antes de descargar precisamente aquello que debe mostrar para aprobar Core Web Vitals.

Por eso la carga diferida se usa demasiado y se entiende demasiado poco.

Qué hace el navegador cuando aplicas carga diferida a una imagen

La carga diferida nativa de imágenes suele añadirse así:

<img src='hero.jpg' loading='lazy' alt='...'>

Con loading='lazy', el navegador puede diferir la descarga de la imagen hasta que considere que probablemente será necesaria. En la práctica, los navegadores usan la distancia al viewport, las condiciones de red, las dimensiones de la imagen y otras heurísticas. Las reglas exactas son detalles de implementación y pueden cambiar.

Con loading='eager', o sin atributo lazy en la mayoría de los casos, el navegador trata la imagen como parte del proceso normal de carga. Aun así tiene que priorizar entre CSS, JavaScript, fuentes, imágenes y otras solicitudes, pero la imagen se puede descubrir inmediatamente.

Esto significa que la carga diferida afecta principalmente a tres fases:

• Descubrimiento: cuándo el navegador detecta el recurso.
• Inicio de la solicitud: cuándo empieza la descarga por red.
• Tiempo de renderizado: cuándo el recurso finalmente puede decodificarse y pintarse.

Para LCP, la fase peligrosa es el inicio de la solicitud. Si la solicitud de la imagen de LCP empieza tarde, todo lo que viene después también se retrasa.

La regla simple: nunca apliques carga diferida al candidato a LCP

Si una imagen es visible en el viewport inicial y probablemente sea el elemento de contenido más grande, no la cargues de forma diferida.

Esto incluye:

• imágenes hero
• fotos principales de producto por encima del pliegue
• imágenes destacadas grandes de artículos
• imágenes grandes tipo fondo implementadas como <img>
• imágenes de póster de video cuando el póster es el elemento visual principal

El navegador no puede renderizar la imagen de LCP hasta que se haya solicitado, transferido, decodificado y pintado. La carga diferida introduce incertidumbre antes del primer paso. Incluso un pequeño retraso puede bastar para mover LCP de aceptable a deficiente en una conexión más lenta.

Un patrón de fallo común se ve así:

1. El servidor envía HTML.
2. El navegador analiza una imagen por encima del pliegue.
3. La imagen tiene loading='lazy'.
4. El navegador espera porque la heurística de carga diferida dice que puede hacerlo.
5. CSS y JavaScript siguen cargando.
6. La solicitud de la imagen empieza más tarde de lo que debería.
7. LCP llega tarde, aunque el archivo de imagen en sí esté razonablemente optimizado.

Esto es frustrante porque la página puede parecer correcta en una revisión de código. El problema no es solo el tamaño del archivo. Es la prioridad.

Si estás leyendo resultados de laboratorio e intentando averiguar si LCP es realmente el problema, nuestra guía para leer un informe de Lighthouse sin entrar en pánico es intencionalmente práctica: separa los datos de campo, las pistas de laboratorio y las correcciones antes de empezar a cambiar código. (Nota: si tu enrutamiento distingue entre mayúsculas y minúsculas, usa la URL exacta de tu CMS.)

Corrección: usa la URL interna real

La URL correcta del artículo de Wux es Cómo leer un informe de Lighthouse sin entrar en pánico. La idea se mantiene: identifica el elemento de LCP antes de cambiar el comportamiento de carga.

Cuándo la carga diferida puede mejorar LCP

La carga diferida puede mejorar LCP indirectamente cuando mantiene recursos no críticos fuera del camino del navegador.

Imagina una página de producto con una imagen hero del producto en la parte superior y un carrusel de doce imágenes de recomendaciones por debajo del pliegue. Si las trece imágenes se cargan de forma eager, el navegador puede gastar ancho de banda y ranuras de conexión en imágenes que el usuario aún no puede ver. En una red limitada, eso puede competir con la imagen hero, CSS o los archivos de fuentes.

Aplicar carga diferida a las imágenes del carrusel por debajo del pliegue puede ayudar a que la imagen de LCP cargue antes porque hay menos solicitudes no críticas compitiendo durante la carga inicial de la página.

Este es el caso de rendimiento legítimo para la carga diferida:

• carga de forma eager el candidato a LCP por encima del pliegue
• carga de forma diferida las imágenes por debajo del viewport inicial
• evita scripts pesados que inyecten imágenes importantes tarde
• conserva las dimensiones de imagen en el HTML para evitar desplazamientos de diseño

La carga diferida no es una optimización de LCP por sí sola. Es una herramienta de priorización de recursos. Ayuda cuando protege la ruta crítica.

El mejor patrón para imágenes de LCP

Para una imagen de LCP por encima del pliegue, el objetivo es que el navegador la descubra pronto, la solicite pronto y la renderice sin inestabilidad de diseño.

Una base sólida se ve así:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Las partes importantes no son decorativas:

• loading='eager' evita el retraso de la carga diferida.
• fetchpriority='high' le indica al navegador que esta imagen importa.
• width y height reservan espacio y reducen el desplazamiento de diseño.
• srcset y sizes evitan descargas sobredimensionadas.
• Un formato moderno puede reducir el tiempo de transferencia cuando se usa con cuidado.

Si todavía sirves un único JPEG grande a todas las pantallas, el formato de imagen y el dimensionamiento responsive pueden importar más que el atributo de carga diferida. Para un árbol de decisión práctico, consulta cuándo AVIF supera a WebP y cuándo no.

Las imágenes de fondo requieren especial cuidado

Las imágenes de fondo CSS no se descubren tan pronto como las imágenes HTML normales. El navegador debe descargar y analizar el CSS antes de saber que existen. Si tu elemento de LCP es una imagen de fondo CSS, ya has hecho que el descubrimiento sea más difícil.

Eso no significa que las imágenes de fondo estén prohibidas. Significa que debes usarlas deliberadamente.

Para imágenes decorativas, los fondos CSS están bien. Para imágenes hero significativas, un elemento <img> o <picture> suele ser mejor porque es visible para el parser HTML, admite texto alt y funciona bien con atributos de imagen responsive.

Si debes usar un fondo CSS para una imagen de LCP, considera precargarla:

<link rel='preload' as='image' href='/images/hero.avif'>

La precarga tampoco es una varita mágica. Precargar demasiadas imágenes crea el mismo problema de prioridad con otro disfraz. Úsala para la única imagen que realmente importa, no para cada imagen del sistema de diseño.

La carga diferida con JavaScript a menudo empeora las cosas

Antes de que la carga diferida nativa estuviera ampliamente soportada, muchos sitios usaban bibliotecas JavaScript que intercambiaban data-src por src después de la carga de la página o después de que se activara un intersection observer. Algunos todavía lo hacen.

Esto puede ser razonable para páginas de artículos largas o galerías con muchas imágenes. Es una mala elección para contenido por encima del pliegue.

El escáner de precarga del navegador es rápido, pero no puede solicitar una imagen cuya URL está oculta en un atributo personalizado hasta que JavaScript se ejecuta. Si tu imagen hero empieza como data-src='hero.jpg', has retrasado el descubrimiento detrás de la descarga, el análisis, la ejecución del script y la hidratación del framework.

Es un mal intercambio para LCP. Coloca las URL de imágenes críticas en HTML real. Deja que el navegador haga su trabajo.

LCP no siempre es un problema de imágenes

En algunas páginas, el elemento de LCP es texto. En ese caso, la carga diferida de imágenes puede tener poco efecto directo. Tu cuello de botella puede ser CSS que bloquea el renderizado, una respuesta lenta del servidor, renderizado del lado del cliente o fuentes web.

Vale la pena mencionar las fuentes porque son una causa oculta frecuente de renderizado tardío de texto. Un encabezado grande puede convertirse en LCP, y el comportamiento de carga de fuentes puede retrasar o alterar cuándo se pinta ese encabezado. Si tu trabajo con imágenes no mueve la métrica, inspecciona directamente el elemento de LCP en lugar de asumir. Nuestro artículo sobre las fuentes web como mejora de rendimiento cubre las correcciones aburridas que suelen funcionar: menos pesos, formatos modernos, fallbacks sensatos.

Cómo probar cambios de carga diferida sin engañarte

No pruebes mirando fijamente tu página con el Wi-Fi de la oficina. Necesitas ver los tiempos de las solicitudes.

Usa este flujo de trabajo:

1. Abre Chrome DevTools y graba una traza de Performance.
2. Activa la limitación de red, como Fast 4G o Slow 4G.
3. Recarga la página con la caché desactivada.
4. Encuentra el marcador de LCP.
5. Identifica el elemento de LCP.
6. En el panel Network, comprueba cuándo empezó a cargarse ese recurso.

Si el recurso de LCP empieza tarde, pregunta por qué:

• ¿Se cargó de forma diferida?
• ¿Lo inyectó JavaScript?
• ¿Estaba oculto en CSS?
• ¿Fue despriorizado detrás de otras imágenes?
• ¿El servidor tardó en responder?

Luego haz un solo cambio y vuelve a probar. El trabajo de rendimiento se vuelve confuso cuando los equipos cambian el formato de imagen, la carga diferida, la precarga, los bundles de JavaScript y la configuración del CDN en el mismo despliegue. Puede que mejores la página, pero no sabrás qué cambio importó.

Los datos de campo también importan. Las herramientas de laboratorio son útiles para el diagnóstico, pero LCP varía según el dispositivo, la red, el viewport, el estado de la caché y la geografía. Usa monitoreo de usuarios reales o datos de Chrome User Experience Report cuando puedas.

<!-- tool-cta:start -->

💡 Prueba esto: Mantén tu imagen LCP pequeña y cargada de forma anticipada pasándola por Image Compressor, para que se renderice rápidamente sin necesitar carga diferida.

<!-- tool-cta:end -->

Una política práctica para la mayoría de los sitios web

Para la mayoría de los sitios de marketing, páginas de ecommerce, sitios de documentación y páginas de medios, esta política es suficiente:

• Imagen principal por encima del pliegue: carga eager, considera alta prioridad de descarga.
• Imágenes de contenido por debajo del pliegue: carga diferida.
• Iconos y recursos pequeños de interfaz: normalmente no merece la pena pensarlos individualmente.
• Hero con fondo CSS: reconsidéralo como imagen HTML o precárgalo con cuidado.
• Imagen hero inyectada por JavaScript: corrige la arquitectura de renderizado si es posible.
• Carruseles: carga de forma eager solo la primera diapositiva visible; carga de forma diferida el resto.

Hay casos límite. Las heurísticas de los navegadores mejoran. Los frameworks añaden componentes de imagen automáticos. Algunas plataformas ahora evitan la carga diferida en imágenes detectadas cerca del viewport. Aun así, el principio no cambia: los recursos críticos deben llegar pronto y ser obvios; los recursos no críticos deben esperar.

La carga diferida es valiosa cuando expresa esa distinción. Es perjudicial cuando oculta el contenido más importante al navegador hasta que la página ya ha empezado a perder la carrera de LCP.