De las tres Core Web Vitals que Google evalúa, LCP es la que más sitios reprueban y la que más directamente correlaciona con conversión. Si tu Largest Contentful Paint está por encima de 2.5 segundos en datos de campo (CrUX), ya estás compitiendo con un peso muerto: Google penaliza, el usuario se va, y la curva de rebote sube. Lo bueno: es la métrica con soluciones más concretas. Esta guía recoge qué es, cómo medirla bien y los siete ajustes que más impacto producen.
Qué mide exactamente el LCP
LCP (Largest Contentful Paint) cronometra cuánto tarda en pintarse el elemento de mayor superficie visible en el viewport inicial. Normalmente es una imagen hero, un bloque de texto grande, un video destacado o un componente con fondo. No es «cuándo termina de cargar la página», sino «cuándo el usuario percibe que el contenido principal está ahí».
Google define tres umbrales:
- Bueno: ≤ 2.5 segundos
- Necesita mejorar: entre 2.5 y 4 segundos
- Pobre: > 4 segundos
Para que tu sitio cuente como «aprobado» en LCP, el percentil 75 de tus visitas reales (móvil incluido) debe quedar bajo 2.5 segundos. No basta con que el promedio sea bueno: Google mira la cola larga.
Cómo medirlo sin engañarte
Hay dos tipos de datos que conviene no confundir:
- Lab data (Lighthouse, PageSpeed Insights modo simulado): es una emulación. Útil para diagnosticar, pero no es lo que Google usa para rankear.
- Field data (CrUX, sección «Experiencia» de Search Console, PSI sección superior): son datos reales de Chrome de los últimos 28 días. Esto es lo que cuenta.
Si tu lab data marca verde pero el field data marca naranja, el problema existe y Google lo está viendo. Cree al campo, no al laboratorio.
Las 7 causas que disparan tu LCP (en orden de frecuencia)
1. Imágenes hero sin optimizar
Es la causa #1 en sitios mexicanos. JPG de 1.8 MB cargando como elemento LCP en móvil con conexión 4G saturada. Solución: convertir a WebP o AVIF, redimensionar al tamaño real del viewport, servir versiones responsive con srcset y aplicar fetchpriority=»high» al hero.
2. Hosting compartido lento
Si tu TTFB (Time to First Byte) supera 600 ms, ningún ajuste front-end te va a salvar. Migrar a un hosting decente con servidores en Norteamérica (si tu audiencia es México/LATAM) puede cortar 1-2 segundos del LCP de golpe.
3. Recursos que bloquean el render
Cada <script> y <link rel=»stylesheet»> sin defer en el <head> retrasa el pintado. Diferir los scripts no críticos, inline el CSS above-the-fold y cargar el resto de forma asíncrona es la jugada estándar.
4. Fuentes web sin font-display: swap
Una fuente que tarda 1.2 segundos en cargar sin swap puede ser el LCP. La solución es triple: font-display: swap, preload de las fuentes críticas y usar formatos WOFF2 con subset de caracteres latinos.
5. Ausencia de CDN
Servir todo desde un único origen en Estados Unidos cuando tu audiencia está en México, Colombia o España es regalar segundos. Cloudflare, Bunny.net o BunnyCDN reducen latencia geográfica a milisegundos.
6. Imágenes lazy-loaded en el viewport inicial
Aplicar loading=»lazy» a la imagen hero es uno de los errores más comunes que vemos. El navegador la trata como secundaria y la carga tarde. Las imágenes above-the-fold nunca llevan lazy.
7. JavaScript ejecutándose en el hilo principal
Sliders, builders visuales tipo Elementor pesados y tracking de analytics ejecutándose síncronamente bloquean el main thread durante segundos. Diferir y dividir bundles es indispensable.
El plan en 5 pasos para arreglar el LCP de tu sitio
- Mide en campo, no en laboratorio. Abre PageSpeed Insights, fíjate solo en la sección superior (datos CrUX). Si está verde, no toques nada y dedica tu energía a INP o CLS.
- Identifica cuál es tu elemento LCP. Lighthouse te lo dice. Sin saber qué elemento se está midiendo, cualquier optimización es a ciegas.
- Optimiza ese elemento primero. Si es una imagen, comprime y aplica fetchpriority=»high». Si es un bloque de texto, asegúrate que la fuente carga rápido.
- Desbloquea el render. Diferir scripts no críticos, inline CSS crítico, eliminar recursos render-blocking del <head>.
- Re-mide después de 28 días. CrUX necesita ese tiempo para reflejar cambios. No te frustres si PSI sigue rojo el día siguiente.
Cuándo el problema no es técnico, es estructural
A veces el LCP no se arregla con ajustes finos porque el sitio está construido sobre un theme inflado, un page builder pesado o un hosting que no da para más. En esos casos el costo de seguir parchando supera al de migrar. Si tu sitio es WordPress con Elementor o Divi y tu LCP móvil está sobre 4 segundos, considera seriamente cambiar de stack antes de seguir gastando en plugins de caché.
El LCP es la métrica más visible de Core Web Vitals porque correlaciona directamente con lo que el usuario siente. Bajarlo de 4 a 2 segundos no solo mejora rankings: mejora tasa de conversión, tiempo en página y porcentaje de scroll. Es de las pocas inversiones en SEO técnico cuyo retorno se mide en semanas, no en meses.
Si quieres seguir auditando tu sitio, lee también nuestras guías sobre cómo mejorar INP y cómo arreglar el CLS, las otras dos métricas que Google evalúa en Core Web Vitals.
Visita https://seoinspector.pro/
Redactor SEO y experto en marketing digital con más de 8 años de experiencia tanto en publicidad pagada como crecimiento orgánico.