Largest Contentful Paint (LCP): Qué es, cómo medir y optimizar

¿Qué es el Largest Contentful Paint (LCP)?

El Largest Contentful Paint es una medición del tiempo de renderizado del elemento de contenido más grande (de tipo imagen, video o texto) que ha sido pintado en la parte visible de la pantalla. El tiempo de LCP indica el tiempo en milisegundos entre la solicitud de la página y cuando ese elemento de contenido más grande se muestra en la parte visible de la página web (above the fold).

Historia del Largest Contentful Paint

Cuando lo piensa, el LCP podría parecer una métrica trivial para representar la parte de carga de los Core Web Vitals. ¿Por qué no medir la velocidad de carga como 'el tiempo que tarda la página en cargar'?

Eso es porque es difícil (o incluso imposible) en la mayoría de los sitios web modernos definir cuándo la página ha cargado. Cada vez más sitios web usan técnicas como lazy loading o carga progresiva donde la página básicamente puede seguir cargando indefinidamente. Eso significa que la velocidad de página no puede medirse por un solo punto en el tiempo.

Hay varios momentos al cargar la página que pueden hacer que un usuario perciba la página como rápida o lenta. Por ejemplo, el retraso del servidor (Time to First Byte), la primera vez que el contenido es visible (First Contentful Paint), el momento en que el viewport visible puede parecer completo (Largest Contentful Paint) y cuando la página se vuelve interactiva (cuando hacer clic en un enlace se vuelve posible) son todos puntos durante el proceso de carga donde el sitio puede parecer lento o rápido.

El Largest Contentful Paint (LCP) fue elegido porque se enfoca en la experiencia del usuario del visitante. Cuando ocurre el LCP puede asumir que un visitante piensa que la página ha terminado de cargar (incluso si procesos en segundo plano aún están ejecutándose). El LCP fue creado para responder la pregunta: '¿Cuándo es visible el contenido de una página?'. Esta es la razón por la cual el LCP es reconocido como un indicador central del rendimiento centrado en el usuario.

LCP vs FCP: ¿Cuál es la diferencia?

Largest Contentful Paint (LCP) y First Contentful Paint (FCP) miden el rendimiento de carga, pero capturan momentos fundamentalmente diferentes en la línea de tiempo de carga de la página. FCP se activa tan pronto como el navegador pinta el primer píxel de contenido, que podría ser una pequeña barra de navegación o un spinner de carga. LCP se activa cuando el elemento significativo más grande se renderiza en el viewport.

Piénselo de esta manera: FCP le dice que la página ha comenzado a cargar; LCP le dice que la página se siente cargada. Google eligió LCP como el Core Web Vital porque refleja con mayor precisión lo que los usuarios perciben como "velocidad".

Para la mayoría de los sitios web, optimizar el LCP debería ser la prioridad. Si su LCP es rápido, su FCP casi siempre será rápido también, porque el FCP ocurre antes en la línea de tiempo de carga. Lo contrario no es cierto: un FCP rápido no garantiza un LCP rápido.

Por qué el LCP importa para su negocio

El Largest Contentful Paint es uno de los 3 Core Web Vitals. Como Core Web Vital, el Largest Contentful Paint es importante para SEO, pero más importante aún, el LCP es crítico para UX. Los visitantes no les gusta esperar, y con cada vez más tráfico móvil (que tiende a ser más lento que el tráfico de escritorio) optimizar el Largest Contentful Paint tiene mucho sentido.

• Para SEO. Sí, Google se enfoca en servir las mejores páginas en sus resultados de búsqueda. LCP es parte de los Core Web Vitals de Google. Google declara claramente que la velocidad del sitio es un factor en los resultados de búsqueda.
• Para los visitantes: Según investigaciones recientes del propio Google, la probabilidad de que un usuario abandone el sitio se duplica con un tiempo de carga de 3 segundos. Probablemente lo reconozca usted mismo. Mientras navega por internet, casi nada parece tan molesto como un sitio web de carga lenta. Es probable que abandone rápidamente una página de carga lenta.
• Otras razones: La velocidad de página es un factor en su puntuación de anuncios de Google. Esto significa que puede comprar sus anuncios más baratos. Además, pasar los Core Web Vitals es uno de los prerequisitos para el cuadro de historias destacadas de Google.

