Los Core Web Vitals son las tres métricas de Google basadas en usuarios reales para medir la experiencia de página: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Miden qué tan rápida, responsiva y visualmente estable es una página para los visitantes reales, y se convirtieron en una señal oficial de ranking de Google en junio de 2021.
Las puntuaciones de laboratorio mienten. Los datos de campo de usuarios reales de Chrome son los que te posicionan — y son el único número de Core Web Vitals que importa cuando Google decide si tu página ofrece una buena experiencia.
¿Qué son los Core Web Vitals?
Los Core Web Vitals son las tres métricas específicas que Google usa para cuantificar la experiencia de página con fines de ranking de búsqueda. Introducidas en 2020 y convertidas en señal de ranking confirmada en junio de 2021, reemplazaron años de señales vagas de "velocidad del sitio" con tres números medibles y basados en umbrales.
Dos propiedades importantes los definen:
- Usuarios reales, no simulados. El sistema de ranking de Google usa datos de campo del Chrome User Experience Report: mediciones de usuarios reales de Chrome en tu sitio. Las puntuaciones de Lighthouse son diagnósticas, no insumos de ranking.
- Basados en umbrales, en el percentil 75. Una página "supera" una métrica solo cuando el 75% de las visitas cumple el umbral "bueno". La mediana (p50) no es suficiente.
En marzo de 2024, Google reemplazó First Input Delay (FID) por Interaction to Next Paint (INP). FID solo medía la primera interacción; INP mide cada interacción a lo largo de toda la visita. INP es una métrica de responsividad más estricta y realista.
Por qué importan los Core Web Vitals
Más allá del ranking, unos Core Web Vitals deficientes cuestan ingresos directamente. Cinco razones por las que cada equipo de SEO y desarrollo los monitorea:
- 24% menos abandonos. Los propios casos de estudio de Google muestran que las páginas que cumplen los tres umbrales retienen significativamente más usuarios hasta la primera interacción.
- Hasta un 15% más de ingresos publicitarios. Editores que corrigieron los CWV reportaron aumentos significativos en monetización: una página lenta genera menos inventario por sesión.
- Señal directa de ranking. Confirmada como desempate entre resultados por lo demás comparables.
- Amplificación móvil. Google indexa mobile-first. Los CWV móviles suelen ser peores que los de escritorio y pesan más.
- Efecto compuesto con la conversión. Cada 100ms ahorrados en LCP muestran un aumento medible en tasa de conversión en benchmarks de ecommerce.
Cómo funcionan los Core Web Vitals
Chrome recopila datos de rendimiento de usuarios reales (con consentimiento de telemetría) y los agrega en CrUX. Esos datos se unen a tus URLs a nivel de origen y de URL individual. Search Console muestra tus URLs agrupadas como Bueno, Necesita mejora o Pobre por métrica.
Datos de campo vs datos de laboratorio
Dos clases de datos miden las mismas métricas pero difieren fuertemente:
- Datos de campo (RUM): usuarios reales de Chrome, agregados durante 28 días. Usados para ranking.
- Datos de laboratorio: ejecuciones simuladas de Lighthouse. Útiles para reproducir problemas, no para ranking.
Nivel de URL vs nivel de origen
CrUX reporta tanto datos de URL individuales (cuando hay suficiente tráfico) como agregados de todo el origen. Las páginas de bajo tráfico heredan los datos del origen hasta que acumulan suficientes muestras.
Los tres Core Web Vitals
| Métrica | Qué mide | Bueno | Necesita mejora | Pobre |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tiempo hasta que el elemento más grande visible renderiza | ≤ 2.5s | 2.5-4s | > 4s |
| INP (Interaction to Next Paint) | Responsividad en cada interacción del usuario | ≤ 200ms | 200-500ms | > 500ms |
| CLS (Cumulative Layout Shift) | Estabilidad visual: saltos inesperados durante la carga | ≤ 0.1 | 0.1-0.25 | > 0.25 |
Largest Contentful Paint (LCP)
LCP mide el renderizado del elemento más grande visible — generalmente la imagen hero, un video hero o un bloque H1 grande. Un LCP lento suele significar una imagen hero sin optimizar, JavaScript que bloquea el renderizado o una respuesta de servidor lenta.
Interaction to Next Paint (INP)
INP rastrea el retraso entre el clic, toque o pulsación de tecla de un usuario y la siguiente actualización visual. Un INP lento suele significar una ejecución pesada de JavaScript en el hilo principal: tareas largas que bloquean el renderizado.
Cumulative Layout Shift (CLS)
CLS cuenta los cambios inesperados de contenido durante la carga de la página. Causas comunes: imágenes sin width/height, anuncios que cargan tarde y empujan el contenido hacia abajo, fuentes web que cambian de tipo y provocan reflujo de texto.
Correcciones reales de Core Web Vitals
1. LCP de 4.8s a 1.9s mediante optimización de imagen y fuente
Una imagen hero de ecommerce DTC era un PNG de 1.2MB. Cambiar a WebP, añadir srcset correcto y precargar el archivo redujo el LCP de 4.8s a 1.9s. La tasa de add-to-cart subió un 8% el mismo mes.
2. INP de 620ms a 140ms mediante aplazamiento de JS
Un sitio editorial cargaba 14 scripts de terceros de forma síncrona al cargar la página. Aplazar los scripts no críticos y consolidar tres etiquetas de analítica en una redujo el INP de 620ms a 140ms. Las páginas vistas por sesión subieron un 12%.
3. CLS de 0.42 a 0.02 mediante slots de anuncio reservados
Los anuncios a mitad de artículo de un sitio de medios se insertaban después de cargar, empujando párrafos hacia abajo. Reservar contenedores CSS de altura fija para cada slot de anuncio redujo el CLS de 0.42 a 0.02 en dos días.
Datos de campo vs datos de laboratorio: cuál te posiciona
Datos de campo (usados para ranking)
- Usuarios reales de Chrome, agregados durante 28 días.
- Fuente: Chrome UX Report (CrUX).
- Se muestran en Google Search Console.
- Refleja tu audiencia real: sus redes, dispositivos, geografía.
- Lo que Google usa para calificar la experiencia de página.
Datos de laboratorio (solo diagnóstico)
- Ejecución simulada única.
- Fuente: Lighthouse (PageSpeed Insights, DevTools).
- Útil para reproducir y depurar problemas.
- No refleja la varianza de usuarios reales.
- Nunca es un insumo directo de ranking.
7 mejores prácticas para los Core Web Vitals
- Comprime y moderniza las imágenes. WebP o AVIF, dimensionadas correctamente vía srcset, con atributos width/height en cada img.
- Precarga el elemento LCP. Una sola pista de precarga en la imagen hero o fuente reduce el LCP en cientos de milisegundos.
- Aplaza el JavaScript no crítico. Analítica, widgets de chat y scripts de A/B testing deben cargar después de la primera interacción.
- Reserva espacio para contenido dinámico. Anuncios, embeds e imágenes necesitan dimensiones explícitas para evitar saltos de diseño.
- Sirve a través de una CDN. Los activos estáticos sobre una CDN global reducen el LCP entre 200 y 800ms dependiendo de la geografía de la audiencia.
- Mide datos de campo, no de laboratorio. Revisa Search Console mensualmente. Lighthouse sirve para reproducir problemas específicos.
- Optimiza para el percentil 75, no para el promedio. Una mediana "aprobada" puede ocultar una cola que falla.
Puntuaciones de Lighthouse 90+ no significan que tus CWV pasen. El laboratorio es una ejecución única en una red simulada rápida; el campo son tus usuarios reales en dispositivos reales. Solo los datos de campo importan para el ranking.
Errores comunes de Core Web Vitals que debes evitar
- Imágenes hero sin comprimir. La causa #1 de LCP lento en 2026.
- JavaScript síncrono pesado. Cada tarea larga retrasa el INP.
- Imágenes sin dimensiones. Cada img sin width/height contribuye al CLS.
- Optimizar solo para escritorio. El móvil carga el peso del ranking.
- Ignorar el percentil 75. Los promedios ocultan la cola lenta que te hace fallar.
Cómo te ayuda theStacc
Nuestra auditoría detecta cada URL que falla en LCP, INP o CLS en el percentil 75 — segmentada por tipo de página, dispositivo y fuente de tráfico. Clasificamos las correcciones por el tráfico que protegerían y entregamos al equipo de desarrollo un ticket listo para implementar. Es el mismo flujo detrás de nuestros proyectos de SEO técnico: medir los datos de campo, corregir la palanca más grande y volver a medir a los 28 días.
Preguntas frecuentes
Sí. Google confirmó los Core Web Vitals como señal de experiencia de página para ranking en junio de 2021. Son un factor real de ranking, pero secundario respecto a la relevancia del contenido y los backlinks: actúan como desempate entre resultados por lo demás iguales.
Los umbrales "buenos" de Google para 2026: LCP inferior a 2.5 segundos, INP inferior a 200 milisegundos, CLS inferior a 0.1. El percentil 75 de usuarios reales debe cumplir los tres para aprobar.
Google Search Console para datos de campo (usuarios reales), PageSpeed Insights para datos de campo y de laboratorio, y Chrome DevTools para auditorías de laboratorio. Los datos de campo del Chrome UX Report son los que realmente alimentan el ranking.
Interaction to Next Paint (INP) reemplazó oficialmente a First Input Delay (FID) en marzo de 2024 como la métrica de responsividad en los Core Web Vitals. INP mide cada interacción durante la visita, no solo la primera.
Los casos de estudio de Google muestran que las páginas que cumplen los tres umbrales de CWV ven un 24% menos de abandonos. Editores que mejoraron los CWV reportaron hasta un 15% más de ingresos publicitarios. Las mejoras se acumulan en SEO, conversión y monetización.
Términos relacionados
Fuentes
- [01]web.dev — Web Vitals (Google Chrome team)
- [02]Google Search Central — Page experience
- [03]Chrome UX Report documentation
- [04]web.dev — INP (Interaction to Next Paint)
- [05]theStacc internal: CWV audits across 68 client sites, 2024-2026
