LCP alto: cómo identificarlo y corregirlo rápido
En resumen:
- Un LCP alto indica que la mayor parte del contenido visible tarda más de 2,5 segundos en cargarse, afectando la velocidad y el SEO. La prioridad es reducir subpartes como TTFB, carga de recursos y bloqueos en el render mediante acciones específicas y técnicas de optimización. Validar en campo y coordinar los equipos es clave para mejorar el rendimiento y cumplir los umbrales recomendados.
Resumen del artículo sobre el LCP alto
Un LCP alto significa que el mayor elemento visible de la página tarda más de 2,5 segundos en renderizarse, lo que afecta directamente a la percepción de velocidad, la tasa de rebote y el posicionamiento en buscadores. Este artículo explica qué causa ese retraso, cómo medirlo con herramientas como PageSpeed Insights, Lighthouse, Chrome DevTools, WebPageTest y CrUX, y cómo corregirlo con un workflow priorizado por impacto y esfuerzo. Se incluyen fragmentos de código reproducibles, una tabla de diagnóstico rápido y un proceso paso a paso para equipos de marketing y desarrollo.
Un LCP (Largest Contentful Paint) de 2,5 segundos o menos es considerado «bueno» según Google; entre 2,5 y 4 segundos, indica que «necesita mejora» y por encima de 4 segundos entra en zona «deficiente». Todos los valores se evalúan en el percentil 75 de visitas reales recogidas por CrUX, es decir, tres de cada cuatro sesiones deben cumplir el umbral para que el sitio se considere en buen estado.
Antes de entrar en la causa raíz, hay tres acciones que suelen reducir el LCP en minutos:
- Precargar la imagen o recurso principal con
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">directamente en el<head>. - Convertir la imagen a WebP o AVIF y servir tamaños responsivos con
srcset/sizespara reducir el peso descargado. - Mover los scripts no críticos a
deferoasyncpara liberar el hilo principal antes del primer render.
Si el LCP sigue alto tras estas tres acciones, el problema suele estar en el TTFB del servidor o en un «element render delay» causado por tareas largas de JavaScript. El resto del artículo desglosa cada causa y su solución.
👉 Si necesitas descargarte infografías sobre LCP alto, descuentos en cursos y herramientas y mucho más puedes hacerlo aquí: descargar infografías y recursos
Tabla de contenidos
- Tabla resumen: causas frecuentes y acciones priorizadas
- ¿Cómo medir LCP en campo y en laboratorio?
- ¿Cuáles son las cuatro causas técnicas de un LCP alto?
- Técnicas concretas para reducir cada subparte del LCP
- Workflow práctico para auditar y priorizar un LCP alto
- Herramientas y comandos para diagnosticar LCP
- Conclusiones
- Puntos clave
- El LCP alto que nadie quiere ver en su informe
- LG DataOne: auditoría de LCP y CRO con datos reales
- Fuentes útiles y lectura recomendada
- Preguntas frecuentes
Tabla resumen: causas frecuentes y acciones priorizadas
Consejo profesional: Usa esta tabla como checklist de auditoría antes de abrir cualquier herramienta. Identifica la fila que describe tu síntoma y ejecuta primero la acción de mayor prioridad.
| Causa | Acción rápida (quick win) | Acción técnica siguiente | Prioridad | Tiempo estimado de mejora |
|---|---|---|---|---|
| TTFB alto del servidor | Activar caché de página completa (ej. LiteSpeed Cache en WordPress) | Configurar CDN con edge caching; revisar consultas lentas de base de datos | Alto | Horas–1 día |
| Recurso LCP no descubierto pronto | Añadir | Mover referencia al recurso al HTML estático; evitar carga desde JS | Alto | Minutos–horas |
| Imagen pesada sin comprimir | Convertir a WebP/AVIF y reducir dimensiones al tamaño de visualización | Implementar srcset/sizes; integrar optimización en pipeline de build | Alto | Horas |
| CSS bloqueante (render-blocking) | Extraer CSS crítico e incluirlo inline en el | Cargar el resto del CSS con media="print" + onload o con herramientas de critical CSS | Medio | 1–2 días |
| JavaScript bloqueante | Añadir defer o async a scripts no críticos | Dividir bundles; eliminar scripts de terceros innecesarios | Alto | Horas–1 día |
| Fuentes web bloqueantes | Añadir font-display: swap en la declaración @font-face | Precargar solo las fuentes del primer viewport; subconjuntar con unicode-range | Medio | Horas |
| Lazy-loading en el elemento LCP | Eliminar loading="lazy" de la imagen hero | Revisar configuración del CMS o plugin que aplica lazy-loading global | Alto | Minutos |
¿Cómo medir LCP en campo y en laboratorio?
La distinción entre medición de campo y de laboratorio es práctica, no académica. Cada una responde a una pregunta distinta.
Medición de campo: lo que experimentan tus usuarios reales
El campo recoge datos de usuarios reales a través de CrUX (Chrome User Experience Report), que alimenta el informe de Core Web Vitals en Google Search Console. La ventaja es que refleja variabilidad real: dispositivos, conexiones, ubicaciones geográficas. La limitación es que los datos tardan varios días en actualizarse y no permiten depurar causas en tiempo real.
Para sitios con tráfico suficiente, Search Console muestra el LCP segmentado por móvil y escritorio. En Europa Central, donde la penetración de móvil es alta y las velocidades de red varían entre países, segmentar por dispositivo es especialmente útil para priorizar.
La alternativa más flexible es instrumentar RUM (monitorización de usuarios reales) directamente con la API del navegador:
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('LCP candidate:', entry.startTime, entry.element);
}
}).observe({ type: 'largest-contentful-paint', buffered: true });
Este fragmento captura el candidato LCP y el elemento concreto que lo dispara, lo que permite identificar si es una imagen, un bloque de texto o un vídeo.
¿Cuáles son las cuatro causas técnicas de un LCP alto?
La metodología oficial de optimización de LCP descompone el tiempo total en cuatro subpartes. En páginas bien optimizadas, la distribución orientativa es: TTFB ≈ 40 %, duración de carga del recurso ≈ 40 %, y los dos «delays» (retraso de carga del recurso y retraso de render del elemento) por debajo del 10 % cada uno. Cuando alguna subparte supera ese peso relativo, ahí está el problema.
TTFB: el servidor responde tarde
El TTFB (Time to First Byte) es el tiempo que tarda el servidor en enviar el primer byte de la respuesta HTML. Un TTFB alto retrasa todo lo demás: el navegador no puede descubrir ningún recurso hasta que recibe el HTML. Causas habituales: servidor sin caché de página, consultas de base de datos lentas, hosting compartido saturado o ausencia de CDN.
Retraso en la carga del recurso (resource load delay)
El recurso LCP existe en el HTML, pero el navegador no lo descubre hasta tarde porque está referenciado desde CSS o JavaScript en lugar de estar en el HTML estático. Cada milisegundo que el navegador tarda en descubrir el recurso se suma al LCP.
Duración de la carga del recurso (resource load duration)
El recurso se descarga, pero tarda mucho porque es demasiado pesado, no está comprimido o el servidor no tiene políticas de caché adecuadas. Una imagen JPEG de 800 KB donde debería haber un WebP de 80 KB es el ejemplo más frecuente.
Retraso de render del elemento (element render delay)
El recurso ya se descargó, pero el navegador no puede pintarlo porque el hilo principal está bloqueado por tareas largas de JavaScript o por CSS no procesado. Este es el caso más difícil de detectar porque los síntomas superficiales (minificar CSS, comprimir imágenes) no lo resuelven.
Cuando las optimizaciones habituales no mueven el LCP, el problema casi siempre está en el element render delay. Revisar las «long tasks» en el panel Performance de Chrome DevTools y buscar scripts de terceros que bloqueen el hilo principal antes del primer render suele revelar la causa real.
Checklist de diagnóstico por subparte:
- Mide el TTFB con
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s " https://ejemplo.com. Si supera 0,6 s, el problema está en el servidor. - En la cascada de WebPageTest, comprueba cuándo aparece la primera solicitud del recurso LCP. Si hay un gap grande entre el inicio de la navegación y esa solicitud, el recurso no está en el HTML estático.
- En Lighthouse, revisa el tamaño del recurso LCP. Si supera 200 KB para una imagen, hay margen de compresión.
- En DevTools (panel Performance), busca tareas largas (bloques rojos) que ocurran después de que el recurso LCP termine de descargarse. Si existen, el render está bloqueado.
Técnicas concretas para reducir cada subparte del LCP
Reducir el TTFB
La primera línea de acción es activar caché de página completa. En instalaciones WordPress, LiteSpeed Cache gestiona caché de objetos, caché de página y optimización de imágenes desde un único plugin. Para entornos más complejos, un CDN con edge caching (Cloudflare, Fastly, Bunny.net) reduce la latencia para usuarios en Europa Central al servir el HTML desde un nodo geográficamente próximo.
Si el TTFB sigue alto tras activar caché, el siguiente paso es revisar consultas lentas de base de datos con herramientas de APM o el log de consultas lentas del servidor.
Hacer el recurso LCP descubrible cuanto antes
El navegador solo puede empezar a descargar el recurso LCP cuando lo encuentra en el HTML. Si la imagen hero se carga desde JavaScript o desde CSS como background-image, el navegador la descubre tarde. La solución más directa es añadir una etiqueta <link rel="preload"> en el <head>:
<link rel="preload" as="image"
href="hero.webp"
imagesrcset="hero-400.webp 400w, hero-800.webp 800w"
imagesizes="(max-width: 600px) 400px, 800px"
fetchpriority="high">
El atributo fetchpriority="high" indica al navegador que este recurso tiene prioridad sobre otros en la cola de descarga.
Reducir el peso del recurso LCP
Convertir imágenes a AVIF o WebP reduce el tamaño entre un 30 % y un 50 % respecto a JPEG equivalente sin pérdida perceptible de calidad. Combinado con srcset y sizes, el navegador descarga solo la resolución necesaria para el dispositivo:
<img src="hero.webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
alt="Descripción del hero"
fetchpriority="high"
width="1200" height="600">
Incluir width y height explícitos evita además un CLS alto al reservar el espacio antes de que la imagen cargue.
Eliminar el bloqueo de render (element render delay)
El CSS bloqueante se resuelve extrayendo el CSS crítico (el necesario para el primer viewport) e incluyéndolo inline en el <head>. Herramientas como Critical o PurgeCSS automatizan este proceso en el pipeline de build.
Para JavaScript, la regla es sencilla: cualquier script que no sea necesario para el primer render debe llevar defer o async. Los scripts de terceros (analytics, chat, publicidad) son los candidatos más frecuentes a diferir.
Las fuentes web bloqueantes se corrigen con font-display: swap en la declaración @font-face y precargando solo las fuentes del primer viewport:
<link rel="preload" as="font" href="fuente-principal.woff2"
type="font/woff2" crossorigin>
Consejo profesional: Cuando la optimización tradicional no reduce el LCP, abre el panel Performance de Chrome DevTools, graba una carga y busca «long tasks» (tareas que superan 50 ms) que ocurran después de que el recurso LCP termine de descargarse. La solución suele ser dividir o diferir la ejecución de JavaScript, no comprimir más imágenes.
Workflow práctico para auditar y priorizar un LCP alto
Un proceso reproducible evita que el equipo pierda tiempo depurando síntomas en lugar de causas. El siguiente workflow está diseñado para completarse en un sprint de una o dos semanas.
Fase 1: recoger datos de campo Abre el informe de Core Web Vitals en Google Search Console y filtra por URLs con LCP deficiente o que necesita mejora. Anota el percentil 75 actual y segmenta por dispositivo.
Fase 2: identificar el candidato LCP Ejecuta PageSpeed Insights en las URLs problemáticas. El informe muestra el elemento LCP con su URL, tamaño y tiempo de carga. Confirma el candidato con el panel Performance de Chrome DevTools.
Fase 3: reproducir en laboratorio Ejecuta Lighthouse CLI o WebPageTest con una ubicación de prueba en Europa Central (Frankfurt o Ámsterdam). Guarda el informe como línea base para comparar después de los cambios.
Fase 4: generar hipótesis de causa Usa la tabla de diagnóstico de la sección anterior para asignar el problema a una subparte (TTFB, resource load delay, resource load duration o element render delay).
Fase 5: priorizar por impacto y esfuerzo
| Cambio | Impacto estimado | Esfuerzo (horas) | Riesgo de regresión | Responsable |
|---|---|---|---|---|
| Eliminar lazy-loading del hero | Alto | 0,5 | Bajo | Frontend |
| Añadir preload de imagen hero | Alto | 1 | Bajo | Frontend |
| Convertir hero a WebP + srcset | Alto | 2–4 | Bajo | Frontend / Marketing |
| Activar caché de página (CDN) | Alto | 4–8 | Medio | DevOps |
| Diferir scripts de terceros | Medio | 2–4 | Medio | Frontend |
| Extraer e inline critical CSS | Medio | 4–8 | Medio | Frontend |
Fase 6: desplegar cambios incrementales y validar Despliega un cambio a la vez y mide en laboratorio antes de pasar al siguiente. Tras una semana de tráfico real, comprueba si el percentil 75 en CrUX ha mejorado.
Caso de ejemplo: una página de producto en un ecommerce tenía el hero referenciado solo desde CSS como background-image. El navegador lo descubría 1,2 segundos después del inicio de navegación. La solución fue mover la imagen a un <img> con fetchpriority="high" y convertirla a WebP responsivo. El resultado en laboratorio fue una reducción de 1,8 segundos en el LCP. En CrUX, el percentil 75 pasó de 4,3 s a 2,6 s en el ciclo de datos siguiente.
Gobernanza entre equipos: los cambios en imágenes y contenido del hero los gestiona marketing; los cambios en CDN y configuración de servidor los gestiona DevOps; los cambios en HTML, CSS y JavaScript los gestiona el equipo de desarrollo frontend. Definir este reparto antes de la auditoría evita bloqueos durante la ejecución.
Herramientas y comandos para diagnosticar LCP
Herramientas de campo
- Google Search Console (informe Core Web Vitals): — muestra el LCP del percentil 75 segmentado por dispositivo, con las URLs agrupadas por estado. Es el punto de entrada para cualquier auditoría.
Comandos y fragmentos útiles
Medir el TTFB desde la línea de comandos:
curl -o /dev/null -s -w
"DNS: %{time_namelookup}s | Connect: %{time_connect}s | TTFB: %{time_starttransfer}s
"
https://ejemplo.com
Ejecutar Lighthouse en modo CI con presupuesto de rendimiento:
npx lighthouse https://ejemplo.com
--budget-path=./budget.json
--output=html
--output-path=./report.html
--chrome-flags="--headless --no-sandbox"
Consejo profesional: Para equipos en Europa Central, configura WebPageTest con el agente de Frankfurt o Ámsterdam y una conexión simulada de «4G» (9 Mbps / 9 Mbps / 170 ms RTT). Esas condiciones representan mejor la experiencia real de usuarios en la región que las pruebas desde servidores en EE. UU.
Conclusiones
Reducir un LCP alto es un proceso sistemático, no una lista de trucos. El punto de partida es siempre el mismo: identificar el elemento LCP concreto, medir en qué subparte se pierde más tiempo y aplicar la corrección de mayor impacto primero.
Las tres tácticas con mejor ratio impacto/esfuerzo son eliminar el lazy-loading del hero, añadir un preload con fetchpriority="high" y convertir la imagen a WebP o AVIF con srcset. Juntas, suelen mover el LCP varios segundos en una sola sesión de trabajo.
El objetivo medible es claro: llevar el percentil 75 de LCP por debajo de 2,5 segundos en CrUX, tanto en móvil como en escritorio. La validación requiere datos de campo reales, no solo laboratorio, porque las condiciones de red y dispositivo de los usuarios reales en Europa Central difieren de las simulaciones.
Coordinar marketing (imágenes y contenido del hero), DevOps (CDN y TTFB) y desarrollo frontend (JS, CSS y fuentes) desde el inicio del sprint es lo que determina si las mejoras se despliegan en días o en semanas.
Puntos clave sobre el LCP alto
Un LCP por encima de 2,5 segundos afecta a la percepción de velocidad, la tasa de conversión y el posicionamiento orgánico; reducirlo requiere identificar la subparte problemática y aplicar correcciones priorizadas por impacto y esfuerzo.
| Punto | Detalles |
|---|---|
| Umbrales oficiales LCP | Bueno ≤ 2,5 s; deficiente > 4 s, evaluados en el percentil 75 de visitas reales (CrUX). |
| Primera acción de mayor impacto | Eliminar loading="lazy" del hero y añadir <link rel="preload" fetchpriority="high"> reduce LCP en minutos. |
| Cuatro subpartes del LCP | TTFB, resource load delay, resource load duration y element render delay; cada una tiene una causa y solución distintas. |
| Validación obligatoria en campo | Las mejoras de laboratorio deben confirmarse en CrUX o con RUM; el percentil 75 es el indicador de éxito. |
| LG DataOne como apoyo | LG DataOne automatiza la auditoría de LCP, prioriza correcciones por impacto y monitoriza el percentil 75 en tiempo real. |
El LCP alto que nadie quiere ver en su informe
Hay una trampa frecuente en los proyectos de optimización de rendimiento: el equipo dedica dos semanas a minificar CSS, comprimir imágenes y activar Gzip, publica los cambios con satisfacción y el LCP en CrUX no se mueve ni medio segundo. La frustración es comprensible, pero el diagnóstico suele ser el mismo: se optimizó la parte equivocada.
El element render delay es la subparte más ignorada del LCP precisamente porque no aparece de forma obvia en los informes de PageSpeed. Un script de analítica de terceros que ejecuta 400 ms de JavaScript antes del primer paint, un bundle de React que bloquea el hilo principal durante la hidratación, o un CSS de 800 KB que el navegador debe parsear entero antes de pintar cualquier cosa: ninguno de estos problemas se resuelve convirtiendo imágenes a WebP.
La lección práctica es que el diagnóstico debe preceder siempre a la optimización. Abrir el panel Performance de Chrome DevTools, grabar una carga en condiciones de red móvil y buscar las tareas largas que ocurren después de que el recurso LCP termina de descargarse tarda menos de diez minutos. Ese tiempo es la diferencia entre un sprint que mueve el percentil 75 y uno que no.
Otro punto que los equipos subestiman: la coordinación entre roles. Marketing sube una imagen hero de 2 MB sin comprimir porque «se ve mejor». DevOps activa un CDN pero no configura el edge caching para HTML. Desarrollo frontend añade un preload pero lo hace después del tercer script de terceros en el <head>. Ninguna de esas acciones aisladas es suficiente. El LCP es una métrica de sistema, y mejorarla requiere que los tres equipos trabajen sobre el mismo diagnóstico al mismo tiempo.
LG DataOne: auditoría de LCP y CRO con datos reales
Muchos equipos llegan a la auditoría de LCP con datos fragmentados: Lighthouse en local, PageSpeed Insights de vez en cuando y Search Console revisado cada mes. El resultado es que las mejoras se despliegan sin una línea base clara y sin forma de confirmar si el percentil 75 en CrUX realmente mejoró.
LG DataOne centraliza la auditoría de velocidad, la monitorización de Core Web Vitals y la priorización de correcciones en una sola plataforma. La auditoría de velocidad web identifica el candidato LCP, desglosa las subpartes problemáticas y genera una tabla de priorización por impacto y esfuerzo lista para compartir con el equipo técnico. La monitorización RUM integrada permite validar que las mejoras de laboratorio se traducen en datos reales de usuarios, sin depender de ciclos de actualización de CrUX.
Para equipos que también quieren conectar la velocidad con las conversiones, la plataforma integra optimización de tasa de conversión (CRO) con tests A/B de rendimiento, mapas de calor y grabación de sesiones. Así, una mejora de LCP no queda como un número técnico aislado, sino como un cambio medible en el comportamiento del usuario.
Prueba LG DataOne durante 14 días sin coste y comprueba en qué subparte está perdiendo tiempo tu sitio.
Fuentes útiles y lectura recomendada sobre el LCP alto
Para profundizar en cada aspecto del diagnóstico y la optimización de LCP, estos recursos oficiales son el punto de partida más fiable:
- Optimiza el Largest Contentful Paint (web.dev): guía completa con la metodología de subpartes, ejemplos de código y checklist de validación. Lectura obligatoria para desarrolladores frontend.
- Definición técnica de LCP y API PerformanceObserver (web.dev): explica qué elementos cuenta la métrica, cómo funciona la API y los matices de medición en iframes y prerenderizado. Útil para equipos que instrumentan RUM.
- Cómo se definieron los umbrales de Core Web Vitals (web.dev): explica por qué 2,5 s y 4 s son los umbrales y la lógica detrás del percentil 75. Útil para justificar objetivos ante stakeholders.
- Web Vitals: resumen de métricas y herramientas (web.dev): visión general de LCP, INP y CLS con enlaces a cada herramienta de medición. Punto de entrada para equipos de marketing que necesitan contexto.
- Time to First Byte (Wikipedia): referencia técnica sobre TTFB y su relación con la latencia del servidor.
- LiteSpeed Cache para WordPress (es.wordpress.org): documentación del plugin para equipos que gestionan sitios WordPress y necesitan reducir TTFB y resource load duration.
Consejo profesional: Si gestionas un ecommerce en Europa Central, empieza por el informe de Core Web Vitals en Search Console filtrado por las URLs de categoría y producto con más tráfico. Esas páginas concentran el mayor impacto comercial y suelen compartir los mismos problemas de LCP, lo que permite aplicar una solución y validarla en múltiples URLs a la vez.
Para equipos con menos experiencia técnica, la guía de rendimiento web y WPO de LG DataOne ofrece contexto operativo sobre cómo la velocidad de carga afecta a las conversiones y qué métricas priorizar según el tipo de sitio.
Preguntas frecuentes sobre el LCP alto
¿Qué significa LCP en métricas web?
LCP (Largest Contentful Paint) mide el tiempo hasta que el mayor elemento visible del viewport se renderiza completamente. Es una de las tres Core Web Vitals que Google usa como señal de experiencia de página.
¿Cuál es un buen valor de LCP?
Un LCP de 2,5 segundos o menos se considera «bueno» según los umbrales oficiales de Google. Por encima de 4 segundos, la métrica entra en zona «deficiente». Ambos valores se evalúan en el percentil 75 de visitas reales.
¿Cómo sé qué elemento está causando el LCP alto?
PageSpeed Insights y Lighthouse identifican el elemento LCP con su URL y tiempo de carga. En Chrome DevTools, el panel Performance marca el candidato LCP en la línea de tiempo. El fragmento de PerformanceObserver de este artículo también captura el elemento en producción.
¿El LCP en medicina significa lo mismo?
No. En medicina, LCP hace referencia a la enfermedad de Legg-Calvé-Perthes, una afección de la cadera infantil. En el contexto de métricas web y Core Web Vitals, LCP siempre se refiere a Largest Contentful Paint.
¿Puedo mejorar el LCP sin tocar el código?
En entornos WordPress o CMS similares, sí es posible avanzar sin modificar código directamente: activar un plugin de caché como LiteSpeed Cache, eliminar el lazy-loading del hero desde la configuración del tema y servir imágenes en WebP desde el panel de medios suelen reducir el LCP sin intervención en el código fuente. Para mejoras más profundas (critical CSS, diferir scripts, preload), se requiere acceso al código.