Un LCP rápido da al visitante la idea de que la página carga rápidamente. Como resultado, es menos probable que un visitante navegue fuera de la página.

Caso de estudio: Vodafone (31% de mejora en LCP, 8% más ventas)

Vodafone Italia realizó un experimento controlado optimizando su puntuación LCP. Al reducir el LCP en un 31%, midieron un aumento del 8% en ventas. Esto no es una correlación; es una prueba A/B directa que demuestra que una carga percibida más rápida se traduce en más ingresos. La optimización se centró en precargar la imagen LCP y reducir los recursos que bloquean la renderización. Lea el caso de estudio completo de Vodafone en web.dev.

Caso de estudio: Google Flights (fetchpriority ahorró 700ms)

El equipo de Google Flights añadió fetchpriority="high" a su imagen hero y vio el LCP mejorar en 700 milisegundos. Este único cambio de atributo HTML fue la optimización más impactante en su sprint de rendimiento. El atributo fetchpriority le dice al navegador que priorice la descarga de la imagen LCP sobre otros recursos, y como demuestra el experimento de Google Flights, el impacto puede ser dramático. Aprenda más sobre priorización de recursos para Core Web Vitals.

¿Qué elementos se consideran elementos LCP?

No todos los elementos se consideran como un elemento LCP. El elemento de contenido más grande debe ser pintado en la parte visible de la pantalla (el viewport) antes de que el usuario haya interactuado con la página.

El elemento debe ser:

• Un elemento <img>.
• Un elemento <image> anidado dentro de un elemento <svg>.
• Un elemento <video> (se usa la imagen del póster o el primer fotograma del video, lo que ocurra primero).
• Un elemento con una imagen de fondo cargada mediante la función CSS url(). (Nota: Este es un antipatrón para la optimización de LCP ya que hace que la imagen sea indetectable para el escáner de precarga del navegador. Lea nuestra guía sobre diferir imágenes de fondo).

• Un elemento de nivel de bloque que contiene nodos de texto u otros elementos de texto en línea (en caso de elementos de texto en línea como <span> se considera el elemento de nivel de bloque más cercano <div> o <p>).

Actualmente, ciertos elementos están excluidos como candidatos LCP, como elementos ocultos con opacity: 0, imágenes que coinciden con el 100% del tamaño del viewport (imágenes de cobertura) y marcadores de posición (imágenes de baja entropía). Tenga en cuenta que esto puede cambiar a medida que la especificación evolucione.

Aspectos técnicos: Midiendo el tamaño del elemento LCP

LCP identifica el elemento de contenido visible más grande en el viewport y calcula su tamaño basándose en un conjunto de reglas precisas. Estas reglas aseguran consistencia y precisión, incluso en diseños complejos.

• Solo el viewport: Solo se considera la parte visible de la página. Si un elemento está solo parcialmente en el viewport visible, el tamaño considerado será recortado.
• Sin borde, padding ni margen: Para todos los elementos, los bordes, padding y márgenes de texto e imagen son completamente ignorados.
• Tamaño del texto: Los elementos de texto se reportan como el rectángulo más pequeño que puede pintarse alrededor del(los) nodo(s) de texto.
• Tamaño de imagen: Para imágenes, se usa el menor de las dimensiones intrínsecas (el ancho y alto originales) y el tamaño de visualización (el tamaño en pantalla) para calcular el tamaño del elemento LCP.
• Cuenta el primer tamaño: Cuando cambia el diseño o cuando cambia el tamaño de un elemento, solo el primer tamaño se considera para el LCP.
• Los elementos eliminados se incluyen: Cuando un elemento se elimina del DOM, sigue siendo un candidato LCP.

Naturaleza dinámica del LCP

Largest Contentful Paint (LCP) es una métrica dinámica. Si bien la renderización puede ser compleja y ocurrir en etapas, es normal que el elemento LCP cambie durante la carga de la página. Antes de la primera interacción del usuario, el observador de rendimiento del navegador identifica todos los elementos que podrían ser considerados candidatos LCP. Si se renderiza un nuevo elemento que es visible dentro del viewport y más grande que el elemento LCP previamente identificado, se convierte en el nuevo LCP.

