Largest Contentful Paint (LCP): definición, umbrales y soluciones

¿Qué es Largest Contentful Paint (LCP)?

Largest Contentful Paint (LCP) es una Core Web Vital que mide cuánto tarda en terminar de renderizarse la imagen, el bloque de texto o el vídeo más grande de la ventana visible, contando desde que el visitante empieza a navegar. Google considera bueno un valor de 2,5 segundos o menos, evaluado en el percentil 75 de cargas reales de página, por separado en móvil y en escritorio.

Como el reloj arranca al navegar, también cuentan las redirecciones, el establecimiento de la conexión y una respuesta lenta del servidor. El LCP es una de las tres Core Web Vitals, junto con INP (capacidad de respuesta) y CLS (estabilidad visual).

Umbrales del LCP

Una página lo supera cuando el percentil 75 de sus cargas está en el rango bueno. Móvil y escritorio se evalúan por separado. Los umbrales se mantienen en web.dev.

¿Qué elemento cuenta como elemento LCP?

El navegador informa del mayor de estos elementos que sea visible en la ventana:

• Elementos <img> (el primer fotograma en las imágenes animadas)
• Elementos <image> dentro de un <svg>
• Elementos <video>, con su imagen de póster o el primer fotograma
• Elementos con imagen de fondo CSS mediante url() (no degradados)
• Elementos de bloque que contienen texto

Solo cuenta la parte visible, y Chromium ignora los elementos con opacidad 0, los que cubren toda la ventana y las imágenes de relleno. El candidato puede cambiar durante la carga, por ejemplo cuando una imagen principal llega después de un titular. El navegador deja de informar cuando el visitante toca, hace scroll o pulsa una tecla, y las páginas cargadas en una pestaña en segundo plano no cuentan.

Las cuatro partes del LCP

Todo tiempo de LCP se divide en cuatro partes. web.dev da esta referencia de cómo reparte su tiempo una página bien ajustada, que debe leerse en proporción entre sí y no como cifras absolutas:

Corrige la parte que se sale de proporción en tu página. Un retraso de carga largo exige otra solución que un Time to First Byte lento.

Ejemplo: una imagen principal que el navegador descubre tarde

Una tienda define su foto principal como background-image CSS en una hoja de estilos externa. El navegador no ve la imagen en el HTML y espera al CSS antes de iniciar la descarga. Eso se nota como un retraso de carga del recurso elevado. Si la foto pasa a un <img> con prioridad de descarga alta, el navegador la encuentra de inmediato:

<img src="/img/hero-1200.avif" alt="Product dashboard"
     width="1200" height="675" fetchpriority="high">

Un archivo más pequeño (consulta tamaño de imagen) acorta después la duración de la descarga.

Cómo mejorar el LCP

• Haz que el recurso LCP sea descubrible en el HTML inicial, con src o srcset en el marcado y no añadido por JavaScript.
• Si la imagen solo se referencia desde CSS o JavaScript, precárgala con <link rel="preload">.
• Pon fetchpriority="high" en la imagen LCP. web.dev advierte de que deja de ayudar si se aplica a más de una o dos imágenes.
• No cargues nunca de forma diferida la imagen LCP. La carga diferida es para imágenes bajo el pliegue.
• Reduce el archivo: ajústalo al tamaño mostrado y usa un formato moderno como AVIF o WebP.
• Recorta el tiempo de respuesta del servidor con caché y una CDN, y evita las cadenas de redirecciones.

Errores comunes con el LCP

• Cargar de forma diferida la imagen principal.
• Esconder la imagen principal tras un carrusel en JavaScript o un renderizado en cliente, de modo que se descubre tarde.
• Optimizar la imagen mientras el servidor sigue tardando segundos en responder.
• Poner fetchpriority="high" en todas las imágenes.
• Probar solo con una conexión de escritorio rápida y fiarse de esa cifra.

Cómo medir el LCP

Las herramientas de laboratorio como Lighthouse y Chrome DevTools miden una carga controlada e indican el elemento LCP, lo que las hace útiles para depurar. Los datos de campo proceden de visitantes reales, por ejemplo del Chrome UX Report, y son la base para aprobar o suspender las Core Web Vitals. Los dos suelen diferir porque los dispositivos, las redes y las ubicaciones reales varían. Para registrar el LCP en el navegador:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const last = entries[entries.length - 1];
  console.log('LCP:', last.startTime, last.element);
}).observe({ type: 'largest-contentful-paint', buffered: true });

El LCP en las pruebas y la monitorización

La monitorización de velocidad de página de LoadFocus ejecuta auditorías de Lighthouse programadas desde 25 regiones en la nube y registra las Core Web Vitals, incluido el LCP, de modo que una imagen principal más pesada o un servidor más lento se vea como tendencia. El verificador gratuito de Core Web Vitals muestra el LCP de usuarios reales de Chrome para una URL en el percentil 75. Las correcciones paso a paso de las tres métricas están en nuestra guía de optimización de Core Web Vitals. Para leer más: cómo monitorizar las Core Web Vitals con alertas e informes y 10 pasos para una web más rápida.

Preguntas frecuentes: Largest Contentful Paint

¿Qué es un buen valor de LCP?

2,5 segundos o menos en el percentil 75 de las cargas de página. Entre 2,5 y 4,0 segundos necesita mejorar, y más de 4,0 segundos es deficiente.

¿Por qué Lighthouse muestra un LCP distinto al de Search Console?

Lighthouse mide una carga simulada. Search Console informa de datos de campo de visitantes reales durante un periodo, en muchos dispositivos y redes. Usa el valor de laboratorio para encontrar causas y el de campo para juzgar el resultado.

¿Cómo encuentro mi elemento LCP?

Ejecuta una auditoría de Lighthouse y abre el diagnóstico del elemento de Largest Contentful Paint, o graba un registro en el panel Rendimiento de Chrome DevTools. En código, la propiedad element de la entrada largest-contentful-paint apunta a él.

¿Debo cargar de forma diferida mi imagen principal?

No. web.dev indica que nunca se cargue de forma diferida la imagen LCP, porque añade retraso antes de que empiece la descarga. Aplica la carga diferida a las imágenes más abajo en la página.

¿Por qué el LCP es más lento en móvil?

Los móviles suelen tener procesadores y conexiones más lentos, y la ventana más pequeña puede hacer que otro elemento sea el mayor. Por eso las Core Web Vitals se evalúan por separado en móvil y en escritorio.