¿Qué son Core Web Vitals?

¿Qué son Core Web Vitals?

Core Web Vitals (CWV) son tres métricas medidas en campo que Google usa para puntuar la experiencia real del usuario en una página web: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Cada una captura una dimensión distinta de la experiencia de usuario: cómo de rápido se siente la página, cómo de receptiva es a las interacciones, y cómo de estable es el layout mientras carga. Desde la actualización de Page Experience de 2021, las CWV son una señal de ranking confirmada de Google — las páginas que alcanzan buenos umbrales en las tres métricas se ven favorecidas frente a las que no.

Las métricas se miden a partir de usuarios reales de Chrome (el Chrome User Experience Report, o CrUX), no a partir de herramientas sintéticas de laboratorio. Por eso dos páginas con scores idénticos en Lighthouse pueden tener valores CWV muy distintos en producción. CWV es el contrato entre lo que hace tu código y lo que sienten realmente usuarios reales en redes reales.

Las 3 métricas Core Web Vitals

Largest Contentful Paint (LCP)

LCP mide cuánto tarda en renderizarse el elemento de contenido visible más grande (normalmente una imagen hero, un bloque grande de texto o un poster de vídeo) en el viewport. Captura la velocidad de carga percibida. Bueno: por debajo de 2,5 segundos. Necesita mejorar: 2,5–4,0 s. Pobre: por encima de 4,0 s. Google usa el percentil 75 sobre 28 días para el ranking. Un LCP lento suele apuntar a imágenes hero no optimizadas, JavaScript o CSS que bloquean el render, o tiempos de respuesta del servidor lentos.

Interaction to Next Paint (INP)

INP reemplazó a First Input Delay (FID) como Core Web Vital el 12 de marzo de 2024. INP mide la latencia de todas las interacciones del usuario (clics, taps, pulsaciones de teclas) durante toda la vida de la página, y reporta la peor (o casi la peor, según el tráfico). Bueno: por debajo de 200 ms. Necesita mejorar: 200–500 ms. Pobre: por encima de 500 ms. A diferencia de FID — que solo medía la primera interacción — INP captura cada momento en que un usuario hace clic en algo y espera a que la página responda. Handlers JavaScript pesados, tareas largas que bloquean el hilo principal y re-renders descontrolados son las causas principales de un INP pobre.

Cumulative Layout Shift (CLS)

CLS mide la estabilidad visual — cuánto salta la página mientras carga el contenido. Es un score sin unidades de 0 (perfecto, nada se mueve) a 1+ (caótico). Bueno: por debajo de 0,1. Necesita mejorar: 0,1–0,25. Pobre: por encima de 0,25. Causas comunes: imágenes sin atributos width/height explícitos, web fonts que cambian sin coincidencia de tamaño (FOUT), y anuncios o embeds inyectados en el flujo del documento sin espacio reservado.

Cómo usa Google Core Web Vitals para el ranking

Desde la actualización de Page Experience, las tres métricas CWV alimentan el algoritmo de ranking de Google como parte de la señal más amplia de Page Experience. Para superar el test de Page Experience, una URL debe alcanzar "Bueno" en las tres métricas en el percentil 75 de muestras de usuarios reales. Las páginas que pasan obtienen un pequeño boost de ranking frente a páginas comparables que no lo hacen. Importante: CWV es un desempate, no una palanca mágica de ranking — un CWV fuerte no superará contenido irrelevante, pero dos páginas con relevancia y autoridad temática similares verán ganar a la que tenga mejores CWV.

Móvil y desktop se puntúan por separado. La mayoría de sitios tienen peores CWV en móvil (CPU más lenta, redes más lentas), así que móvil suele ser el cuello de botella para mejoras de ranking.

Lab vs campo: por qué tu score de Lighthouse miente

Lighthouse, la pestaña "Lab" de PageSpeed Insights y herramientas similares simulan un dispositivo en una red rápida y calculan CWV sintéticos. Los usuarios reales vienen de miles de dispositivos, redes y ubicaciones — y su CWV agregado por CrUX es lo que Google usa para el ranking. Un score de 95 en Lighthouse no significa que tu CWV de CrUX sea bueno. Comprueba siempre ambos: lab para diagnóstico (qué es lento, por qué), campo para impacto en ranking (¿están teniendo los usuarios reales una buena experiencia?).

La forma más rápida de ver tus valores live de CrUX es el informe de Core Web Vitals en Google Search Console, que muestra el rollup de campo de 28 días por grupo de páginas. PageSpeed Insights también muestra datos de campo cuando CrUX tiene suficientes muestras para la URL.

Causas comunes de Core Web Vitals pobres (y cómo arreglarlas)

LCP pobre suele estar causado por: imágenes hero sin optimizar (usa formatos modernos como AVIF o WebP, define width/height explícitos, preload de la imagen LCP), tiempo de respuesta del servidor / TTFB lento (cachea, usa una CDN, optimiza la consulta de base de datos para el contenido above-the-fold) y recursos que bloquean el render (defer CSS/JS no críticos, inline el CSS crítico).

