¿Qué son los Core Web Vitals?

Los Core Web Vitals son un subconjunto de las métricas de rendimiento web que Google considera fundamentales para evaluar la experiencia de un usuario en una página. Se anunciaron en mayo de 2020 y forman parte de las señales de SEO técnico que Google agrupa bajo el nombre «page experience», junto con el uso de HTTPS, la ausencia de interstitials intrusivos y una correcta adaptación a móvil.

Hoy son tres métricas: LCP mide la velocidad de carga percibida, INP mide la capacidad de respuesta ante interacciones y CLS mide la estabilidad visual. No sustituyen al resto de indicadores de page speed ni a un análisis completo de rendimiento; son la parte que Google eligió como señal de ranking porque afecta a cualquier tipo de sitio, no solo a uno concreto.

El trío ha cambiado una vez desde su lanzamiento: en marzo de 2024, INP sustituyó a First Input Delay (FID) como tercera métrica, tras año y medio como indicador experimental. Cualquier definición que siga citando FID como parte activa de los Core Web Vitals describe un estado anterior a ese cambio.

Estos umbrales se aplican al percentil 75 de las visitas de una página, calculado por separado para móvil y escritorio: basta con que una cuarta parte de las visitas vaya mal para que la página no pase el corte de «bueno», aunque la mayoría cargue rápido.

INP es la métrica más reciente de las tres. Sustituyó a FID como Core Web Vital oficial el 12 de marzo de 2024, después de un periodo como métrica experimental desde mayo de 2022. La diferencia práctica es que FID solo medía el retraso de la primera interacción, mientras que INP evalúa la respuesta de la página durante toda la visita, así que capta problemas de interactividad que FID pasaba por alto.

Los Core Web Vitals se miden de dos formas distintas, y confundirlas es el error más común al interpretarlos. Los datos de campo proceden del Chrome User Experience Report (CrUX), recogidos a partir de visitas reales de usuarios de Chrome que han dado su consentimiento; reflejan cómo carga la página en la práctica, con la conexión y el dispositivo de cada visitante. Los datos de laboratorio, en cambio, proceden de herramientas como Lighthouse, que simulan una visita bajo condiciones fijas y sirven para diagnosticar un problema de velocidad de carga antes de que llegue a producción, pero no reflejan el uso real.

El informe de Core Web Vitals de Search Console se construye sobre datos de campo, no sobre las simulaciones de Lighthouse: mide lo que percibieron los visitantes reales de cada URL o de un grupo de URLs con estructura similar, agregado por semanas. Cuando una página no acumula tráfico suficiente para tener datos propios en CrUX, Google recurre a los del resto de páginas del mismo origen con esa estructura.

Por eso una URL puede tener una puntuación de laboratorio alta y seguir apareciendo como «mejorable» en Search Console: son dos mediciones tomadas en momentos y condiciones distintos, y solo la de campo refleja lo que experimentaron los usuarios que realmente visitaron esa página.

Los Core Web Vitals son señal de ranking desde 2021, dentro del conjunto más amplio de señales de page experience que Google usa en la búsqueda. Un buen resultado no garantiza el primer puesto: la relevancia del contenido para la consulta sigue pesando más. Pero entre dos páginas igual de relevantes, la que carga rápido y responde sin fricción tiene ventaja.

Lo que un negocio nota primero es el comportamiento del visitante. Una carga lenta o una interfaz que tarda en reaccionar a un clic empuja a abandonar antes de terminar una compra, rellenar un formulario o leer un artículo entero. Ese abandono ocurre al margen de la posición en el buscador, así que optimizar estas métricas beneficia a la conversión aunque el ranking no se moviera ni un puesto.

Por eso conviene tratarlos como parte de la UX del sitio, no como una casilla que marcar para el buscador. Un LCP alto en la página de producto o un CLS que desplaza el botón de compra justo cuando el usuario va a pulsarlo cuesta ventas antes que posiciones.

• Prioriza la carga del elemento above the fold que probablemente sea el LCP, como una imagen de cabecera o un titular grande, y evita retrasarlo con scripts de terceros que no aportan nada visible.
• Reduce el JavaScript que se ejecuta durante la interacción del usuario: dividir tareas largas en fragmentos más pequeños mejora el INP sin tocar el diseño.
• Reserva espacio con width y height (o aspect-ratio) en imágenes, vídeos e iframes, y evita insertar banners o avisos de cookies encima de contenido que ya estaba cargado.
• Sirve las imágenes en formatos modernos como WebP, con lazy loading fuera del área visible inicial, sin retrasar las que sí forman parte del LCP.
• Revisa el informe de Core Web Vitals en Search Console por grupos de URLs, no solo la puntuación de una página suelta en una herramienta de laboratorio.
• Mide en dispositivos reales de gama media, no solo en el portátil de desarrollo: Google indexa y mide sobre todo la versión móvil bajo su criterio de mobile first, y ahí suele notarse más la diferencia.

• Fijarse solo en la puntuación de laboratorio de una herramienta como PageSpeed Insights y no revisar los datos de campo reales, que son los que determinan el informe de Search Console.
• Optimizar el LCP con una imagen comprimida pero seguir cargando fuentes o scripts que bloquean el renderizado antes de que aparezca.
• Confundir INP con FID y seguir citando el «retraso de la primera interacción» como si fuera la métrica vigente; FID quedó obsoleta el 12 de marzo de 2024.
• Corregir el CLS eliminando animaciones necesarias para la usabilidad, en vez de reservar simplemente el espacio que esas animaciones van a ocupar.
• Tratar los Core Web Vitals como un proyecto puntual: sin monitorización continua, un despliegue nuevo puede empeorar un INP que llevaba meses en verde sin que nadie lo note hasta la siguiente revisión de SEO técnico.