Ver contenido
Introducción
El lazy loading tiene buena reputación, y con razón: diferir imágenes que el usuario todavía no ve ahorra ancho de banda y acelera la carga inicial. El problema aparece cuando esa misma técnica se aplica sin distinguir a la imagen equivocada. Si difieres tu imagen LCP (Largest Contentful Paint), no estás optimizando: estás retrasando lo primero que el usuario necesita ver.
Este artículo explica el porqué. Qué mide realmente el LCP, cómo funciona el diferimiento con loading="lazy", y por qué la combinación de ambos empuja tu métrica más visible en la dirección contraria. No es un tutorial paso a paso: si ya identificaste el problema y quieres corregirlo en tu CMS o framework, más abajo enlazamos la guía práctica.
Qué es el LCP y por qué importa
Largest Contentful Paint (LCP) mide cuánto tarda en volverse visible el elemento de contenido más grande del viewport inicial, normalmente una imagen o un bloque de texto. Google lo usa como uno de los Core Web Vitals, el conjunto de métricas que evalúan la experiencia de carga y que forman parte de sus señales de ranking.
Umbrales que define Google:
- Bueno: ≤ 2.5 segundos
- Necesita mejora: 2.5 - 4.0 segundos
- Pobre: > 4.0 segundos
En la mayoría de las páginas, el elemento LCP es una imagen hero, la foto de producto destacada o un banner grande. Es decir: casi siempre es la imagen que da sentido a la pantalla, la que el usuario está esperando. Por eso el LCP funciona como un buen proxy de la percepción de velocidad: no mide cuándo termina de cargar todo, sino cuándo aparece lo que importa.
Cómo funciona el lazy loading del navegador
El atributo loading="lazy" le indica al navegador que posponga la descarga de una imagen hasta que esté por entrar en el viewport. Es un mecanismo nativo, sin JavaScript adicional: el navegador observa la posición del elemento y solo dispara la petición de red cuando el usuario se acerca a él al hacer scroll.
<!-- Uso correcto: imagen que vive debajo del fold -->
<img src="galeria-3.jpg" alt="Descripción" loading="lazy">
Para una miniatura al final de la página o la cuarta imagen de una galería, esto es exactamente lo que quieres: no gastar red en algo que quizás el usuario nunca alcance. El diferimiento es una herramienta de priorización, y como toda priorización, solo sirve si distingue lo urgente de lo que puede esperar.
El mecanismo: por qué diferir el LCP retrasa la métrica
Aquí está el núcleo del problema. Cuando marcas tu imagen LCP con loading="lazy", le estás pidiendo al navegador que trate como aplazable justamente el recurso que define tu métrica de carga. El navegador te hace caso, y eso es lo que duele.
Sin diferimiento, el navegador descubre la imagen mientras parsea el HTML y comienza a descargarla de inmediato, en paralelo con el resto de recursos. Con loading="lazy", en cambio, la secuencia cambia:
- El navegador parsea el HTML y encuentra la imagen hero.
- Ve
loading="lazy"y decide no pedirla todavía. - Necesita calcular el layout para saber si la imagen cae dentro del viewport.
- Recién cuando confirma que sí está visible, dispara la descarga.
- La imagen llega tarde, y el LCP se registra cientos de milisegundos después de lo que debería.
La paradoja es que la imagen LCP ya está en el viewport desde el primer momento. El diferimiento se pensó para recursos fuera de pantalla, pero el navegador no puede asumir que un elemento es visible sin antes resolver el layout. Ese trabajo intermedio —esperar el layout en lugar de pedir la imagen apenas la descubre— es el retraso artificial. Según web.dev, aplicar lazy loading al elemento LCP puede sumar 500 ms o más a la métrica. No es que el navegador falle: hace exactamente lo que le pediste, aplazar. El error está en habérselo pedido para la imagen equivocada.
Qué se rompe en Core Web Vitals y en SEO
El LCP no vive aislado. Es uno de los tres Core Web Vitals, y Google lo incorpora a sus señales de experiencia de página. Un LCP que cruza el umbral de los 2.5 segundos no solo se ve más lento para el usuario: puede mover tu evaluación de Core Web Vitals de "aprobado" a "reprobado", con el impacto que eso tiene sobre la competitividad de la página en los resultados de búsqueda.
El detalle que hace este error tan frecuente es que suele ser invisible en el código fuente. Nadie escribe conscientemente loading="lazy" en su imagen hero; llega por defecto, a través de un plugin de optimización, un tema de CMS o el comportamiento estándar de un componente de framework. La intención era acelerar el sitio, y el resultado fue frenar la métrica que más miran los motores de búsqueda.
El principio: lazy loading selectivo
La conclusión no es abandonar el lazy loading. Es aplicarlo con criterio. La regla se puede resumir en una línea: si el usuario ve la imagen sin hacer scroll en la mayoría de los dispositivos, no la difieras.
Diferir (loading="lazy") tiene sentido para contenido que el usuario aún no ve:
- Imágenes debajo del fold, más abajo en la página
- Fotos de producto a partir de la primera fila visible de una grilla
- Miniaturas de blog, ítems de galería, imágenes del footer
- Contenido dentro de carruseles, pestañas o secciones ocultas
Cargar con prioridad (sin diferir) corresponde al contenido que el usuario ve de inmediato:
- La imagen hero
- La primera foto de producto visible
- Cualquier imagen above-the-fold
- Tu elemento LCP, sea cual sea
Visto así, el lazy loading no es una casilla que se activa para todo el sitio, sino una decisión por imagen. La misma técnica que acelera una galería de veinte fotos es la que frena tu hero si la aplicas sin distinguir. El objetivo no es diferir todo ni nada, sino reservar la red para lo que el usuario necesita primero.
Cómo corregirlo
La corrección conceptual es directa: quita loading="lazy" de tu imagen LCP y, si quieres ir un paso más allá, indícale al navegador que la priorice con fetchpriority="high". Pero identificar cuál es exactamente tu elemento LCP, encontrar de dónde salió el atributo (un plugin de WordPress, el auto-lazy de Shopify, una librería JavaScript, el componente de imagen de un framework) y verificar la mejora es un trabajo con sus propios pasos. Todo eso lo cubre en detalle la guía Cómo detectar y corregir el lazy loading en tu imagen LCP, con DevTools, Lighthouse y PageSpeed Insights, y las soluciones específicas por plataforma. Este artículo se queda en el porqué; el cómo está allí.
Artículos Relacionados
- Cómo detectar y corregir el lazy loading en tu imagen LCP - Diagnóstico paso a paso y soluciones por CMS y framework
- Guía de Optimización de LCP - Guía completa para mejorar el Largest Contentful Paint
- Fetchpriority de Imágenes Explicado - Cómo priorizar la carga de una imagen crítica
- Preloading de Imágenes Explicado - Cuándo hacer preload de imágenes
- Hub de SEO de Imágenes - Todas las guías de optimización de imágenes
Referencias
- web.dev - Largest Contentful Paint - Documentación oficial de LCP de Google
- web.dev - Browser-level lazy loading - Cuándo usar lazy loading
- Chrome Developers - Lighthouse LCP - Midiendo LCP
- MDN - Lazy loading - Referencia técnica