LCP, CLS, INP: las 3 métricas que Google mide y nadie te explica bien
Las siglas que más confunden en SEO técnico, explicadas en lenguaje claro con ejemplos visuales, causas comunes y fix concreto para cada una.
Por qué Google eligió estas 3 métricas
Google llegó a estas 3 métricas tras años de investigación sobre qué realmente percibe el usuario. Cada una representa una dimensión distinta de la experiencia:
- Loading: ¿la página se ve rápido? → LCP
- Interactivity: ¿responde bien cuando interactúo? → INP (antes FID)
- Visual stability: ¿se mueven cosas mientras carga? → CLS
Las 3 cubren la experiencia completa de carga. Mejorar solo una sin las otras es como tener un auto rápido sin frenos.
LCP: la métrica del “ya cargó”
Largest Contentful Paint. Mide el tiempo desde que el usuario navega a tu URL hasta que el elemento más grande visible en pantalla termina de renderizarse.
Tipos de elementos que cuentan para LCP:
- Imágenes (incluyendo background images detectables).
- Bloques de texto grandes (el hero copy, por ejemplo).
- Vídeos con poster image.
- SVGs grandes inline.
Ejemplo visual
En una landing típica de SaaS: el LCP suele ser la imagen hero o el H1. En un blog: la imagen destacada del post. En un e-commerce: la foto del producto en la ficha.
CLS: la métrica de la estabilidad visual
Cumulative Layout Shift. Mide cuánto se mueven los elementos visibles mientras la página carga. Se expresa como un score sin unidad, basado en el área desplazada × distancia desplazada.
Es la única métrica que mide UX percibida en su totalidad, no velocidad. Un sitio puede cargar en 1 segundo y aún así tener CLS terrible si los elementos saltan.
Causas más frecuentes
- Imágenes sin dimensiones. El navegador no sabe cuánto espacio reservar hasta que la imagen carga.
- Anuncios insertados dinámicamente. AdSense, redes publicitarias.
- Banners de cookies. Aparecen y empujan contenido.
- Fonts FOUT/FOIT. Texto que cambia de tipografía a mitad de carga.
- Embeds (YouTube, Twitter, Instagram). Cargan en iframe con altura variable.
INP: la métrica del lag percibido
Interaction to Next Paint. Mide el tiempo entre que el usuario interactúa (clic, tap, tecla) y la próxima actualización visual de la página.
Reemplazó a FID (First Input Delay) en marzo 2024 porque captura mejor el problema real: no solo la primera interacción, sino todas las interacciones a lo largo de la sesión.
La causa #1 de INP malo
Hidratación pesada de frameworks JS. Sitios React, Vue, Angular sin code splitting cargan kilobytes de JS antes de responder a la primera interacción. El usuario hace clic y nada pasa por 600-1500ms.
Cómo medirlas en tu sitio
- Lighthouse (lab). En Chrome DevTools, pestaña Lighthouse, run audit. Útil para iterar pero NO es lo que Google usa para ranking.
- Search Console > Core Web Vitals. Datos reales (CrUX) de tus usuarios. Es la métrica oficial de Google.
- PageSpeed Insights. Combina lab + field (CrUX) en una sola pantalla. Buen one-stop-shop.
- Vercel Speed Insights / Cloudflare Web Analytics. RUM (Real User Monitoring) propio. Útil para páginas autenticadas que CrUX no cubre.
- MinimalAuditor. Lighthouse mobile + desktop con interpretación AEO-aware. Útil para auditar como parte de un audit completo.
Qué optimizar primero según síntomas
- “Mi sitio tarda en mostrarse” → LCP. Empieza por optimizar imagen hero y reducir JS bloqueante.
- “Los elementos saltan al cargar” → CLS. Width/height en imágenes y reservar espacio para ads/embeds.
- “Hago clic y no pasa nada por un rato” → INP. Code splitting de JS y diferir third-party scripts.
- “Search Console dice todo mal” → priorizar según cuál tiene más volumen de URLs afectadas en el reporte.
Preguntas frecuentes
¿Estas métricas aplican igual para mobile y desktop?+
Aplican a ambos, pero los umbrales son los mismos. Lo que cambia es que mobile suele tener métricas peores por hardware más limitado y conexiones más lentas. Como Google indexa mobile-first, mobile pesa más.
¿Si tengo solo LCP malo pero CLS e INP bien, me afecta el ranking?+
Sí, pero menos que si los 3 estuvieran mal. Google considera el conjunto. Una métrica en rojo te baja del 'optimizado' a 'necesita mejorar', lo que en categorías competitivas puede mover 2-5 posiciones.
¿Cuál es la más fácil de mejorar?+
Suele ser CLS. Es problema de layout y se arregla con CSS (width/height en imágenes, aspect-ratio, reserva de espacio para ads/embeds). LCP requiere optimización de assets. INP requiere refactor de JS.
¿Vale la pena obsesionarse con un 95+ en cada una?+
No. El 'sweet spot' es estar en el rango 'Bueno' de los 3 (LCP < 2.5s, CLS < 0.1, INP < 200ms). Pasar de 'Bueno' a 'Excelente' tiene retornos decrecientes salvo en industrias muy competitivas (e-commerce, ads).
¿Existe un cuarto Core Web Vital escondido?+
TTFB (Time to First Byte) y FCP (First Contentful Paint) NO son Core Web Vitals oficiales, pero Lighthouse los muestra y afectan indirectamente. TTFB es la base: si tu servidor tarda 2s en responder, todo lo demás se vuelve imposible.
¿Cómo afecta usar Cloudflare/Vercel CDN?+
Mucho. Un buen CDN reduce TTFB de 800ms a 50ms en mercados internacionales. Eso mejora directamente LCP. Si tu mercado es multi-país y no usas CDN, es la palanca más barata.
Sigue leyendo
Core Web Vitals 2026: el checklist práctico que sí entiendes
Las 3 métricas que Google usa para evaluar tu experiencia: LCP, CLS, INP. Aquí va qué miden, cuáles son los umbrales actuales y qué hacer concretamente para mejorarlos.
Cómo leer un reporte de Lighthouse sin perder la cabeza
Lighthouse muestra 4 scores, decenas de audits y miles de bytes de información. Esta guía enseña cómo leerlo en orden de impacto, qué ignorar y qué atacar primero.
Velocidad mobile vs desktop: por qué Google solo mira mobile (y qué hacer si tu mobile es lento)
Desde 2019 Google indexa mobile-first. Esto significa que tu sitio en mobile es lo que cuenta para ranking, no la versión desktop. Aquí va qué cambió y qué hacer.