Core Web Vitals 2026: LCP, INP, CLS y por qué tu sitio podría estar perdiendo ranking
Google reemplazó FID por INP en marzo 2024 y endureció los thresholds. Te decimos las cifras exactas que necesitas, cómo se mide en México, y los 10 fixes que más mueven la aguja.
Core Web Vitals son tres métricas que Google usa como factor de ranking confirmado desde 2021. Desde marzo 2024 cambió FID por INP — más estricto y más realista. Si tu sitio no las pasa, Google te baja en resultados, especialmente en mobile, que es el 78% del tráfico mexicano.
Los umbrales oficiales 2026
| Métrica | Bueno | Necesita mejora | Malo |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤2.5s | 2.5–4s | >4s |
| INP (Interaction to Next Paint) | ≤200ms | 200–500ms | >500ms |
| CLS (Cumulative Layout Shift) | ≤0.1 | 0.1–0.25 | >0.25 |
Para que Google considere tu sitio "aprobado", el percentil 75 (P75) de cada métrica debe estar en verde. Es decir, el 75% de tus visitas reales deben tener LCP ≤2.5s, no solo el promedio. Esto se mide con el Chrome User Experience Report (CrUX), datos reales de Chrome.
LCP — La primera impresión cuenta
LCP mide cuánto tarda en pintarse el elemento más grande visible en pantalla. En México, con conexiones móviles 4G/5G variables, el LCP promedio P75 es 3.4s — por encima del threshold. Causas más comunes:
- Imagen hero sin optimizar (sirviendo JPG de 2MB en vez de WebP/AVIF de 80KB).
- Fuentes web bloqueando render — no usar `font-display: swap`.
- CSS bloqueante en <head> que pesa más de 50KB.
- Servidor lento (TTFB >800ms). Hostings compartidos baratos son culpables habituales.
- Faltan `<link rel="preload">` en assets críticos.
- Plugins de terceros (chatbots, analytics) que se cargan antes del hero.
INP — Lo nuevo en 2024
INP reemplazó FID el 12 de marzo 2024. Mide la latencia entre cualquier interacción (tap, click, teclado) y la respuesta visual. Es más estricto porque captura el peor caso de toda la sesión, no solo la primera interacción.
Lo que mata el INP en sitios mexicanos típicos:
- JavaScript pesado en el thread principal (~400ms de tarea bloquea TODO).
- Listeners de scroll mal implementados (sin debounce/throttle).
- Frameworks viejos sin code splitting (Angular 1, React 16 sin lazy).
- Plugins de WordPress encimados (cada uno suma 100–300ms).
- Animaciones JS en vez de CSS transforms (la GPU es más rápida).
CLS — El layout que no se mueva
CLS mide cuánto "salta" el contenido durante la carga. El bug clásico: lees el primer párrafo y de pronto un banner cookie/anuncio empuja todo abajo y das clic donde no querías. Causas:
- Imágenes sin `width` y `height` (o `aspect-ratio` CSS).
- Banners de cookies que aparecen tarde y empujan hero.
- Anuncios AdSense sin reserva de espacio.
- Fuentes web sin `font-display: optional` causando FOUT.
- Componentes condicionales sin altura reservada.
Cómo medir lo tuyo (gratis y bien)
- PageSpeed Insights (pagespeed.web.dev) — da CrUX real + Lighthouse lab. Lo más rápido.
- Google Search Console → Core Web Vitals → tu propiedad. Datos reales agrupados.
- Chrome DevTools → Lighthouse + Performance panel para debug.
- WebPageTest.org con perfil "México 4G" para emular la realidad local.
- DebugBear o SpeedCurve si necesitas monitoreo continuo (~$20 USD/mes).
Los 10 fixes que más mueven la aguja
- Convertir imágenes a WebP + AVIF con next/image (o equivalente).
- Servir con CDN — Vercel/Cloudflare/Fastly. TTFB <200ms en México.
- Eliminar 60–80% del CSS no usado (PurgeCSS, lightningcss).
- Lazy-load todo lo debajo del pliegue (imágenes, iframes, third-party).
- Preload del LCP image y de la fuente principal.
- Reservar espacio con `aspect-ratio` o width/height en TODA imagen y video.
- Code split por ruta + dynamic imports para componentes pesados.
- Mover analytics y chats a defer/async — nunca bloquear render.
- Comprimir Brotli (no solo gzip) en el servidor — 15–25% menos bytes.
- Quitar plugins/scripts que no aportan ROI medible.
¿Cuánto pesa esto en el ranking realmente?
Google ha dicho que CWV es "un factor pequeño pero real". En la práctica, vemos diferencias de 5–15 posiciones en SERPs competitivos cuando un sitio pasa de rojo a verde. El efecto compuesto es mayor: menos rebotes, más páginas por sesión, más conversiones — todas señales que Google también lee.
Para una PyME, el upside está en el bounce rate. Sitios con LCP 4s tienen ~32% de bounce; con LCP 2s, ~9% (Google internal study via web.dev). Esa diferencia mueve más leads que cualquier campaña de Ads. Nosotros construimos con estas métricas como requisito, no como parche: desarrollo web y mantenimiento continuo para que no se degraden con el tiempo.