Los Core Web Vitals son una señal de ranking confirmada por Google que mide tres dimensiones de la experiencia de página: velocidad de carga (LCP), interactividad (INP) y estabilidad visual (CLS). Funcionan como desempate entre páginas que son equivalentes en relevancia y autoridad — no como un multiplicador que anula la calidad del contenido.
Ese matiz importa. La mayoría de sitios pasan demasiado tiempo persiguiendo puntuaciones perfectas en Lighthouse cuando sus datos de campo reales en GSC ya están en rango “Bueno”. Y muchos sitios con problemas reales de CWV los descartan como irrelevantes sin entender qué les dice el field data.
Esto es lo que muestran los datos de verdad — y lo que merece la pena arreglar.
Qué son los Core Web Vitals (y qué no son)
Google introdujo los Core Web Vitals como señal de ranking oficial en mayo de 2021 con la actualización de Page Experience. La señal es real. La ponderación es más ligera de lo que sugiere la mayoría de artículos.
Google ha sido explícito al respecto: los CWV no anulan la relevancia ni la calidad del contenido. Una página lenta con contenido excelente y backlinks sólidos casi siempre superará a una página rápida con contenido mediocre. Pero cuando dos páginas compiten en igualdad de condiciones — contenido similar, autoridad similar — la que supera los umbrales de CWV tiene una ventaja medible.
Un estudio de Ahrefs de 2023 encontró que las páginas en el top 10 tienen más probabilidades de superar los Core Web Vitals que las páginas en posiciones 11–20, pero la correlación es más fuerte en keywords muy competitivas donde varias páginas son similares en calidad. Para keywords long tail de baja competencia, los CWV rara vez determinan el resultado.
La implicación práctica: arregla los fallos de CWV porque dañan la experiencia de usuario y tienen un efecto SEO real, aunque moderado. No los trates como la palanca principal para mejorar rankings — eso sigue siendo contenido y enlaces.
Las tres métricas y sus umbrales
Google define tres niveles para cada métrica basándose en datos de campo:
| Métrica | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|
| LCP | < 2,5s | 2,5s – 4,0s | > 4,0s |
| INP | < 200ms | 200ms – 500ms | > 500ms |
| CLS | < 0,1 | 0,1 – 0,25 | > 0,25 |
Una URL se clasifica como “Buena” solo si las tres métricas superan los umbrales en el percentil 75 de sesiones reales de usuarios. Ese último punto es crítico — no te miden sobre tu usuario promedio, sino sobre el percentil 75. Una página que es rápida para el 80% de los usuarios pero lenta para el 25% más lento sigue fallando.
LCP — Largest Contentful Paint
El LCP mide cuánto tarda en renderizarse el elemento visible más grande del viewport. En la práctica, casi siempre es la imagen hero o el bloque de encabezado principal.
El umbral Bueno es menos de 2,5 segundos en conexiones reales de usuarios. La mayoría de sitios que fallan en LCP lo hacen en móvil con conexiones lentas — no en la conexión de fibra desde la que tú pruebas.
Los fallos de LCP más frecuentes
Imagen hero sin preload. El navegador descubre tu imagen LCP demasiado tarde porque está enterrada en CSS o se carga después de recursos bloqueantes del render. Solución: añade <link rel="preload" as="image" href="/hero.jpg"> en el <head>, y fetchpriority="high" en el propio <img>.
Imagen sobredimensionada para el viewport. Servir una imagen de 2.400px de ancho a una pantalla móvil de 390px desperdicia ancho de banda y retrasa el LCP. Sirve imágenes responsive con srcset y sizes. Usa formato WebP o AVIF. Una imagen correctamente dimensionada en formato moderno reduce el LCP un 40–60% en móvil de media.
TTFB lento del servidor. Si tu Time to First Byte supera los 600ms, el LCP sufrirá independientemente de la optimización de imágenes. Revisa el TTFB en PageSpeed Insights. Soluciones: migra a un hosting más rápido, añade un CDN o implementa edge caching.
CSS o fuentes bloqueando el render. Las hojas de estilo en etiquetas <link> en <head> bloquean el renderizado hasta que se descargan. Haz inline el CSS crítico. Carga el CSS no crítico de forma asíncrona. Usa font-display: swap para las web fonts para que el texto se renderice de inmediato aunque no haya cargado la fuente personalizada.
En mi experiencia auditando sitios, el LCP casi siempre es un problema de carga de imágenes combinado con un TTFB lento. Arregla el preload de la imagen y reduce el TTFB primero — estos dos cambios mueven más el indicador que cualquier otra cosa.
INP — Interaction to Next Paint
El INP reemplazó al FID (First Input Delay) en marzo de 2024. El FID solo medía el retraso antes de que el navegador pudiera responder a la primera interacción del usuario. El INP mide el retraso para cada interacción durante toda la sesión — clics, toques, pulsaciones de teclas — y reporta la peor en el percentil 75.
Esta es una métrica significativamente más difícil de superar. Un sitio que puntuaba bien en FID puede fallar en INP porque el procesamiento intensivo de JavaScript durante las interacciones (no solo en la carga de página) causa retrasos visibles.
Qué causa un INP alto
Long tasks en el hilo principal. Cualquier tarea JavaScript que tarda más de 50ms es una “long task” que bloquea al navegador para responder a la entrada del usuario. Usa el panel Performance de Chrome DevTools para identificar y dividir las long tasks. Las tareas por encima de 200ms son la prioridad inmediata.
Manejadores de eventos pesados. Un handler de clic que procesa datos de forma síncrona, actualiza el DOM y dispara recálculos de layout puede tardar fácilmente 300–500ms. Mueve el procesamiento costoso fuera del hilo principal usando Web Workers, o difiere las actualizaciones no críticas con requestAnimationFrame.
Scripts de terceros. Widgets de chat, scripts de publicidad, gestores de etiquetas y librerías de analytics son los principales causantes de INP. Se ejecutan en el hilo principal y no se pueden optimizar directamente. Audita el impacto de terceros en PageSpeed Insights. Carga los terceros no críticos tras la interacción del usuario o con loading="lazy".
Hidratación de frameworks. Las aplicaciones React, Vue y Angular suelen tener INP alto durante la hidratación — la fase en que el framework JavaScript toma el control del HTML renderizado en servidor. Considera la hidratación parcial o patrones de streaming SSR.
CLS — Cumulative Layout Shift
El CLS mide la cantidad total de desplazamiento de layout inesperado que ocurre durante la vida de una página. Una puntuación de 0,1 significa que el 10% del viewport se desplazó inesperadamente. Por encima de 0,25 es Deficiente.
El CLS es la métrica más correlacionada con la frustración directa del usuario. Un layout que salta provoca clics erróneos, interrumpe la lectura y da la sensación de que la página está rota. Según la propia investigación de Google, las páginas con CLS alto tienen tasas de rebote más altas con independencia de cualquier efecto en ranking.
Las causas de CLS más frecuentes
Imágenes sin dimensiones explícitas. Cuando el navegador encuentra una etiqueta <img> sin atributos width y height, no puede reservar espacio antes de que cargue la imagen. La imagen entonces desplaza el contenido hacia abajo al llegar. Solución: añade siempre width y height a las etiquetas <img>. El CSS puede sobreescribir estos valores — el navegador solo los necesita para calcular el ratio de aspecto.
Anuncios y embeds sin espacio reservado. Los anuncios display, embeds de redes sociales e iframes inyectados en áreas de contenido desplazan el layout al cargarse. Reserva espacio con un contenedor de dimensiones conocidas antes de que llegue el contenido dinámico.
Fuentes web causando FOUT. El Flash of Unstyled Text ocurre cuando el navegador renderiza el texto en una fuente de respaldo y luego lo vuelve a renderizar con la fuente web (que tiene métricas diferentes). Usa font-display: optional para fuentes no críticas, o asegúrate de que las métricas de la fuente de respaldo coincidan con la web font usando el descriptor size-adjust.
Banners de cookies y notificaciones. Cualquier elemento que se inserta por encima del contenido existente causa CLS. Posiciona los banners de consentimiento como overlays que no empujen el contenido, o reserva espacio para ellos antes del render de la página.
Cómo medir los CWV correctamente
La distinción clave es datos de laboratorio vs datos de campo.
Datos de laboratorio (Lighthouse, simulaciones de PageSpeed Insights) prueba tu página en un entorno controlado con conexión y CPU limitadas. Útiles para diagnosticar problemas concretos. No son los que usa Google para posicionar.
Datos de campo (CrUX — Chrome User Experience Report) mide a usuarios reales de Chrome que visitan tus páginas reales. Esto es lo que muestra Google Search Console y lo que afecta a tus señales de Page Experience.
Una página puede puntuar 95 en Lighthouse y seguir fallando en datos de campo si los usuarios reales con conexiones móviles lentas tienen una experiencia diferente a la del test simulado. Comprueba siempre primero en GSC.
El flujo de medición correcto
- Google Search Console → Experiencia → Core Web Vitals: Ve qué URLs están clasificadas como Deficiente o Necesita mejorar según usuarios reales. Esta es tu lista de prioridades.
- PageSpeed Insights en URLs concretas: Muestra tanto datos de campo (parte superior del informe) como datos de laboratorio (Lighthouse). Diagnostica las métricas específicas que fallan.
- Panel Performance de Chrome DevTools: Para depurar INP y long tasks en interacciones específicas.
- Extensión Web Vitals de Chrome: Mediciones de CWV en tiempo real mientras navegas por tu propio sitio.
Arregla las URLs Deficientes antes de tocar las de Necesita mejorar. Cada grupo de URLs en GSC afecta a las páginas dentro de él — un cluster de páginas Deficientes puede arrastrar hacia abajo la señal global de Page Experience de tu dominio.
El orden de prioridad
No todos los fallos de CWV son iguales. Así es como hay que priorizar:
Primero: arregla los fallos de LCP en tus páginas de mayor tráfico. El LCP es la métrica que falla con más frecuencia y la más directamente ligada a la velocidad percibida. Homepage, páginas de categoría principales y posts del blog con más tráfico, primero.
Segundo: audita y reduce los scripts de terceros. Un único widget de chat o script de publicidad mal cargado puede causar tanto fallos de INP como de LCP en todo tu sitio. La relación impacto-esfuerzo es muy alta.
Tercero: arregla las dimensiones de imágenes y el sizing de contenedores de anuncios para CLS. Normalmente son arreglos rápidos con mejoras inmediatas en los datos de campo, visibles en GSC en 28 días.
Cuarto: aborda el INP en interfaces con mucho JavaScript. Requiere más esfuerzo de desarrollo y suele ser menor prioridad salvo que tengas una webapp con interactividad compleja.
Para la mayoría de sitios de contenido y servicios, arreglar el LCP y eliminar el CLS de imágenes y anuncios es suficiente para pasar de Deficiente a Bueno en GSC. La auditoría de SEO técnico detecta los tres habitualmente en la primera pasada — junto con las páginas y elementos concretos que causan los fallos.
El resumen honesto
Supera los umbrales de datos de campo en Google Search Console. Arregla los fallos críticos en tus páginas de mayor tráfico primero. Deja de obsesionarte con las puntuaciones de laboratorio de Lighthouse.
Los Core Web Vitals son una señal real con un efecto real en rankings — especialmente en sectores competitivos donde la calidad del contenido entre los primeros resultados es similar. También son un proxy de la calidad de experiencia de usuario que afecta a la tasa de rebote, el engagement y las conversiones con independencia de cualquier efecto en el ranking.
La auditoría SEO incluye una revisión completa de los datos de campo de CWV con arreglos priorizados. Si ya sabes que tienes fallos de CWV y necesitas soporte para implementar las soluciones, el servicio de SEO técnico cubre toda la lista de correcciones. Para ver cómo los Core Web Vitals encajan en el cuadro completo del SEO técnico, consulta el Hub de SEO Técnico.
Preguntas frecuentes
¿Los Core Web Vitals afectan directamente al posicionamiento en Google?
Sí, pero como señal de desempate ligera, no como factor principal de ranking. Google confirmó los Core Web Vitals como señal de ranking en mayo de 2021. No anulan la relevancia del contenido ni la autoridad — pero cuando dos páginas compiten en igualdad de condiciones, la que supera los umbrales de CWV tiene ventaja.
¿Qué Core Web Vital tiene más impacto en el posicionamiento?
El LCP tiende a tener el mayor impacto directo porque refleja la velocidad de carga percibida. Un LCP pobre (más de 4 segundos) es el fallo más frecuente en los datos de campo de GSC. Arregla primero el LCP, luego el INP y luego el CLS.
¿Cuál es la diferencia entre datos de laboratorio y datos de campo?
Los datos de laboratorio provienen de pruebas controladas (Lighthouse) — útiles para diagnosticar pero no son los que usa Google. Los datos de campo provienen de usuarios reales de Chrome a través de CrUX y son los que aparecen en Google Search Console. Optimiza siempre para los umbrales de datos de campo.
¿Cómo compruebo mis Core Web Vitals en Google Search Console?
Ve a Google Search Console → Experiencia → Core Web Vitals. Verás las URLs divididas en Bueno, Necesita mejorar y Deficiente según datos de usuarios reales. Haz clic en cualquier grupo para ver qué métrica falla. Prioriza las URLs Deficientes.
¿La velocidad de página afecta al posicionamiento en móvil y escritorio por separado?
Sí. Google evalúa los Core Web Vitals por separado para móvil y escritorio. El móvil suele rendir peor. En la mayoría de sectores domina el tráfico móvil — prioriza el rendimiento CWV en móvil y revisa ambos informes en GSC.
