TL;DR, Respuesta rápida
9 min de lecturaLargest Contentful Paint es bueno en 2.5 segundos o menos, necesita mejorar entre 2.5 y 4.0 segundos y es pobre por encima de 4.0 segundos, leído en el percentil 75. Mide cuándo terminó de renderizarse la imagen o el bloque de texto más grande del viewport, y Google lo divide en cuatro subpartes: time to first byte, resource load delay, resource load duration y element render delay. Mide la división antes de optimizar, porque tres de los cuatro arreglos no hacen nada por la cuarta.
¿Qué es LCP (Largest Contentful Paint) y qué es una buena puntuación?
Google puntúa Largest Contentful Paint como bueno en 2.5 segundos o menos, necesita mejorar entre 2.5 y 4.0 segundos y pobre por encima de 4.0 segundos, leído en el percentil 75 de las cargas de página y puntuado por separado para móvil y escritorio (web.dev, "Largest Contentful Paint (LCP)", actualizado 4 de septiembre de 2025). La métrica marca el momento en que terminó de renderizarse la imagen o el bloque de texto más grande visible dentro del viewport, que es la mejor aproximación del navegador al momento en que un visitante decide que la página ya llegó. Compara tu número con 2.5 segundos en p75 primero, porque una media que aprueba con un p75 que suspende sigue siendo una página que suspende.
El tamaño se juzga solo dentro del viewport, y para las imágenes el navegador reporta el tamaño visible o el tamaño intrínseco, el que sea menor.
¿Qué elementos pueden ser el elemento LCP?
La especificación de LCP cuenta cinco tipos de elemento, así que el ganador en tu página es uno de ellos y nada más. Todo lo que queda fuera de la lista, elementos canvas y degradados CSS incluidos, no puede llevarse el título por mucha pantalla que ocupe.
| Elemento elegible | Qué mide el navegador |
|---|---|
<img> | Tamaño visible o intrínseco, el que sea menor |
<image> dentro de <svg> | La misma regla que <img> |
<video> | La imagen del póster, o el primer fotograma pintado |
Cualquier elemento con una imagen de fondo url() | El área pintada del elemento |
| Elementos de bloque que contienen nodos de texto | El rectángulo más pequeño alrededor de todos los nodos de texto |
Identifica el tuyo antes de tocar nada. Chrome DevTools nombra el elemento ganador en el panel Performance, y las herramientas de campo lo adjuntan a cada muestra, lo que importa porque los dos rara vez coinciden.
¿Cuáles son las cuatro subpartes de Largest Contentful Paint?
Google divide Largest Contentful Paint en time to first byte (tiempo hasta el primer byte), resource load delay (espera hasta que empieza la descarga), resource load duration (duración de la descarga del recurso) y element render delay (espera hasta que el elemento se pinta), cuatro tramos consecutivos que suman la métrica entera. El equipo de Chrome publica una cuota objetivo para cada uno en "Optimize Largest Contentful Paint" (web.dev, actualizado 31 de marzo de 2025): alrededor del 40% para time to first byte, por debajo del 10% para resource load delay, alrededor del 40% para resource load duration y por debajo del 10% para element render delay. Mide las cuotas antes de elegir un arreglo, porque una subparte que ya está dentro de su presupuesto no puede devolverte los segundos que necesitas.
| Subparte | Qué cubre | Cuota objetivo | Qué la vuelve lenta | El arreglo |
|---|---|---|---|---|
| Time to first byte | Del inicio de la navegación hasta que llega el primer byte de la respuesta HTML | ~40% | Cadenas de redirecciones, respuestas de origen sin cachear, trabajo lento en el backend, distancia al origen | Cortar redirecciones, servir HTML cacheado desde nodos edge de un CDN, reducir el tiempo de procesamiento del backend |
| Resource load delay | Del primer byte hasta que el navegador empieza a descargar el recurso LCP | <10% | La imagen solo se referencia en CSS o JS, así que el preload scanner nunca la ve; loading="lazy" en el hero; renderizado en cliente que la inyecta tarde | Poner la imagen LCP en el HTML inicial, añadir <link rel="preload" fetchpriority="high"> cuando solo se alcanza vía CSS o JS, quitar el lazy loading del hero |
| Resource load duration | La descarga del recurso LCP en sí, de principio a fin | ~40% | Imágenes sobredimensionadas o sin comprimir, formatos antiguos, competencia por el ancho de banda, sin cabeceras de caché | Comprimir y redimensionar, servir AVIF o WebP, servir desde un CDN, fijar caducidades de caché largas, incrustar recursos pequeños |
| Element render delay | Del fin de la descarga hasta que el elemento se pinta de verdad | <10% | Hojas de estilo y scripts que bloquean el renderizado, tareas largas en el hilo principal, hidratación que retiene el primer pintado | Diferir o incrustar el CSS y el JS bloqueantes, renderizar en el servidor, partir las tareas largas |
¿Cómo se reparte un Largest Contentful Paint de 4.2 segundos entre las cuatro partes?
La división convierte un número inútil en un objetivo evidente, porque la métrica es una suma simple:
LCP = time to first byte + resource load delay + resource load duration + element render delay
Toma una página cuyo LCP p75 es de 4.2 segundos, que es pobre. Los datos de campo lo reparten en 0.9s de time to first byte, 2.0s de resource load delay, 1.0s de resource load duration y 0.3s de element render delay. Aplica las cuotas objetivo a 4.2 segundos para obtener el presupuesto de cada subparte.
| Subparte | Medido | Cuota de 4.2s | Presupuesto en 4.2s | Veredicto |
|---|---|---|---|---|
| Time to first byte | 0.9s | 21% | 1.68s | Dentro del presupuesto |
| Resource load delay | 2.0s | 48% | 0.42s | 4.8x por encima |
| Resource load duration | 1.0s | 24% | 1.68s | Dentro del presupuesto |
| Element render delay | 0.3s | 7% | 0.42s | Dentro del presupuesto |
Tres de las cuatro están sanas. La imagen del hero no se pide hasta dos segundos completos después de que llega el HTML, lo que apunta al descubrimiento: la imagen está detrás de una regla CSS, detrás de un script o detrás de loading="lazy". Comprimirla más atacaría el 1.0s que ya está bien y dejaría la página en pobre.
Arregla el problema de descubrimiento y el resource load delay baja a unos 0.2s. La nueva suma es 0.9 + 0.2 + 1.0 + 0.3 = 2.4s, que aprueba. Un cambio, 1.8 segundos, ninguna imagen recodificada. Lleva el mismo desglose a Cumulative Layout Shift y a Interaction to Next Paint, y úsalo para decidir qué cuenta como un buen LCP en una página concreta.
¿Por qué cambia el elemento LCP entre móvil y escritorio?
El elemento LCP es lo que sea más grande dentro del viewport de ese visitante, así que un diseño que se reordena entre breakpoints entrega el título a un elemento distinto en cada dispositivo. Una foto de hero de escritorio de 1200px de ancho puede quedar oculta por una media query en móvil, donde el bloque de texto del titular pasa a ser el elemento pintado más grande. Los dos números no comparten entonces ningún mecanismo: el LCP de escritorio lo domina resource load duration y el LCP móvil lo dominan time to first byte y element render delay, porque el texto no necesita una descarga aparte.
Esta es la trampa detrás de la mayoría del trabajo de LCP que fracasa. Un equipo hace preload de la imagen del hero, ve mejorar el LCP de escritorio y ve que el p75 móvil se niega a moverse, porque en móvil esa imagen nunca fue el elemento LCP. Google puntúa móvil y escritorio por separado, así que depúralos por separado: saca el elemento LCP por formato de dispositivo de los datos de campo y cuenta con dos arreglos distintos. Cuando gana el texto, una fuente web que bloquea el renderizado mueve la métrica entera a element render delay y ningún trabajo sobre imágenes la toca.
¿Por qué el lazy loading de una imagen de hero empeora el LCP?
Aplicar loading="lazy" a la imagen LCP siempre añade resource load delay, porque el preload scanner la salta durante el parseo del HTML y la descarga espera a que el layout se ejecute y coloque el elemento cerca del viewport. El equipo de Chrome lo dice sin rodeos en "Optimize Largest Contentful Paint" (web.dev, actualizado 31 de marzo de 2025): "a lazy-loaded LCP image will always lead to unnecessary resource load delay", es decir: una imagen LCP cargada de forma diferida siempre provocará resource load delay innecesario. La espera no compra nada, ya que un hero por encima del pliegue ya está en el viewport.
El daño llega por los valores por defecto. Un CMS o una librería de componentes que estampa loading="lazy" en cada imagen acierta con las 40 que están debajo del pliegue y falla con la única que está arriba. Pon loading="eager" y fetchpriority="high" en el hero, mantén el lazy loading en todo lo demás y confírmalo en datos de campo en vez de en una prueba de laboratorio.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
¿Cómo ves el LCP que recibieron tus visitantes reales?
Los datos de campo son la única fuente que reporta el elemento LCP y la división en subpartes desde dispositivos reales en redes reales, y por eso el real user monitoring está debajo de cada número de esta página. Una prueba de laboratorio devuelve un LCP repetible para una máquina que tú configuraste; el p75 que decide tu veredicto de Core Web Vitals sale de las visitas que de verdad recibiste.
El peso es la restricción, porque un script de monitorización que retrasa la página corrompe la métrica que reporta. Flowsery recoge datos de campo con un único script de menos de 10 KB, sin cookies y alojado en la UE, sin muestreo de datos, así que el p75 sale de todas las sesiones y no de un subconjunto. Graba la sesión junto a los tiempos y marca rage clicks, dead clicks, errores de JavaScript y abandonos, lo que convierte un p75 lento en una repetición que puedes ver.
Preguntas frecuentes
¿Largest Contentful Paint se mide antes o después de la interacción del usuario?
El navegador deja de reportar nuevos candidatos a LCP en la primera interacción del usuario, sea un scroll, un toque o una pulsación de tecla. Nada de lo que se pinte después de ese punto llega a ser el elemento LCP, por grande que sea. El corte mantiene la métrica atada a la carga inicial en lugar de al contenido que el visitante trajo a la vista con el scroll.
¿El elemento LCP tiene que quedarse en la página?
No. Una vez que un elemento queda registrado como largest contentful paint, conserva el título aunque salga del viewport con el scroll o abandone el DOM por completo, salvo que después se renderice un elemento mayor. Una imagen de bienvenida que desaparece a los 500ms fija igualmente tu LCP, y en un carrusel gana la primera diapositiva mientras que las siguientes no cambian nada.
¿Por qué mi LCP de laboratorio es rápido y mi LCP de campo es pobre?
Las herramientas de laboratorio miden un dispositivo en una conexión que tú configuraste, y los datos de campo miden los dispositivos que tu audiencia tiene de verdad. Un LCP de Lighthouse de 1.6s y un p75 de campo de 4.2s son las dos respuestas correctas a preguntas distintas. Verifica un arreglo en el laboratorio, decide si la página aprueba en el campo.
¿Un CDN arregla Largest Contentful Paint?
Un CDN reduce dos de las cuatro subpartes: time to first byte, al servir el HTML desde un nodo edge cerca del visitante, y resource load duration, al servir la imagen igual. No hace nada por el resource load delay causado por un descubrimiento tardío, ni por el element render delay causado por scripts que bloquean el renderizado. Divide tu LCP primero y la respuesta ya está a la vista.
¿Puede un vídeo ser el elemento LCP?
Sí. Los elementos de vídeo son elegibles, y el navegador mide la imagen del póster o el primer fotograma pintado. Poner un póster en un vídeo por encima del pliegue le da al navegador algo que pintar antes de que lleguen los datos del vídeo; sin él, el título de LCP se va a lo que sea más grande.
¿Cuántas muestras necesito para que un número de LCP signifique algo?
Las suficientes para que el percentil 75 deje de moverse cuando llega un solo dispositivo atípico. Una ruta con 40 visitas por semana produce un p75 que oscila con un único visitante en un móvil lento, así que agrega a la plantilla de página o amplía la ventana. Dividir por país y dispositivo a la vez multiplica el tráfico necesario, ya que cada segmento arrastra su propia distribución.
¿Puede un degradado CSS ser el elemento LCP?
La especificación de LCP reconoce cinco tipos de elemento: imágenes, imágenes SVG, vídeos, elementos con una imagen de fondo url() y bloques de texto. Los degradados CSS y los elementos canvas quedan fuera de esa lista, así que ninguno de los dos puede ganar el título sin importar cuánto viewport ocupen.
¿Puede un titular convertirse en el elemento LCP en lugar de una imagen?
Cualquier elemento de bloque que contenga nodos de texto califica, medido como el rectángulo más pequeño que envuelve esos nodos. Es justo lo que ocurre en los layouts móviles donde una media query oculta la foto de hero y el bloque de texto del titular pasa a ser el elemento más grande pintado.
¿Comprimir la imagen de hero siempre arregla un LCP lento?
Solo cuando resource load duration es la subparte que excede su presupuesto. En el ejemplo de 4.2 segundos de esta página, resource load duration ya estaba dentro de presupuesto en 1.0s mientras resource load delay iba 4.8 veces por encima, así que comprimir más la imagen habría dejado la página igual de pobre. Revisa el reparto antes de tocar la imagen.
¿Qué porcentaje del LCP debería ocupar resource load duration?
Alrededor del 40%, la misma cuota objetivo que time to first byte. Las otras dos subpartes, resource load delay y element render delay, deberían quedarse cada una por debajo del 10% del total.
¿Te resultó útil este artículo?
¡Cuéntanos qué opinas!
Vernos más en Google
Un clic marca Flowsery como fuente preferida y nuestros artículos aparecen más arriba en tus Noticias destacadas, el modo IA y los resúmenes con IA.
Antes de irte...
Flowsery
Analítica orientada a ingresos para tu sitio web
Rastrea cada visitante, fuente y conversión en tiempo real. Simple, potente y sin cookies.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
Términos relacionados del glosario
Cómo se calcula realmente el Cumulative Layout Shift
Cada puntuación de Cumulative Layout Shift es impact fraction por distance fraction, y Google reporta la mayor ráfaga de desplazamientos, no su suma.
Cómo Interaction to Next Paint puntúa tu peor clic
Chrome puntúa Interaction to Next Paint por la peor interacción de una página: input delay, processing y presentation delay hasta el siguiente frame pintado.
Qué demuestra la monitorización de usuarios reales que el laboratorio no puede
Pasiva por diseño, la monitorización de usuarios reales recoge rendimiento y errores de visitas que ocurrieron de verdad, y los lee en p75, no en media.
¿Cuánto ralentiza el session replay la velocidad de un sitio web?
La respuesta real a si el session replay ralentiza un sitio web, con cifras publicadas de rrweb y Sentry sobre script, CPU y ancho de banda de subida.
Cuándo empieza el muestreo de datos y cómo detectarlo en un informe
En GA4, el muestreo de datos empieza por encima de 10 millones de eventos en propiedades estándar y 100 millones en Analytics 360. Un icono es la única pista.
Qué registran los datos de clickstream, fila a fila
Cada fila de datos de clickstream es un hit con marca de tiempo, un identificador y una URL, y por eso el RGPD y la CCPA la tratan como dato personal.
Artículos relacionados
Cómo leer entry page vs landing page en GA4 y Adobe
La separación entre entry page vs landing page importa porque GA4 solo trae Landing page y Adobe solo trae Entry page, calculadas desde campos distintos.
Qué exige de verdad el RGPD en session replay
Revisar el RGPD en session replay depende de cuatro cosas: base legal del artículo 6, datos del artículo 9, consentimiento ePrivacy 5(3) y una EIPD.
En qué se diferencian de verdad rage clicks vs dead clicks
La distinción rage clicks vs dead clicks va de causa, no de gravedad. Umbrales publicados por PostHog, Hotjar, FullStory, LogRocket y Clarity.