INP pobre suele estar causado por: JavaScript de larga ejecución en el hilo principal (rómpelo en tareas más pequeñas, usa scheduler.yield o setTimeout), event handlers pesados (debounce, mueve el trabajo fuera del hilo principal con web workers) y layout síncrono forzado en handlers de interacción (lee primero las medidas del DOM, agrupa las escrituras después).

CLS pobre suele estar causado por: imágenes sin dimensiones explícitas (define siempre atributos width/height o aspect-ratio CSS), web fonts de carga tardía que causan FOUT (usa font-display: optional o size-adjust) y anuncios/embeds inyectados dinámicamente (reserva espacio con min-height antes de que cargue el contenido).

Por qué FID fue retirado e INP tomó su lugar

First Input Delay (FID) era la métrica original de interactividad. Medía el retraso entre el primer clic/tap y cuando el navegador empezaba a procesar el handler. El problema: FID solo medía la primera interacción, ignorando todo lo que pasaba después de cargar la página. Los usuarios reales hacen clic en muchas cosas durante una sesión, y la mayoría de las interacciones dolorosas ocurren a mitad de sesión, no en el primer clic.

INP arregla esto midiendo cada interacción y reportando la peor. La transición fue oficial el 12 de marzo de 2024 — sitios que rankeaban bien con FID empezaron a ver números diferentes en CrUX cuando Google cambió la métrica fuente. Si solo optimizaste para FID antes de 2024, tus scores CWV casi seguro empeoraron sin que cambiara nada más.

FAQ: Core Web Vitals

¿Cuáles son buenos scores de Core Web Vitals en 2026?

LCP por debajo de 2,5 s, INP por debajo de 200 ms, CLS por debajo de 0,1 — medidos en el percentil 75 de datos de usuarios reales sobre 28 días. "Bueno" en las tres es el umbral para pasar la señal de Page Experience en el algoritmo de ranking de Google.

¿Cuánto tardan en aparecer las mejoras de CWV en Search Console?

CrUX es una ventana móvil de 28 días, así que los cambios que despliegas hoy aparecerán completamente en tu informe CWV después de unos 28 días. Espera mejoras parciales en la primera semana, reflejo completo en la cuarta semana. No te asustes si tus scores se ven peor durante unos días tras un deploy — la ventana móvil aún contiene principalmente los datos antiguos.

¿Importan los Core Web Vitals para el SEO?

Sí — CWV es una señal de ranking de Google confirmada como parte de la actualización Page Experience. El boost es pequeño (más bien desempate, no megáfono), pero compuesto entre miles de URLs sí importa. Más importante: las mismas cosas que mejoran CWV (páginas más rápidas, menos layout shift) también mejoran la satisfacción del usuario y reducen la tasa de rebote.

¿Cuál es la diferencia entre CWV de lab y de campo?

Lab: medición sintética en un dispositivo bajo condiciones controladas (Lighthouse, PageSpeed Insights pestaña Lab). Útil para diagnóstico. Campo: usuarios reales en producción, agregados por Chrome (CrUX). Lo que Google realmente usa para ranking. Tu score lab y score campo pueden diferir mucho — comprueba siempre ambos.

¿Puedo tener un alto score de Lighthouse y aún así fallar en Core Web Vitals?

Sí. Lighthouse simula un dispositivo en una red. Los usuarios reales se reparten entre miles de gamas de dispositivos y velocidades de conexión. Una página que puntúa 95 en Lighthouse en un MacBook M1 puede aún tener LCP de campo fallando para usuarios en móviles Android de gama media en regiones 4G. CrUX es la verdad.

¿Cómo puedo monitorizar CWV continuamente?

Tres fuentes, usadas juntas: Google Search Console (rollup de campo 28 días, por grupo de páginas), PageSpeed Insights (por URL lab + campo) y una herramienta de monitorización sintética que ejecute auditorías Lighthouse desde navegadores reales en regiones reales con un schedule. LoadFocus hace lo tercero — auditorías Lighthouse programadas desde más de 25 regiones globales para cazar regresiones CWV antes de que lleguen a la ventana CrUX de 28 días.

¿Cuenta una página cargada desde caché para CWV?

Sí. CrUX mide cada navegación en Chrome, incluyendo recargas y navegaciones atrás-adelante. Los hits de bfcache — restauraciones instantáneas desde el historial — se tratan como nuevas navegaciones con tiempos de carga muy rápidos, lo que generalmente ayuda a tus medias CWV. Optimizar la elegibilidad para bfcache (sin handlers de unload, sin Cache-Control: no-store) es una de las ganancias CWV más baratas.

Cómo ayuda LoadFocus con Core Web Vitals

LoadFocus ejecuta auditorías Lighthouse desde más de 25 regiones AWS según un schedule, mostrando cómo varía CWV por geografía y hora del día. Donde Google Search Console te da el rollup de campo de 28 días, LoadFocus te dice qué está pasando ahora mismo — y desde dónde. Combina la monitorización sintética con la prueba de velocidad web de LoadFocus para análisis profundos puntuales cuando despliegas un cambio. Regístrate gratis en loadfocus.com/es-es/signup o ejecuta un test instantáneo en loadfocus.com/es-es/website-speed-test.