Cómo mejorar el LCP optimizando imágenes

Qué es el LCP y por qué depende de las imágenes

El Largest Contentful Paint (LCP) mide cuánto tarda en mostrarse el elemento más grande visible en la ventana al cargar la página. Google considera bueno un LCP de 2,5 segundos o menos en el percentil 75 de las visitas reales, y es una de las tres métricas de Core Web Vitals junto a INP y CLS.

En la gran mayoría de páginas —portadas, fichas de producto, artículos— ese elemento es una imagen: el banner principal, la foto del producto o la imagen destacada del post. Por eso, mejorar el LCP es casi siempre mejorar cómo se carga una imagen concreta.

Las cuatro fases del LCP

El tiempo de LCP se puede descomponer en cuatro partes. Identificar cuál es la más larga te dice qué optimizar:

1. Tiempo hasta el primer byte (TTFB): lo que tarda el servidor en responder con el HTML.
2. Retraso de carga del recurso: tiempo entre el TTFB y el momento en que el navegador empieza a descargar la imagen.
3. Duración de la carga del recurso: lo que tarda en descargarse la imagen.
4. Retraso de renderizado: tiempo entre que termina la descarga y la imagen se pinta.

Las imágenes afectan sobre todo a las fases 2 y 3. Una guía útil de Google: en una página bien optimizada, las fases de retraso deberían ser mínimas y la mayor parte del tiempo se dedica al TTFB y a la descarga.

Paso 1: encuentra tu elemento LCP

Antes de optimizar, confirma cuál es. Tienes varias formas:

• PageSpeed Insights o Lighthouse: en el diagnóstico "Elemento de Largest Contentful Paint" aparece el nodo exacto.
• Chrome DevTools > Rendimiento: graba una carga y busca el marcador LCP en la línea de tiempo.
• Search Console > Core Web Vitals: muestra los grupos de URLs con problemas según datos reales de usuarios.

El elemento LCP puede ser distinto en móvil y escritorio. Revisa ambos.

Paso 2: que el navegador la descubra pronto

El error más común es que la imagen LCP no esté en el HTML inicial: se inserta con JavaScript, es un background-image de CSS o depende de un slider que se inicializa tarde. En esos casos el navegador no puede empezar a descargarla hasta mucho después.

Soluciones, de mejor a peor:

• Usa un <img> normal en el HTML servido por el servidor.
• Si debe ser fondo CSS o se carga con JS, añade un <link rel="preload">:

<link rel="preload" as="image" href="/hero.avif" type="image/avif" fetchpriority="high">

Si usas imágenes responsive, el preload admite imagesrcset e imagesizes para precargar la variante correcta.

Paso 3: dale prioridad alta

Por defecto, el navegador descarga las imágenes con prioridad baja hasta que sabe que son visibles. El atributo fetchpriority="high" le indica desde el principio que esta es importante:

<img src="/hero.avif" fetchpriority="high" width="1600" height="900" alt="…">

Y lo más importante: nunca pongas loading="lazy" en la imagen LCP. La carga diferida retrasa la descarga hasta que el navegador calcula el diseño, y es una de las causas más frecuentes de LCP lento. En la guía sobre lazy loading y fetchpriority tienes el detalle.

Paso 4: reduce su peso

Con la imagen ya descubierta y priorizada, el tiempo de descarga depende de sus bytes. Aquí entra la optimización:

• Dimensiones correctas. Si la imagen se muestra a 1200 px, no sirvas 4000 px. Usa srcset para ofrecer varios tamaños.
• Formato moderno. AVIF suele reducir el peso un 40-50 % frente a JPEG. Usa <picture> con WebP o JPEG de respaldo.
• Calidad razonable. Para una imagen principal, AVIF 55-65 o WebP 80 suelen ser indistinguibles del original.

Una imagen LCP de 400 KB en JPEG puede quedar en 120-180 KB en AVIF. En una conexión 4G media eso son cientos de milisegundos menos.

Paso 5: evita retrasos de renderizado

Aunque la imagen haya llegado, puede tardar en pintarse si:

• Hay CSS o JavaScript bloqueantes que retrasan el primer renderizado.
• La imagen está oculta inicialmente (por ejemplo, un carrusel que la muestra con una animación).
• Una fuente web retrasa el texto y, con él, el diseño.

Mantén el CSS crítico pequeño, difiere el JavaScript no esencial y evita animaciones de entrada en la imagen principal.

Errores frecuentes

• loading="lazy" en la primera imagen visible.
• Hero como background-image sin preload.
• Servir la misma imagen de 2500 px a móviles.
• Sliders que cargan todas las diapositivas con la misma prioridad.
• CDNs de imágenes con redirecciones o en un dominio distinto sin preconnect.

Preguntas frecuentes

¿Cuánto mejora el LCP cambiar a AVIF?

Depende de la conexión y del peso original, pero si la imagen supone la mayor parte del tiempo de carga, reducir su tamaño a la mitad puede recortar cientos de milisegundos en móviles.

¿Debo usar preload y fetchpriority a la vez?

Si la imagen ya está en el HTML como <img>, basta con fetchpriority="high". El preload es útil cuando el navegador no puede descubrirla pronto.

¿El texto puede ser el elemento LCP?

Sí. Si el bloque más grande es un titular, el LCP depende sobre todo del TTFB y de la carga de fuentes, no de imágenes.

¿Por qué Lighthouse y Search Console dan resultados distintos?

Lighthouse es una prueba de laboratorio en condiciones simuladas. Search Console usa datos reales de usuarios (CrUX) de los últimos 28 días. Los cambios tardan unas semanas en reflejarse en los datos reales.