Largest Contentful Paint (LCP): cómo medir y mejorar la carga de tu web

Abres tu web en el móvil y el titular tarda en aparecer. Ese hueco es el Largest Contentful Paint (LCP): la métrica con la que Google y tus usuarios juzgan si tu página carga rápido. Aquí tienes cómo medirlo y cómo arreglarlo.

Qué mide el Largest Contentful Paint (LCP) y qué no

El Largest Contentful Paint es el tiempo de renderizado del elemento más grande visible en la ventana del navegador, contado desde que arranca la navegación. Ese reloj incluye las redirecciones, el handshake TLS, el evento unload de la página anterior y el TTFB, así que los datos de campo y los de laboratorio casi nunca cuadran.

Qué elementos cuentan como candidatos

• <img> y <image> dentro de un SVG.
• <video>: su póster o su primer fotograma, el que ocurra antes.
• Bloques de texto: párrafos, titulares y listas.
• Elementos con fondo url() en CSS; un degradado no cuenta.

El tamaño se calcula sobre el área visible: los recortes no suman. En imágenes se toma el menor entre tamaño visible e intrínseco, así que una foto enorme mostrada en miniatura no se vuelve candidata.

Qué excluye la heurística de "poco contenido"

Chrome descarta candidatos con opacidad cero, elementos que cubren toda la ventana a modo de fondo e imágenes de baja entropía: placeholders, blur-ups y bloques de un solo color. El LCP deja de reportar candidatos en cuanto el usuario interactúa. Un <svg> en línea no es candidato; la misma imagen dentro de un <img src> sí.

Los umbrales: 2,5 segundos en el percentil 75

2,5 segundos o menos es bueno, entre 2,5 y 4,0 segundos es mejorable y por encima de 4,0 segundos es malo. Son los mismos umbrales que Google publica junto al resto del marco en Core Web Vitals y resultados de búsqueda.

El matiz que lo cambia todo es el percentil 75 de las visitas, con móvil y escritorio por separado. No es una media ni el dato de tu última recarga: la pregunta correcta no es cuánto tarda tu web, sino cuánto tarda para tres de cada cuatro visitas. Y la métrica no se detiene en la primera pintura: si un banner entra después del titular y resulta más grande, el LCP es el del banner.

Las cuatro subpartes del LCP: dónde se va el tiempo

Toda página descompone su LCP en cuatro tramos que no se solapan y que juntos suman el total:

Dos llevan "retraso" en el nombre y deberían ir a cero: es trabajo que tu web puede saltarse. Las otras dos implican red y solo se recortan. La idea clave, que la guía oficial de optimización del LCP deja clara, es que mejorar una subparte puede no bajar el total: solo mueve el tiempo a otra.

Cómo medir el LCP: primero datos de campo, después laboratorio

El orden no es negociable. Los datos de campo vienen de usuarios reales (CrUX, PageSpeed Insights y el informe de Core Web Vitals de Search Console); los de laboratorio (Lighthouse, DevTools) sirven para diagnosticar, no para decidir si tienes un problema.

Qué mirar en el informe de Core Web Vitals

• Agrupa por grupos de URL y por dispositivo, con móvil y escritorio separados.
• El estado del grupo es el de su métrica peor: si el LCP es bueno pero el CLS falla, el grupo aparece como malo.
• Un grupo necesita datos suficientes de LCP y CLS para aparecer.
• Los valores mostrados son el 75% de las visitas de ese grupo.

Cómo leer ese panel y sacarle partido lo tienes en cómo usar Google Search Console para mejorar tu SEO.

Medir el LCP con JavaScript (y sus trampas)

Puedes registrarlo con un PerformanceObserver sobre el tipo largest-contentful-paint, pero es más sensato usar la librería web-vitals para no reimplementar los casos raros: iframes (la API no los mide, la métrica sí), bfcache, páginas prerenderizadas y pestañas de fondo. La variante de atribución entrega además las subpartes.

import { onLCP } from 'web-vitals/attribution';

onLCP(({ value, attribution }) => {
  navigator.sendBeacon('/rum', JSON.stringify({ value, attribution }));
});

Tu script puede dar un número algo distinto al de Google, sobre todo con anuncios y contenido dentro de iframes: tu medición aproxima la métrica, no la replica.

Qué ha cambiado en 2026 (y por qué muchas guías están desactualizadas)

