Core Web Vitals: qué miden, los valores que pide Google y cómo mejorar la velocidad de tu página

Una página lenta, o que salta mientras carga, se nota antes de leer una palabra. Google lo mide con tres números, las Core Web Vitals, y los usa para posicionar. Lo que casi nunca se cuenta es cuánto pesan, por qué tu sitio puede no tener datos y por qué el 100 de PageSpeed no es la meta.

Esto es lo que dicen Google Search Central, web.dev y la documentación de PageSpeed Insights y de Search Console, consultados el 30 de septiembre de 2026. Las páginas de web.dev en español son traducción automática, así que las leímos en inglés.

Las tres métricas

Métrica	Qué mide	Bueno	Necesita mejora	Deficiente
LCP	Cuánto tarda en verse el elemento más grande: la imagen o el bloque de texto principal	2,5 s o menos	Hasta 4 s	Más de 4 s
INP	Cuánto tarda la página en responder a un clic, un toque o una tecla, durante toda la visita	200 ms o menos	Hasta 500 ms	Más de 500 ms
CLS	Cuánto se mueve el contenido sin que lo pidas	0,1 o menos	Hasta 0,25	Más de 0,25

El INP reemplazó al FID el 12 de marzo de 2024. Si una herramienta o un informe todavía te habla de FID, está viejo.

El 75 % de las visitas

Una página aprueba si cumple las tres métricas en el percentil 75 de sus visitas, por separado en celulares y en computadoras. No es un promedio: quiere decir que al menos tres de cada cuatro visitas tienen que estar en «bueno». Google eligió ese corte para que la página ande bien para la mayoría, también con teléfonos y redes lentos.

Dónde se miden

PageSpeed Insights muestra dos cosas distintas, y conviene no mezclarlas:

• Datos de campo: lo que vivieron personas reales en los últimos 28 días, del informe de experiencia de usuarios de Chrome, que solo cuenta a quienes aceptaron compartir datos. Estas son las Core Web Vitals.
• Datos de laboratorio: una carga simulada con Lighthouse, con el puntaje de 0 a 100. Sirve para encontrar problemas, pero no mide el INP, porque nadie toca la página: usa otra métrica en su lugar. El puntaje cambia entre una prueba y otra sin que cambies nada, y Google dice que un buen laboratorio no garantiza una buena experiencia real.

Si los dos no coinciden, web.dev es claro: los datos de campo son los que deben guiar lo que arreglas primero.

Search Console tiene un informe de Core Web Vitals con datos de campo, que agrupa páginas parecidas y muestra el estado de su peor métrica. Es una muestra, solo de páginas indexadas, y al arreglar algo, la validación tarda 28 días → Google Search Console.

«Sin datos» en un sitio chico

Es lo más común en un negocio pequeño, y no es un error. Para tener datos de campo, una página tiene que ser pública, indexable y lo bastante visitada, y Google no publica el mínimo. Si la página no llega, PageSpeed Insights prueba con el sitio entero, y si tampoco alcanza, no muestra datos reales. En Search Console, «No hay datos disponibles» quiere decir lo mismo. Mientras tanto, el laboratorio sirve para encontrar los problemas.

Cuánto pesan para Google

Su página sobre la experiencia de página lo dice en cuatro frases, y vale leerlas juntas:

• «Nuestros sistemas de clasificación usan Core Web Vitals».
• No hay una señal única de experiencia de página.
• La Búsqueda intenta mostrar el contenido más relevante, aunque la experiencia de la página sea deficiente.
• Buenos resultados en Search Console o en otras herramientas no garantizan aparecer arriba, y perseguir un puntaje perfecto solo por SEO puede no valer el tiempo.

Es decir: una página rápida que no contesta lo que buscan no gana; entre varias que sí contestan, la experiencia puede ayudar → posicionamiento SEO.

Lo que suele arreglarlas

Según web.dev, los arreglos con más efecto son estos:

• La imagen principal (LCP). Que esté en el HTML con una etiqueta de imagen normal, no cargada después por código; con prioridad alta (fetchpriority="high"), sin carga diferida y comprimida, en formatos como WebP o AVIF. Según web.dev, en el 73 % de las páginas para celular el elemento más grande es una imagen → cómo comprimir imágenes.
• El servidor (LCP). Servir desde cerca y con caché: web.dev recomienda una CDN.
• El código que bloquea (LCP e INP). Menos CSS y JavaScript antes de que se vea la página, y dividir las tareas largas. Si usas un gestor de etiquetas, revisar sus etiquetas de vez en cuando.
• El tamaño de las imágenes (CLS). Ponerles ancho y alto, para que el navegador reserve su lugar: según web.dev, el 66 % de las páginas tiene al menos una imagen sin tamaño. Lo mismo para anuncios, mapas y videos incrustados.
• Los avisos que entran deslizándose (CLS). Un banner de cookies que empuja el contenido suma a los saltos; si se anima, que sea sin mover lo demás.
• Las fuentes (CLS). Una fuente que carga tarde puede mover el texto; hay ajustes para evitarlo.

Casi todo esto se decide al construir la página, y se cuida después, cada vez que se agrega una foto o una herramienta → mantenimiento de una página web.

Lo que no hay que hacer

• Perseguir el 100. Google dice que no se espera.
• Mirar una sola prueba de laboratorio y sacar conclusiones: varía entre corridas.
• Buscar el informe de «Usabilidad móvil» o el de «Experiencia en la página»: Search Console los retiró.
• Venderlas como «el» factor de posicionamiento. Son uno, y la relevancia va antes.

Fuentes oficiales

• Las métricas web esenciales y la experiencia de página — Google Search Central; INP en las Core Web Vitals, con la actualización del 12 de marzo de 2024 — blog de Search Central.
• Web Vitals, las mejoras más efectivas, optimizar el LCP, optimizar el CLS y por qué difieren el laboratorio y el campo — web.dev, en inglés.
• Acerca de PageSpeed Insights, cómo puntúa Lighthouse y la metodología del informe de Chrome — Google, en inglés.
• El informe de Core Web Vitals — Ayuda de Search Console.