Conclusiones de los datos de campo de LCP: En CoreDash rastreamos millones de entradas LCP por día. Resulta que, para las vistas de página móviles, el elemento LCP es frecuentemente un elemento basado en texto, ya sea un párrafo o un título. En promedio (o en el percentil 75 para ser precisos) los Core Web Vitals pasarán cuando el elemento LCP sea un nodo de texto o incluso una imagen normal. Cuando el elemento LCP es una imagen de fondo, video o una imagen con lazy loading, los Core Web Vitals tienden a fallar.

¿Qué es una buena puntuación LCP?

Para pasar los Core Web Vitals para el Largest Contentful Paint, al menos el 75% de sus visitantes necesitan tener una puntuación LCP 'buena'. Una puntuación LCP entre 0 y 2,5 segundos se considera una puntuación LCP buena, una puntuación LCP entre 2,5 y 4 segundos necesita mejora y una puntuación LCP superior a 4 segundos se considera deficiente.

Lo que muestran los datos reales de LCP

CoreDash rastrea millones de mediciones reales de LCP de usuarios cada día. Esto es lo que los datos revelan sobre el rendimiento de LCP en la web.

LCP de imagen vs LCP de texto

Las páginas con elementos LCP basados en imágenes tienen un percentil 75 de LCP de 744ms, casi el doble de lento que los elementos LCP basados en texto con 388ms. Esto confirma que la optimización de imágenes es el área con mayor impacto para mejorar las puntuaciones de LCP. Si su elemento LCP es una imagen, necesita ser particularmente agresivo con la optimización.

El impacto del preloading y lazy loading

Las imágenes LCP con preload alcanzan 100% de puntuaciones "buenas" con un percentil 75 de 364ms. En contraste, las imágenes LCP con lazy loading están entre las más lentas con 720ms, con 4,3% de cargas de página calificadas como "deficientes". Las imágenes sin preload rinden casi igual de mal con 752ms. La conclusión es clara: haga preload de su imagen LCP y nunca le aplique lazy loading.

LCP en móvil vs escritorio

El LCP en móvil (764ms en el percentil 75) es 2 veces más lento que el LCP en escritorio (380ms). Esta brecha es impulsada por redes móviles más lentas y procesadores móviles menos potentes. Dado que Google usa indexación mobile-first, optimizar para LCP en móvil debería ser la prioridad.

Estadísticas globales de LCP

Según el HTTP Archive Web Almanac 2025, el 62% de las páginas móviles a nivel global logran una buena puntuación LCP (menos de 2,5 segundos), frente al 44% en 2022. LCP sigue siendo el Core Web Vital más difícil de pasar y es el cuello de botella principal para las puntuaciones generales de CWV. Además, el 73% de los elementos LCP en móvil son imágenes, y el 16% de los sitios móviles aplican erróneamente lazy loading a su imagen LCP.

Cómo se mide el LCP: Las cuatro fases clave

Según Google, el Largest Contentful Paint puede desglosarse en 4 subpartes. Entender qué fase está causando el cuello de botella es esencial para una optimización eficiente, porque cada fase requiere una solución completamente diferente. Un Time to First Byte (TTFB) lento necesita trabajo del lado del servidor, mientras que un retraso en la carga de recursos necesita cambios en su HTML.

El tiempo final de LCP de una página no es un valor único y monolítico. Es la suma de cuatro subpartes distintas. Entender este desglose es la clave para diagnosticar y corregir problemas de LCP eficientemente.

Aquí hay un desglose de las cuatro fases:

