Inicio/Glosario/Core Web Vitals
SEO técnicoCore Web Vitals
Los Core Web Vitals son las tres métricas con las que Google cuantifica la experiencia real de una página: velocidad de carga (LCP), capacidad de respuesta a las interacciones (INP) y estabilidad visual (CLS). Cada métrica se clasifica como "bueno", "necesita mejorar" o "deficiente", y la evaluación toma el percentil 75 de las visitas reales.
Qué es
Los Core Web Vitals (CWV) son tres métricas que Google usa para medir la experiencia de uso de una página con datos de usuarios reales. LCP (Largest Contentful Paint) mide cuándo se pinta el mayor elemento visible: la velocidad de carga percibida. INP (Interaction to Next Paint) mide la latencia de respuesta a las interacciones del usuario. CLS (Cumulative Layout Shift) mide cuánto se desplaza el contenido de forma inesperada: la estabilidad visual.
Según la documentación canónica de Google y web.dev, el umbral "bueno" es LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1. La evaluación se hace sobre el percentil 75 de las páginas vistas y se segmenta por dispositivo (móvil y escritorio): una página se clasifica como "buena" en una métrica cuando al menos el 75 % de las visitas reales cumplen ese umbral. En 2024, INP sustituyó a FID (First Input Delay) como métrica de capacidad de respuesta.
Los CWV se miden idealmente con datos de campo (usuarios reales, vía CrUX o Search Console), no solo con datos de laboratorio (Lighthouse, PageSpeed Insights). Ambos pueden diferir, y la evaluación oficial prioriza el campo. Capturar estas métricas exige renderizar la página en un navegador real: no basta con leer el HTML, el mismo límite que afronta el Rastreo e indexación cuando el contenido depende de JavaScript.
Por qué importa
Los Core Web Vitals forman parte de la señal de page experience que Google usa para clasificar. Son un factor entre muchos: cumplirlos no garantiza posiciones, y nadie puede prometerlas. Lo que sí ofrecen es una medida concreta y comparable de la experiencia que reciben tus usuarios.
Por eso conviene tratarlos como una métrica de negocio, no solo técnica: cruzados con Eventos y conversiones —el impacto medible de cada interacción en el embudo— dejan de ser un dato de laboratorio para convertirse en una palanca de ingresos. Una carga lenta, una interfaz que no responde o un layout que salta degradan la experiencia, y eso afecta a la conversión y a la confianza, al margen del ranking. Medirlos por plantilla y por dispositivo permite priorizar dónde la mejora mueve de verdad la experiencia y el negocio, con criterio humano para decidir qué vale la pena tocar. Buena parte de esa decisión es de Arquitectura web —qué plantillas se reutilizan, qué recursos se cargan y cómo—, donde un arreglo se propaga a miles de URLs a la vez.
En profundidad
LCP no es un número: son cuatro fases
Optimizar contra el umbral de 2,5 s sin saber dónde se va el tiempo es trabajar a ciegas. LCP se descompone en cuatro subpartes que indican EN QUÉ punto se pierde el tiempo: TTFB (servidor y red hasta el primer byte), Resource Load Delay (cuánto tarda el navegador en empezar a cargar el recurso LCP), Resource Load Duration (la carga del recurso en sí) y Element Render Delay (del fin de la carga al pintado). El TTFB pertenece al dominio de la Infraestructura cloud —servidor, caché y red de origen—, no del front-end, así que atacarlo ahí cuando el cuello está en el servidor es perder el tiro.
web.dev orienta el reparto ideal hacia la carga del recurso, no hacia los delays: una cifra orientativa de ~40% TTFB, <10% load delay, ~40% load duration y <10% render delay. Es eso, una orientación, no un umbral oficial. Importa el matiz: web.dev advierte que la duración de carga no suele ser el cuello de botella en la mayoría de sitios, así que la regla de ingeniería es medir la subparte que duele con datos reales antes de tocar nada, no asumir cuál es.
INP tampoco es una caja negra: input, processing, presentation
Una interacción lenta se reparte en tres fases con causas distintas. Input delay: desde que el usuario interactúa hasta que empiezan a ejecutarse los callbacks del evento (se alarga cuando el hilo principal está ocupado). Processing duration: el tiempo que tardan en ejecutarse esos callbacks. Presentation delay: hasta que el navegador pinta el siguiente frame con el resultado visual de la interacción.
Cada fase exige una palanca distinta —partir tareas largas para el input delay, adelgazar handlers para el processing, reducir trabajo de renderizado para el presentation—, así que el primer paso es saber qué fase domina, no asumirlo. El peso del hilo principal suele venir del JavaScript de la página, el mismo eje que gobierna el JavaScript SEO: menos script ejecutándose mejora a la vez la indexabilidad y la respuesta. Para ir a la causa raíz en campo está LoAF (Long Animation Frames API, disponible desde Chrome 123), que mejora el enfoque de la Long Tasks API y expone qué scripts congestionan el frame de la interacción. La librería web-vitals v4 integra esos insights.
CLS: la fórmula real y sus casos límite
CLS no es la suma de todos los desplazamientos. Cada layout shift se calcula como fracción de impacto × fracción de distancia, y la puntuación de la página es la 'ventana de sesión' con mayor acumulado: una ráfaga de shifts con menos de 1 s entre cada uno y un máximo de 5 s de ventana. Es una métrica sin unidades.
El caso límite que más confunde: los desplazamientos dentro de 500 ms de una entrada discreta del usuario (tap, clic, tecla) llevan el flag hadRecentInput y se excluyen. Pero el scroll, el arrastre o el pinch-zoom NO cuentan como input reciente, así que un shift durante el scroll sí penaliza. Entender la mecánica evita 'optimizaciones' que mueven el problema fuera de la ventana sin resolverlo.
Medir como mide Chrome: campo propio, no solo el informe
Los datos que Google usa para evaluar (CrUX) son una ventana móvil de 28 días al percentil 75. Eso implica latencia estructural: lo que arregles hoy tarda semanas en consolidarse en campo, y el informe siempre va por detrás de tu último deploy.
Para cerrar ese lazo conviene instrumentar RUM propio con la librería web-vitals (~2 KB) y su build attribution (+1,5 KB), que mide exactamente como Chrome y añade diagnóstico por métrica (qué elemento, qué subparte). Ese RUM no deja de ser un caso de Eventos y conversiones aplicado al rendimiento: capturas la métrica como un evento por sesión y la cruzas con el negocio. Dos puntos ciegos a tener presentes. El bfcache restaura páginas de forma casi instantánea al navegar atrás/adelante y mejora LCP y CLS reales; bloquearlo con unload handlers o con Cache-Control: no-store penaliza —un detalle de cabeceras que se decide en la Infraestructura cloud—, y la librería web-vitals reporta esas restauraciones. Y las soft navigations de una SPA (React, Vue, Next) hoy no se miden de forma estándar: Chrome lo explora con la Soft Navigations API, aún experimental. Esas mismas SPAs son el terreno del JavaScript SEO, donde la navegación cliente complica tanto la medición como el rastreo. Quien instrumenta con método ve antes lo que el informe tarda en contar.
| Concepto | Qué es | Implicación al medir |
|---|---|---|
| CrUX | Ventana móvil de 28 días al percentil 75 (datos de campo de Google) | Latencia estructural: el informe va por detrás de tu último deploy |
| web-vitals (RUM) | Librería ~2 KB que mide como Chrome; build attribution +1,5 KB | Diagnóstico por métrica: qué elemento y qué subparte; cierra el lazo en campo |
| bfcache | Restaura la página casi instantánea al ir atrás/adelante; mejora LCP y CLS | unload handlers o Cache-Control: no-store lo bloquean y penalizan; web-vitals lo reporta |
| Soft navigations | Navegación SPA (React, Vue, Next) sin recarga completa | Hoy no se miden de forma estándar; Chrome lo explora con la Soft Navigations API (experimental) |
En vídeo y audio
Qué observar
Las señales que importan.
LCP por plantilla y dispositivo
El LCP mide el tiempo hasta que se pinta el elemento más grande del viewport. Su origen suele ser una imagen pesada, una fuente o un recurso que bloquea el render. Varía por plantilla y por dispositivo.
INP: latencia de respuesta
El INP mide cuánto tarda la página en reaccionar a interacciones reales del usuario. La degradación procede del JavaScript que retrasa esa respuesta. Sustituye a FID desde 2024.
CLS: estabilidad visual
El CLS cuantifica los desplazamientos inesperados del layout. Se originan en imágenes, anuncios o fuentes que cargan sin reservar previamente su espacio.
Campo frente a laboratorio
Los datos de campo (CrUX/Search Console) reflejan visitas reales; los de laboratorio (Lighthouse) son sintéticos. Ambos pueden divergir por las condiciones de red, dispositivo y comportamiento del usuario.
Evaluación por percentil 75
Una página se considera 'buena' cuando al menos el 75 % de las visitas reales cumple el umbral 'bueno' en cada métrica. El percentil 75 es el criterio de evaluación.
Conceptos clave
El vocabulario del término.
- Subpartes de LCP
- Las cuatro fases en que se descompone el LCP —TTFB, Resource Load Delay, Resource Load Duration y Element Render Delay— que indican en qué punto del proceso se pierde el tiempo de carga.
- TTFB (Time to First Byte)
- Tiempo desde que el usuario inicia la carga hasta que el navegador recibe el primer byte del HTML; es la primera subparte del LCP, su base, porque nada ocurre en el frontend hasta ese byte.
- Fases de INP
- Las tres etapas de una interacción —input delay (espera del hilo principal), processing duration (ejecución de los callbacks) y presentation delay (pintado del siguiente frame)— que se optimizan por separado.
- LoAF (Long Animation Frames API)
- API de Chrome (disponible desde la v123) que mejora el enfoque de la Long Tasks API exponiendo qué scripts congestionan el hilo principal; herramienta principal para diagnosticar en campo la causa de un INP alto.
- Ventana de sesión (CLS)
- Ráfaga de layout shifts con menos de 1 s entre cada uno y un máximo de 5 s; el CLS de la página es la ventana con mayor puntuación acumulada, no la suma de todos los shifts.
- hadRecentInput
- Flag de la Layout Instability API que excluye del CLS los desplazamientos dentro de 500 ms de una entrada discreta (tap, clic, tecla); el scroll, el arrastre y el pinch-zoom no cuentan como input reciente.
- web-vitals.js (build attribution)
- Librería oficial de Google (~2 KB) para medir las CWV de usuarios reales tal como las mide Chrome; el build attribution (+1,5 KB) añade diagnóstico por métrica para localizar la causa raíz.
- bfcache (back/forward cache)
- Caché en memoria que restaura una página completa de forma casi instantánea al navegar atrás/adelante, mejorando LCP y CLS reales; prácticas como los unload handlers o Cache-Control: no-store lo bloquean.
- Soft navigation
- Cambio de ruta gestionado por JavaScript dentro de una SPA sin recarga completa; punto ciego histórico de las CWV que Chrome intenta medir con la Soft Navigations API, todavía experimental.
- Ventana móvil de 28 días (CrUX)
- Los datos de campo de CrUX se calculan sobre los últimos 28 días en ventana deslizante al percentil 75, por lo que cualquier mejora tarda semanas en consolidarse en el informe.
Aún no mostramos casos.
No inventamos resultados. Cuando tengamos casos reales —anonimizados y medibles— donde este concepto marcó la diferencia, vivirán aquí.
Conceptos relacionados
Fuentes
- Web Vitals (web.dev)
- Understanding Core Web Vitals and Google Search results (Google Search Central)
- How the Core Web Vitals metrics thresholds were defined (web.dev)
- Largest Contentful Paint (LCP) (web.dev)
- Why lab and field data can be different (web.dev)
- Optimize Largest Contentful Paint · consultado 2026-06-01
Una pieza del glosario.
Forma parte del glosario de SEO, analítica e IA de InnovaOrigen Tech: un mapa de conceptos definidos con criterio y fuentes. Si quieres llevarlo a tu caso, lo vemos sin compromiso.