La optimización LCP consiste en bajar tu Largest Contentful Paint de 2,5 segundos en el 75% de las visitas reales. El camino más rápido no es perseguir la puntuación de Lighthouse: divides el LCP en sus cuatro fases —time to first byte, retraso de carga del recurso, duración de carga del recurso y retraso de renderizado del elemento—, identificas cuál se lleva más milisegundos y arreglas esa. Todo lo demás es adivinar con buena presentación.
La mayoría de equipos aborda la optimización LCP al revés. Pasan PageSpeed Insights, ven un número en rojo y empiezan a bajar por la lista de “Oportunidades” de arriba abajo. Seis semanas después la puntuación de laboratorio está en verde, los datos de campo no se han movido y nadie sabe explicar por qué. Esta guía cubre qué mide realmente el LCP, cómo encontrar el cuello de botella real en unos quince minutos y los arreglos que sí mueven los datos de campo.
Qué mide realmente el LCP
El Largest Contentful Paint registra el momento en que la imagen o el bloque de texto más grande visible en el viewport termina de pintarse. Es el sustituto que usa Google para “la página ya parece cargada para una persona”.
El umbral de Google son 2,5 segundos o menos, medidos en el percentil 75 de las cargas reales, no en la media. Esa distinción importa más de lo que parece. Un sitio con una mediana de 1,8 segundos y una cola larga de sesiones móviles lentas puede suspender con holgura, porque el percentil 75 lo arrastra el peor cuarto de las visitas. Optimizar la mediana no hace nada por esa URL. Hay que arreglar la cola.
La medición que Google usa de verdad viene del Chrome UX Report, que agrega datos de campo anonimizados de usuarios reales de Chrome en una ventana móvil de 28 días. Eso es lo que aparece en Search Console y lo que alimenta la señal de experiencia de página documentada en la guía de Core Web Vitals de Google. Tu puntuación de Lighthouse es una herramienta de diagnóstico. No es la métrica.
Un detalle más que despista a mucha gente: el LCP no es definitivo hasta que el usuario interactúa. El navegador va actualizando el elemento candidato mientras carga la página y fija el valor en el primer clic, toque o pulsación de tecla. Por eso las imágenes de cabecera que cargan tarde cuentan enteras, y poner lazy loading a la imagen LCP es uno de los autogoles más habituales que veo.
Las cuatro fases: dónde se va tu tiempo de LCP
Este es el framework más útil de toda la optimización LCP, y viene directamente de Google. Cualquier medición de LCP se descompone en cuatro fases consecutivas:
- Time to first byte (TTFB): desde el inicio de la navegación hasta que llega el primer byte del documento HTML.
- Retraso de carga del recurso: desde el TTFB hasta que el navegador empieza a descargar el recurso LCP.
- Duración de carga del recurso: lo que tarda esa descarga.
- Retraso de renderizado del elemento: desde que el recurso termina de descargarse hasta que se pinta de verdad.
La guía de optimización de LCP de Google en web.dev marca un reparto objetivo: en torno al 40% del presupuesto en TTFB, en torno al 40% en duración de carga del recurso y por debajo del 10% en cada una de las dos fases de retraso. Los retrasos son desperdicio puro: tiempo en el que no se descarga nada y no se pinta nada. Si cualquiera de los dos se está comiendo el 25% o el 40% de tu LCP, ya has encontrado el problema y todavía no has tocado ni una imagen.
Ese encuadre cambia el trabajo por completo. “Comprime las imágenes” es un consejo inútil para una página con 3,8 segundos de LCP y 2,1 segundos de retraso de carga del recurso. La imagen no es lenta; el navegador no supo que la necesitaba hasta demasiado tarde.
Ten en cuenta que en la mayoría de páginas el elemento LCP es una imagen: una cabecera, una foto de producto, un banner de fondo. Los elementos LCP de texto suelen ser más fáciles, porque el texto se pinta en cuanto se resuelve la tipografía, lo que colapsa dos de las cuatro fases.
Cómo diagnosticar el LCP en 15 minutos
No saltes directamente a los arreglos. Sigue este proceso de cinco pasos y sabrás exactamente qué fase atacar.
- Saca los datos de campo. Abre Search Console → Core Web Vitals → Móvil e identifica los grupos de URL que suspenden. Después pasa esas URLs representativas por PageSpeed Insights y lee solo el bloque superior, el de datos de campo de CrUX. Ignora de momento la sección de laboratorio.
- Identifica el elemento LCP. En Chrome DevTools abre Performance, aplica throttling a 4G lenta y CPU 4x, recarga y lee el marcador LCP en la pista Timings. Apunta qué elemento es.
- Desglosa las cuatro fases. Lo más cómodo es la librería JavaScript
web-vitals, que reporta el LCP con atribución de las cuatro fases. Alternativamente puedes leerlas en la cascada de red de DevTools: el TTFB es la respuesta del documento, el retraso de carga es el hueco entre la llegada del documento y el inicio de la petición del recurso LCP, y así sucesivamente. - Busca la fase más grande. La que se lleve más milisegundos es tu proyecto. Todo lo demás es distracción hasta que esa esté arreglada.
- Revisa la ruta de descubrimiento. Pregúntate cómo se entera el navegador de que existe el recurso LCP. ¿Es un
<img>normal en el HTML inicial? ¿Lo inyecta JavaScript? ¿Es unbackground-imagede CSS? La respuesta suele explicar por sí sola un retraso de carga alto.
Por mi experiencia auditando ecommerce y SaaS, el paso cinco es donde aterriza el diagnóstico más veces que no. La imagen está bien. Lo que está roto es el descubrimiento: la cabecera está puesta como fondo CSS, o la pinta un componente en cliente, así que el preload scanner nunca la ve y la descarga no arranca hasta que el hilo principal ya está ocupado.
Optimización LCP para TTFB y retraso de carga
En estas dos fases están las victorias baratas, y son justo donde casi nadie mira.
Para el TTFB, el orden de impacto es siempre el mismo. Sirve HTML cacheado desde el edge de un CDN en lugar de generarlo en cada petición: es la palanca de TTFB más grande para la mayoría de sitios y suele recortar cientos de milisegundos. Después elimina las cadenas de redirecciones; cada salto añade un round trip completo, y una cadena http → https → www puede costar 400 ms en móvil antes de que el servidor haga nada. Luego arregla las consultas lentas de backend y activa la compresión. Si tu TTFB pasa de 800 ms, nada de lo que venga después te va a salvar.
Para el retraso de carga del recurso, los arreglos son mecánicos:
- Pon la imagen LCP en el HTML inicial como una etiqueta
<img>real, para que el preload scanner del navegador la encuentre antes de que el parser llegue hasta ahí. - Añade
fetchpriority="high"a la imagen LCP. Le dices al navegador que la promocione por encima del resto de imágenes que compiten por el ancho de banda, y muchas veces vale varios cientos de milisegundos por sí solo. - No pongas nunca
loading="lazy"en una imagen visible sin hacer scroll. Es el autogol de LCP más común que hay. - Si el recurso LCP es un
background-imagede CSS o viene de un tercero, añade<link rel="preload">con los atributosasyfetchprioritycorrectos. - Elimina los recursos que bloquean el renderizado por delante. Cada hoja de estilos síncrona y cada script bloqueante en el
<head>retrasa el descubrimiento y la descarga de todo lo que viene detrás.
Bajar el retraso de carga por debajo del 10% del LCP total suele ser trabajo de un sprint, y es la mejor relación entre impacto y esfuerzo de toda la disciplina. Si quieres una pasada estructurada por todo esto, entra dentro del alcance estándar de una auditoría de SEO técnico.
Optimización LCP para duración de carga y renderizado
Una vez arreglado el descubrimiento, lo que queda es transferencia y pintado de verdad.
La duración de carga del recurso se reduce a bytes y conexión. Usa formatos modernos —AVIF o WebP antes que JPEG— y dimensiona la imagen al viewport más grande que la vaya a mostrar de verdad, con srcset y sizes para que un móvil no descargue nunca una cabecera de 2400px. Añade <link rel="preconnect"> para cualquier origen de terceros que sirva el recurso LCP: te ahorras los round trips de DNS, TCP y TLS. Pasar una cabecera de 400 KB a 90 KB es lo normal y vale cerca de un segundo en una conexión móvil media.
El retraso de renderizado del elemento casi siempre es JavaScript o tipografías. Si el elemento LCP es texto, una fuente cargada con font-display: block puede secuestrar el pintado hasta tres segundos: cámbialo a swap u optional y haz preload del archivo. Si el elemento LCP vive dentro de un componente renderizado en cliente, el navegador no puede pintarlo hasta que el bundle se descargue, se parsee y se hidrate; renderiza esa parte en servidor o pre-renderízala estáticamente. Revisa también si hay long tasks bloqueando el hilo principal justo cuando aterriza el recurso, porque una imagen descargada del todo sigue sin poder pintarse con el hilo principal ocupado. Esas long tasks suelen ser las mismas que te hunden el INP, así que el trabajo se acumula a tu favor.
Por qué el laboratorio y el campo no coinciden
Te vas a topar con esto el primer día, así que cuenta con ello.
Lighthouse simula una carga, en un dispositivo emulado, desde una ubicación, con caché fría y sin banner de cookies, sin script de tests A/B, sin widget de chat y sin sesión iniciada. Los datos de campo son todas las visitas reales: Android antiguos, redes congestionadas, etiquetas de terceros que solo se disparan en producción y usuarios que entran a mitad de sesión con la caché caliente. Los dos números miden cosas distintas y no van a converger.
Usa el laboratorio para diagnosticar: es el único sitio donde ves una cascada y puedes atribuir tiempo a un recurso concreto. Usa el campo para el veredicto. Y ten paciencia con el veredicto: como CrUX agrega en una ventana móvil de 28 días, el día que despliegas el arreglo tu LCP reportado todavía contiene 27 días de datos previos. Es habitual que un equipo concluya al tercer día que el arreglo “no ha funcionado” y lo revierta. Pon la fecha de revisión a cuatro semanas y no lo toques.
Si un grupo de URLs no tiene volumen suficiente para reportar en campo, monitoriza con real user monitoring. Cualquier montaje de RUM con la librería web-vitals te da la misma atribución de cuatro fases sobre tu propio tráfico, con la muestra que tengas.
Qué vale realmente la optimización LCP
Sé honesto con tus stakeholders en esto, porque venderlo de más rompe la confianza cuando la subida de posiciones no llega.
Los Core Web Vitals son una señal de posicionamiento real, pero débil. Funcionan como desempate entre páginas de relevancia y autoridad parecidas. Una página rápida no va a superar a una página objetivamente mejor, y nunca he visto un arreglo de LCP rescatar a un sitio con un problema de contenido o de enlaces. Si tu tráfico cae por otros motivos, el LCP no es la palanca: ese es otro diagnóstico, y normalmente empieza por una auditoría SEO completa y no por un sprint de rendimiento.
El argumento fuerte es comercial. Los usuarios abandonan las páginas lentas antes de ver nada, así que cada cien milisegundos de LCP se pagan en rebote y conversiones perdidas justo sobre el tráfico que más te ha costado conseguir. Ese argumento aguanta delante de un director financiero como no lo hace “puede que ayude al posicionamiento”.
Así que secuéncialo bien. Arregla primero los problemas críticos de rastreo e indexación, deja el LCP y el resto de vitals en verde como mínimo exigible y mete el presupuesto de verdad en contenido y enlaces. Si suspendes más de un vital, empieza por el Cumulative Layout Shift: es el más barato de los tres y rara vez exige tocar infraestructura. Si quieres una segunda opinión sobre dónde encaja la optimización LCP en tu lista de prioridades concreta, es el tipo de decisión que ayudo a tomar como consultor SEO freelance; casi siempre la respuesta es que la optimización LCP merece cuatro semanas de foco, y ni un día más.
Preguntas frecuentes
¿Qué es un buen valor de LCP?
Google considera bueno un LCP de 2,5 segundos o menos, necesita mejorar entre 2,5 y 4,0 segundos, y deficiente por encima de 4,0 segundos. El umbral se aplica al percentil 75 de las cargas reales, así que una cuarta parte de tus visitas puede ir más lenta de 2,5 segundos y la URL sigue aprobando. Las puntuaciones de laboratorio de Lighthouse no cuentan.
¿Cómo encuentro mi elemento LCP?
Abre Chrome DevTools, graba una traza en Performance y mira el marcador LCP en la pista Timings: te nombra el elemento exacto. PageSpeed Insights también lo indica en el diagnóstico de LCP. En la mayoría de páginas es una imagen de cabecera, un banner o el bloque de texto más grande visible sin hacer scroll.
¿Por qué mi LCP es bueno en Lighthouse y malo en Search Console?
Lighthouse ejecuta una prueba de laboratorio simulada, en un dispositivo, desde una ubicación y con caché fría. Search Console muestra datos de campo del Chrome UX Report: visitas reales, con dispositivos y redes reales, en una ventana móvil de 28 días. Los datos de campo incluyen móviles lentos, conexiones malas y scripts de terceros que tu prueba de laboratorio nunca cargó, así que casi siempre son peores, y son los únicos que Google usa.
¿El LCP afecta al posicionamiento en Google?
Sí, pero de forma débil. Los Core Web Vitals son una señal de experiencia de página que funciona como desempate entre páginas de relevancia y autoridad parecidas: no van a colocar una página floja por encima de una buena. El argumento fuerte para la optimización LCP es la conversión, porque una página lenta pierde usuarios antes de que lleguen a ver el contenido.
¿Cuánto tardan las mejoras de LCP en verse en Search Console?
Unos 28 días para el efecto completo. El Chrome UX Report agrega una ventana móvil de 28 días, así que el día que despliegas el arreglo tu LCP reportado todavía contiene 27 días de datos antiguos. Deberías ver movimiento en la primera semana y la cifra definitiva el día 28: no juzgues un arreglo antes de eso.