• Time to First Byte (TTFB): Este es puro tiempo de respuesta del servidor. Cubre todo, desde la búsqueda DNS, pasando por la conexión TCP/TLS, hasta el momento en que el navegador recibe el primer byte del documento HTML. Un TTFB lento es un problema fundamental que siempre matará su LCP. En la web, los sitios con LCP deficiente gastan un promedio de 2,27 segundos solo en TTFB, que es casi todo el umbral de 2,5 segundos. Optimizar el TTFB implica caché del lado del servidor, configuración de CDN y código backend eficiente.
• Resource Load Delay: Esta es la "brecha de descubrimiento". Mide el tiempo entre la finalización del TTFB y el momento en que el navegador realmente comienza a descargar el recurso LCP. Un largo retraso aquí significa que el navegador encontró el recurso LCP tarde. Este es el síntoma clásico de usar imágenes de fondo CSS (que el escáner de precarga no puede descubrir) o renderización del lado del cliente (donde el elemento LCP solo aparece después de que JavaScript se ejecuta). La solución es asegurar que su elemento LCP esté en el HTML inicial y precargar la imagen LCP si el navegador no puede descubrirla lo suficientemente temprano.
• Resource Load Duration: Es cuánto tiempo tarda en descargar realmente el archivo del recurso LCP (la imagen, fuente o video). Esta fase trata sobre el tamaño del archivo y las condiciones de la red. Optimizar significa usar formatos de imagen modernos como AVIF o WebP, implementar imágenes responsive con srcset y servir activos a través de un CDN con compresión adecuada.
• Element Render Delay: Este es el retraso final. Mide el tiempo entre cuando el recurso LCP termina de descargarse y cuando el elemento se renderiza completamente en pantalla. Este retraso casi siempre es causado por el hilo principal del navegador bloqueado por otras tareas, especialmente el procesamiento de JavaScript. CSS que bloquea la renderización y scripts síncronos son las causas más comunes.

Cada una de estas áreas de enfoque puede optimizarse para mejorar el Largest Contentful Paint. Para entender los pasos que necesita tomar, lea Corregir e identificar problemas de Largest Contentful Paint (LCP).

Errores comunes de LCP

Después de analizar millones de cargas de página a través de CoreDash, tres errores de LCP aparecen con mucha más frecuencia que cualquier otro. Evitar estos llevará a la mayoría de los sitios a una puntuación LCP aprobatoria.

Error 1: Aplicar lazy loading a la imagen LCP

Añadir loading="lazy" a su imagen hero es el error de LCP más común. Lazy loading le dice al navegador que intencionalmente retrase la descarga de la imagen hasta que entre en el viewport. Para su imagen LCP (que ya está en el viewport), esto crea un retraso completamente innecesario. Según los datos de CrUX, el 16% de los sitios móviles cometen este error. Los datos de CoreDash muestran que las imágenes LCP con lazy loading tienen un percentil 75 de 720ms con 4,3% de experiencias deficientes, comparado con 364ms y 0% deficientes para imágenes con preload. Lea nuestra guía completa sobre cómo corregir una imagen LCP con lazy loading.

Error 2: No hacer preload de la imagen LCP

Incluso sin lazy loading, muchos sitios no informan al navegador sobre la imagen LCP lo suficientemente temprano. Si la URL de la imagen solo se descubre después de analizar CSS o ejecutar JavaScript, el navegador desperdicia cientos de milisegundos antes de siquiera comenzar la descarga. La solución es añadir una pista de preload en el <head> de su documento:

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

Esto le dice al navegador que comience a descargar la imagen inmediatamente, sin esperar cálculos de CSS o diseño. Combínelo con fetchpriority="high" para máximo impacto. Aprenda más en nuestra guía para precargar la imagen LCP.

Error 3: Usar una imagen de fondo CSS para el LCP

Las imágenes de fondo CSS cargadas mediante background-image: url(...) son invisibles para el escáner de precarga del navegador. El navegador no puede descubrirlas hasta que ha descargado el HTML, analizado el CSS y construido el árbol de renderizado. Esto añade un retraso significativo en la carga del recurso. Según los datos de CrUX, el 9% de las páginas móviles usan una imagen de fondo CSS como su elemento LCP. La solución es usar una etiqueta estándar <img> en su lugar, con el atributo fetchpriority="high":

<img src="/img/hero.webp"
     alt="Descriptive alt text"
     width="1200"
     height="600"
     fetchpriority="high">

El atributo fetchpriority="high" es una señal directa al navegador de que este recurso de imagen es el de mayor prioridad en la página. Como demostró el caso de estudio de Google Flights, este único atributo puede reducir el LCP en 700ms. Para una comprensión más profunda, vea nuestra guía de priorización de recursos.

Cómo medir el Largest Contentful Paint

El Largest Contentful Paint (LCP) puede medirse con JavaScript puro, datos de laboratorio y herramientas de campo. Ambos tienen sus ventajas y desventajas.

Medir el Largest Contentful Paint con JavaScript

