Respuesta corta: el Largest Contentful Paint (LCP) indica cuándo se renderiza la imagen, el bloque de texto o el video más grande visible en la pantalla. Se cuenta desde que el visitante empezó a navegar a la página. Un buen LCP es de 2.5 segundos o menos, medido en el percentil 75 de las cargas de página.
Qué cuenta como elemento LCP
Los candidatos son los elementos img, los elementos image dentro de un svg y los videos. En un video cuenta su imagen de portada o su primer fotograma, lo que ocurra primero. Una imagen de fondo cargada con url() también cuenta, aunque un gradiente de CSS no. Y cuentan los elementos de bloque que contienen texto.
En los navegadores basados en Chromium, el LCP deja fuera los elementos con opacidad 0 y los que cubren toda la pantalla y parecen un fondo. También deja fuera las imágenes de relleno de baja entropía. Las herramientas de Google no informan del LCP de páginas cargadas en una pestaña en segundo plano.
Las cuatro partes del LCP
Cada tiempo de LCP se reparte en cuatro partes sin huecos ni solapes entre ellas, y juntas suman el LCP completo.
| Parte | Qué mide | Peso en una página bien optimizada |
|---|---|---|
| Tiempo hasta el primer byte | Desde que empieza la carga hasta el primer byte del HTML | Alrededor del 40% |
| Retraso en la carga de recursos | Desde el primer byte hasta que el navegador empieza a cargar el recurso LCP | Menos del 10% |
| Duración de la carga de recursos | Lo que tarda en cargarse el propio recurso LCP | Alrededor del 40% |
| Retraso en la renderización del elemento | Desde que termina esa carga hasta que el elemento LCP se renderiza del todo | Menos del 10% |
De web.dev, «Optimiza el procesamiento de imagen con contenido más grande», consultada el 3 de noviembre de 2026.
Las dos partes que llevan «retraso» en el nombre deberían acercarse a cero. Si el elemento LCP es un texto con una fuente del sistema, no hay nada que cargar: el retraso y la duración de la carga del recurso son cero.
Cómo mejorar el LCP
- Busca tu elemento LCP en los resultados de laboratorio de PageSpeed Insights, que vienen de Lighthouse.
- Si es una imagen, asegúrate de que el navegador la encuentre en el HTML, o precárgala si solo la cita un archivo CSS o JavaScript.
- Dale a esa imagen un fetchpriority alto para que empiece a cargarse pronto, y resérvalo para una o dos imágenes como mucho.
- Nunca uses carga diferida en la imagen LCP.
- Reduce la imagen, por ejemplo en WebP o AVIF, y sírvela cerca de tus visitantes.
- No ocultes el elemento LCP hasta que corra el JavaScript, y reduce las hojas de estilo que bloquean el renderizado o insértalas en el HTML.
- Baja tu tiempo hasta el primer byte, que afecta a todos los pasos posteriores.
Nuestras guías de la carga diferida de imágenes, de WebP y del TTFB amplían los pasos 4, 5 y 7.
Cómo es el LCP en nuestras páginas
El 3 de noviembre pasamos 4 de nuestras páginas por PageSpeed Insights en el móvil: la de inicio, la del servicio de SEO, la de SEO en Miami y la guía de robots.txt. Las 4 dieron un LCP de 1.2 segundos en la prueba de laboratorio, muy por debajo de los 2.5 segundos. El LCP también cuenta la descarga de la página anterior, la configuración de la conexión y las redirecciones. Con visitantes reales eso puede pesar más, así que los datos de campo pueden no coincidir con los de laboratorio.
En las 4, el elemento LCP era un texto: un titular o un párrafo, no una imagen. El reparto de Lighthouse no mostró ningún recurso que cargar. Por eso el retraso en la renderización del elemento abarcó desde el primer byte del HTML hasta que se pintó el texto: entre el 98% y el 100% del reparto.
Así que en nuestras páginas, un LCP más rápido tiene que salir de ese retraso de renderización, no de las imágenes. Nuestra guía de Core Web Vitals explica cómo encaja el LCP junto al INP y el CLS.
Antes de dar por arreglado tu LCP
- Sabes cuál es el elemento LCP.
- La imagen LCP no usa carga diferida.
- El navegador encuentra la imagen en el HTML.
- La imagen está comprimida y tiene el tamaño justo.
- Nada oculta el elemento hasta que corren los scripts.
- Los datos de campo marcan 2.5 segundos o menos.
RecuerdaEl LCP son cuatro tiempos sumados: el primer byte, la espera antes de cargar el recurso, la carga y el renderizado. Acortar uno solo ayuda si el tiempo no pasa a otro, así que mira los cuatro.
Si quieres páginas que carguen rápido su contenido principal en el teléfono, mira nuestro servicio de diseño web.
Respuestas rápidas sobre el LCP
¿Qué es un buen LCP?
web.dev considera bueno 2.5 segundos o menos. Para cumplirlo con la mayoría de los usuarios, mide el percentil 75 de las cargas de página, con el móvil y la computadora por separado.
¿Un texto puede ser el elemento LCP?
Sí. Además de imágenes, video e imágenes de fondo, cuentan los elementos de bloque con texto. Si el texto usa una fuente del sistema, no hay que descargar nada para él, así que el retraso y la duración de la carga del recurso son cero. Con una fuente web, la fuente puede ser el recurso LCP.
¿Debo diferir la carga de mi imagen principal?
No si es tu imagen LCP. web.dev advierte que nunca uses carga diferida en la imagen LCP, porque siempre añade retraso en la carga del recurso. Déjala con la carga normal y, si empieza tarde, súbele la prioridad con fetchpriority.
¿Por qué una imagen más pequeña no mejoró mi LCP?
Porque el tiempo puede pasar a otra parte. web.dev muestra una página donde comprimir la imagen acortó la carga, pero el elemento seguía oculto hasta que corría el JavaScript, así que el LCP no cambió.
¿Necesito un reparto perfecto?
No. Los porcentajes son pautas, no reglas estrictas. Si tu LCP se queda en 2.5 segundos o menos, el reparto importa menos; los retrasos largos son los que hacen difícil llegar a la meta.
Fuentes
Consultadas el 3 de noviembre de 2026. web.dev: Largest Contentful Paint (LCP) y Optimiza el procesamiento de imagen con contenido más grande. Nuestro caso: 4 de nuestras páginas en PageSpeed Insights en el móvil, el 3 de noviembre de 2026.