• Chrome 147 (feb-2026) emite los candidatos comparando con la imagen ya pintada más grande, no con la que está pendiente de descargar. En páginas con un hero lento vuelven a aparecer candidatos intermedios en tu analítica, aunque CrUX no cambia.
• Chrome 151 (jul-2026) entrega el LCP de los elementos <video> en la primera oportunidad de pintado, alineando mejor los datos de campo con tu propia medición.
• Las navegaciones suaves están habilitadas por defecto desde Chrome 151: ya puedes medir el LCP de cada cambio de ruta en una aplicación de una sola página. Necesitas web-vitals v6 o superior y restar el startTime de cada navegación. CrUX todavía no publica métricas segmentadas por navegación suave: esto se ve en tu analítica, no en Search Console.

Y una corrección al consejo clásico: desde Chrome 133 el renderTime de recursos de otro origen se expone sin Timing-Allow-Origin. Si tu guía dice que lo necesitas para no falsear el LCP, actualízala.

Cómo mejorar el LCP: los cuatro frentes, en orden

1. Retraso de carga: que el recurso se descubra antes

El recurso LCP debería estar en el HTML, no inyectado por JavaScript ni referenciado solo desde una hoja de estilos externa. Si no puede ser, usa <link rel="preload" fetchpriority="high" as="image">. Nunca pongas loading="lazy" en la imagen principal y limita fetchpriority="high" a una o dos imágenes: en todas, no ayuda a ninguna.

2. Duración de carga: menos bytes y más cerca

Formatos modernos (WebP o AVIF), dimensiones correctas con srcset y sizes, buena compresión, CDN y proximidad geográfica. Sirve el recurso desde el mismo origen que el HTML. Lo complementas con cómo optimizar tus imágenes para SEO.

3. Retraso de renderizado: quitar lo que bloquea

Fuentes con font-display y precarga de la tipografía del titular, y fuera el CSS y el JS que bloquean el render por delante del hero. Si tu web es cliente, el hero llega tarde: necesita HTML con el contenido dentro. Y nunca dejes el elemento principal oculto hasta que termine un script.

4. TTFB: el primero de la fila

Menos redirecciones en cadena, caché de HTML y un hosting a la altura. Regla práctica: si tu LCP está casi pegado al TTFB, no hay nada que arreglar en el frontend; el cuello de botella está en el servidor.

Errores que empeoran el LCP sin que te des cuenta

• Lazy loading en la imagen principal.
• Un carrusel con varias imágenes a prioridad alta compitiendo entre sí.
• El hero como background-image en una hoja de estilos externa.
• Tipografías sin precarga y sin font-display.
• Confiar solo en Lighthouse, o solo en la media de una visita.
• Medir en tu portátil con fibra y no mirar nunca el informe de móvil.

Cómo comprobar que la mejora fue real

Vuelve a los datos de campo. CrUX usa una ventana de 28 días, así que verás la mejora de forma progresiva. Comprueba por dispositivo y por grupos de URL: si mejoró la portada pero empeoró una categoría, el problema sigue ahí. Anota una línea base antes de tocar nada (fecha y percentil 75 de móvil y escritorio).

LCP y SEO: lo que Google dice de verdad

La documentación oficial es clara: las Core Web Vitals sí las usan los sistemas de ranking, pero no existe una única señal de experiencia de página y los demás aspectos de experiencia no ayudan directamente a posicionar. Google busca mostrar el contenido más relevante aunque la experiencia sea deficiente, como recuerda su guía de experiencia de página. Traducción práctica: el LCP no es una palanca de posiciones, es una palanca de experiencia y conversión que además juega a tu favor cuando compites con contenido igual de bueno por la misma consulta.

Conclusión: la lista de comprobación

1. Mira tu percentil 75 de móvil en datos de campo, no en tu equipo.
2. Descompón el LCP en sus cuatro subpartes y anota cuál pesa más.
3. Identifica el elemento LCP exacto, con nombre y apellidos.
4. Ataca primero el retraso de carga y el de renderizado: pueden ir a cero.
5. Recorta bytes y sirve el recurso desde el mismo origen que el HTML.
6. Vuelve a los datos de campo a los 28 días y compara por dispositivo y grupo de URL.

El orden importa más que la prisa: si optimizas sin medir, es fácil mover el problema de sitio en lugar de resolverlo.