Para medir el Largest Contentful Paint (LCP) usando JavaScript, la API del Performance Observer ofrece una solución rápida. El siguiente fragmento de código demuestra cómo capturar el tiempo y la información del elemento LCP:

new PerformanceObserver((list) => {
    const lcpEntry = list.getEntries().at(-1);
    console.log('LCP value: ', lcpEntry.startTime);
    console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  }).observe({ type: 'largest-contentful-paint', buffered: true });

Este fragmento rastrea la entrada LCP a medida que se reporta, mostrando su marca de tiempo y detalles del elemento en la consola. Para información más extensa, considere usar la biblioteca Web Vitals.

Medir Largest Contentful Paint (LCP) en Chrome DevTools

1. Abra Chrome DevTools presionando Ctrl+Shift+I (o Cmd+Option+I en Mac).
2. Navegue a la pestaña Performance.
3. Recargue la página para ver los Core Web Vitals.

La pestaña Performance de DevTools ahora muestra información sobre los Core Web Vitals, incluyendo el tiempo y el elemento del Largest Contentful Paint.

Medir el Largest Contentful Paint con herramientas de laboratorio y campo

Seamos claros: Los datos de laboratorio y campo sirven para dos propósitos diferentes. Necesita ambos.

• Datos de campo (RUM y CrUX) son los únicos datos que realmente importan para pasar los Core Web Vitals. Es lo que sus usuarios reales experimentan. Google usa estos datos de su conjunto de datos CrUX. Empiece aquí para descubrir si tiene un problema.
• Datos de laboratorio (Lighthouse, etc.) son una prueba controlada. No es lo que Google usa para el ranking, pero es esencial para la depuración. Use esto para descubrir por qué tiene un problema.

Aquí hay una guía rápida de las herramientas esenciales:

Mejorando el Largest Contentful Paint

Optimizar el LCP requiere un enfoque sistemático que aborde las cuatro fases. Cualquier cosa que suceda antes de que el elemento LCP sea pintado, ya sea relacionada con la red o intensiva en CPU, puede impactar la puntuación LCP. No persiga solo una corrección; entienda toda la cadena. Aquí está la estrategia de alto nivel:

• Optimizar el TTFB: Su servidor necesita ser rápido. Si su TTFB es lento, nada más importa. Esto implica caché del lado del servidor, usar un CDN y código backend eficiente. Lea más en nuestra guía para optimizar el TTFB.
• Eliminar el Resource Load Delay: Asegúrese de que el elemento LCP esté en el HTML inicial para que el escáner de precarga del navegador pueda encontrarlo al instante. Evite imágenes de fondo CSS para LCP. Precargue imágenes críticas que se descubren tarde. Aprenda cómo en nuestra guía para corregir el Resource Load Delay.
• Reducir el Resource Load Time: Haga el archivo LCP más pequeño. Esto significa usar formatos de imagen modernos como AVIF, imágenes responsive y compresión adecuada. Vea nuestra guía completa sobre cómo optimizar la imagen LCP. También puede leer sobre cómo redujimos el LCP en un 70% en un proyecto real.
• Acortar el Element Render Delay: Deje de bloquear el hilo principal. Difiera JavaScript no crítico, divida tareas largas y minimice CSS que bloquea la renderización. Esto se cubre en nuestra guía para corregir el Element Render Delay.

Guías relacionadas

Esta página hub cubre el Largest Contentful Paint a alto nivel. Para orientación detallada y práctica sobre cada aspecto de la optimización de LCP, explore estas guías dedicadas:

• Corregir e identificar problemas de LCP: Una guía de diagnóstico paso a paso para encontrar exactamente qué está causando su LCP lento, usando Chrome DevTools, WebPageTest y CoreDash.
• Optimizar la imagen LCP: Todo sobre formatos de imagen, imágenes responsive, compresión y servir la imagen óptima para cada dispositivo.
• Resource Load Delay: Cómo asegurar que el navegador descubra su recurso LCP lo antes posible, incluyendo preloading, fetchpriority y evitar imágenes de fondo CSS.
• Resource Load Duration: Reducir el tiempo de descarga real del recurso LCP mediante optimización del tamaño del archivo, configuración de CDN y compresión moderna.
• Element Render Delay: Eliminar el retraso entre la descarga del recurso y la renderización en pantalla reduciendo el bloqueo del hilo principal por JavaScript y CSS.