Core Web Vitals
Tres métricas con las que Google mide si tu sitio web responde bien a sus usuarios. Señal de ranking. No garantía de primer lugar.
Tres métricas que Google usa para medir experiencia de usuario como señal de ranking: LCP (carga), INP (interactividad) y CLS (estabilidad visual). Se miden desde datos reales de usuarios a través de CrUX.
Mapa conceptual
Core Web Vitals son un subconjunto del programa Web Vitals de Google. Se componen de tres métricas con umbrales oficiales: LCP (Largest Contentful Paint, tiempo de carga del elemento visual más grande), INP (Interaction to Next Paint, capacidad de respuesta a interacciones del usuario) y CLS (Cumulative Layout Shift, estabilidad visual mientras carga la página).
Google incorporó los Core Web Vitals como factores de ranking en 2021, dentro del sistema Page Experience. Los datos utilizados para el ranking provienen de CrUX (Chrome User Experience Report), que registra métricas reales de usuarios de Chrome — no de herramientas de laboratorio.
En marzo de 2024, INP reemplazó oficialmente a FID (First Input Delay) como tercer Core Web Vital.
Antes de los Core Web Vitals, "velocidad" era un criterio vago. Ahora Google tiene tres números concretos. Si tu LCP supera los 4 segundos, si tu INP supera los 500 ms o si tu CLS supera 0.25, Google los registra como señal de mala experiencia.
El impacto no es solo de ranking. Un sitio que tarda 5 segundos en mostrar su contenido principal en mobile pierde usuarios antes de que vean la oferta, independientemente de su posición en los resultados.
LCP, INP y CLS: qué mide cada una
Largest Contentful Paint — carga del elemento más grande
Mide el tiempo que tarda en renderizarse el elemento visual más grande visible en el viewport inicial: la imagen hero, el video principal o el bloque de texto H1. Es la métrica más directamente relacionada con la percepción de velocidad.
Causas frecuentes de LCP lento: imágenes sin optimizar (formato, dimensiones, compresión), TTFB alto (servidor lento), recursos que bloquean el render (CSS y JS síncronos), lazy loading aplicado incorrectamente al elemento LCP.
Interaction to Next Paint — interactividad
Nuevo en 2024Mide la latencia entre una interacción del usuario (clic, toque, tecla) y el siguiente repintado visual de la página. A diferencia de FID, que solo medía la primera interacción, INP mide todas las interacciones durante la sesión y registra el percentil 98.
Por qué reemplazó a FID: FID solo medía la primera interacción (generalmente solo detectaba el primer clic), ignorando la experiencia posterior. INP da una imagen completa de qué tan responsiva es la interfaz durante toda la sesión.
Cumulative Layout Shift — estabilidad visual
Mide cuánto se desplazan visualmente los elementos de la página mientras se carga. Un CLS alto significa que el usuario ve cómo los botones se mueven, el texto salta o las imágenes aparecen y empujan el contenido — lo que resulta en clics incorrectos y experiencia frustrante.
Causas frecuentes: imágenes y videos sin atributos de dimensión (width/height), fuentes web que se cargan tarde (FOIT/FOUT), anuncios que se insertan dinámicamente, contenido inyectado sobre contenido existente.
Cómo medir los Core Web Vitals
Existen dos tipos de datos: de campo (usuarios reales) y de lab (condiciones controladas). Google solo usa datos de campo para el ranking.
Chrome User Experience Report. Agrega métricas reales de usuarios de Chrome. Es la fuente que Google usa para ranking. Accesible desde PageSpeed Insights y Search Console.
Combina datos de CrUX (campo) y Lighthouse (lab). La herramienta más práctica para diagnóstico rápido. Muestra ambas fuentes separadas.
Muestra CWV agrupados por URL y por dispositivo. Útil para identificar patrones en todo el sitio. Solo disponible si tu dominio está verificado en GSC.
Auditoría en condiciones simuladas. Útil para diagnosticar causas, pero NO representa la experiencia real de tus usuarios. Google no usa Lighthouse para ranking.
Problemas técnicos más frecuentes
- —Imágenes sin optimizar (formato no moderno, sin dimensiones explícitas)
- —TTFB alto — servidor lento o sin CDN
- —Render blocking CSS o JS en <head>
- —Lazy loading aplicado al elemento LCP (error común: nunca lazylodear el LCP)
- —Fuentes web sin preload
- —JavaScript pesado bloqueando el main thread
- —Hydration lenta en SPAs / frameworks (React, Next.js, Vue)
- —Event handlers costosos sin debounce
- —Third-party scripts que monopolizan el thread principal
- —DOM excesivamente profundo y complejo
- —Imágenes y videos sin atributos width/height explícitos
- —Fuentes web sin font-display: swap o similar
- —Anuncios y embeds que se insertan sobre contenido existente
- —Animaciones que usan propiedades que triggerea layout (top, left, width)
- —Contenido inyectado dinámicamente por encima del viewport
Core Web Vitals y ranking en Google
Google incorporó los Core Web Vitals como señal de ranking dentro del sistema Page Experience en 2021. Junto con HTTPS y la ausencia de intersticiales intrusivos, forman el conjunto de señales que Google evalúa como "experiencia de página".
En la práctica, los Core Web Vitals actúan como un criterio de desempate. En competencia ajustada, un sitio con CWV en verde tiene ventaja sobre uno con CWV en rojo, asumiendo que el contenido es comparable. Sin embargo, Google ha confirmado repetidamente que un sitio con contenido muy relevante puede posicionarse bien aunque tenga CWV mediocres.
Buenos Core Web Vitals no garantizan ranking alto. Son uno de muchos factores. El contenido relevante, los backlinks, el E-E-A-T y la intención de búsqueda siguen siendo los determinantes principales del posicionamiento.
Conversión y experiencia post-clic
El impacto más directo de los Core Web Vitals no es el ranking — es la conversión. Un sitio que tarda 5 segundos en mostrar su contenido principal en mobile pierde usuarios antes de que lean la oferta, independientemente de su posición en resultados.
Un CLS alto es especialmente dañino en páginas de conversión: si el botón de "Comprar" o "Solicitar" se mueve mientras el usuario intenta hacer clic, el resultado es frustración o una acción incorrecta.
El usuario ve una pantalla en blanco o parcial. Se va antes de ver la propuesta de valor.
Los clics y formularios no responden. La página se siente rota.
Los elementos se mueven. El usuario hace clic en el lugar equivocado o abandona.
Conceptos que se confunden con Core Web Vitals
| Concepto | Qué es | Relación con CWV |
|---|---|---|
| Page Experience | Sistema de señales de ranking de Google | CWV es uno de los componentes de Page Experience |
| Lighthouse | Herramienta de auditoría (lab data) | Mide CWV en lab, pero Google usa datos de campo para ranking |
| TTFB | Time to First Byte — tiempo de respuesta del servidor | Input de LCP, pero no es un Core Web Vital en sí mismo |
| FCP | First Contentful Paint — primer render visible | Relacionado con LCP, pero no es un Core Web Vital actual |
| FID | First Input Delay — primera interacción (depreciado) | Fue un Core Web Vital hasta marzo 2024. Reemplazado por INP |
Cómo trabajamos los Core Web Vitals
Los Core Web Vitals forman parte del análisis técnico en el diagnóstico SEO de Hipersigno. Revisamos el estado real de las tres métricas usando datos de CrUX (campo) para cada URL relevante del sitio, identificamos los elementos causantes y priorizamos según impacto en conversión y ranking.
No prometemos resultados numéricos específicos de mejora — eso depende de múltiples factores técnicos, de hosting y de implementación. Lo que hacemos es diagnosticar con precisión y proponer el plan técnico correcto.
“Core Web Vitals son un subconjunto de Web Vitals que aplican a todas las páginas web. Son medibles en el campo y reflejan la experiencia de usuario en el mundo real.”
Fuente: Google web.dev
“Los Core Web Vitals son usados por los ranking systems de Google junto con otras señales de Page Experience.”
Fuente: Google Search Central
“INP mide la latencia de todas las interacciones durante la sesión, no solo la primera. Reemplazó a FID en marzo de 2024.”
Fuente: Google web.dev
Conceptos relacionados
Largest Contentful Paint — tiempo que tarda en renderizarse el elemento visual más grande del viewport. Umbral…
Interaction to Next Paint — latencia de todas las interacciones del usuario. Reemplazó a FID en marzo 2024. Um…
Cumulative Layout Shift — inestabilidad visual: cuánto se mueven los elementos mientras carga la página. Umbra…
Sistema de señales de ranking de Google que incluye Core Web Vitals, HTTPS y ausencia de intersticiales intrus…
Herramienta de auditoría de rendimiento de Google. Mide Core Web Vitals en condiciones de lab (no datos reales…
Chrome User Experience Report — base de datos de métricas reales de navegadores Chrome que Google usa para eva…
Experience, Expertise, Authoritativeness, Trust — las dimensiones con que Google evalúa la calidad de autoría …
Optimizaciones que facilitan que Google rastree, indexe y entienda un sitio: velocidad, estructura, schema, ca…
Core Web Vitals — Preguntas frecuentes
¿Qué son los Core Web Vitals?
Core Web Vitals son tres métricas con las que Google mide la experiencia de usuario de una página web: LCP (velocidad de carga del elemento visible más grande), INP (capacidad de respuesta a interacciones) y CLS (estabilidad visual). Google los usa como señal dentro del sistema Page Experience para determinar ranking.
¿Cuáles son las tres métricas actuales?
Las tres métricas son: LCP (Largest Contentful Paint) — debe ser ≤2.5 segundos; INP (Interaction to Next Paint) — debe ser ≤200 ms; y CLS (Cumulative Layout Shift) — debe ser ≤0.1. Desde marzo de 2024, INP reemplazó a FID (First Input Delay) como Core Web Vital.
¿Los Core Web Vitals afectan el ranking en Google?
Sí, pero con una precisión importante: son una señal de ranking dentro del sistema Page Experience, no el único factor. Google ha confirmado que buenos Core Web Vitals ayudan, pero no garantizan un ranking alto. El contenido relevante y la calidad del sitio siguen siendo factores primarios.
¿Cómo mido los Core Web Vitals de mi sitio?
Existen dos fuentes de datos: datos de campo (usuarios reales) a través de CrUX, accesibles desde PageSpeed Insights y Google Search Console; y datos de lab (condiciones controladas) a través de Lighthouse. Google usa datos de campo para el ranking, no datos de lab. Si tu URL no tiene suficiente tráfico, no habrá datos de campo disponibles.
¿Por qué INP reemplazó a FID?
FID (First Input Delay) solo medía la latencia de la primera interacción del usuario. INP (Interaction to Next Paint) mide la latencia de todas las interacciones durante toda la sesión, lo que da una imagen más completa de la capacidad de respuesta del sitio. Google hizo el cambio oficial en marzo de 2024.
¿Qué diferencia hay entre Lighthouse y CrUX?
Lighthouse mide en condiciones controladas de laboratorio (simulación de dispositivo y red). CrUX (Chrome User Experience Report) recoge datos reales de usuarios de Chrome. Para el ranking de Google solo importan los datos de campo (CrUX). Los datos de lab de Lighthouse son útiles para diagnosticar problemas, pero no representan la experiencia real de tus usuarios.
Sigue aprendiendo
Ruta técnica
Para implementadores y arquitectos
- →LCP(pronto)
- →INP(pronto)
- →CLS(pronto)
- →Lighthouse(pronto)
Ruta SEO
Para estrategas y content managers
- →Page Experience(pronto)
- →E-E-A-T
- →SEO técnico
Ruta comercial
Para decisores y dueños de negocio
Fuentes oficiales
Definición oficial, métricas y umbrales de Core Web Vitals
Core Web Vitals como factor de ranking en Google Search
Page Experience como sistema de ranking — incluye Core Web Vitals
INP reemplazó a FID como Core Web Vital en marzo 2024