Las Core Web Vitals son las tres métricas con las que Google mide la experiencia de quien abre tu web. Miden la velocidad de carga, la capacidad de respuesta y la estabilidad visual. Las tres salen de visitas reales, con el móvil y la conexión que tenga cada visitante, no de una prueba de laboratorio.
Suena a cosa de programadores, pero de estas tres cifras depende que quien te busca llegue a ver lo que vendes. Si la página tarda, se marcha antes. Google además las usa como señal de posicionamiento, aunque, como verás más abajo, pesan menos que el contenido.
Qué son las Core Web Vitals y de dónde salen
En 2020 Google agrupó las métricas de rendimiento que había y creó las Web Vitals, un conjunto de indicadores para medir la calidad de la experiencia web. Las Core Web Vitals son el subconjunto que Google pide vigilar a cualquiera que tenga una web, y las que aparecen en Search Console y en el resto de sus herramientas.
Con una sola métrica no basta, porque una web puede aparecer rápido en pantalla y luego tardar medio segundo en reaccionar a cada clic. Son tres métricas para tres momentos distintos de la visita.
Los datos salen de quien navega con Chrome, con el móvil y la conexión que tenga cada uno. Un móvil de gama media con mala cobertura cuenta igual que un portátil con fibra.
Las tres métricas y qué mide cada una
Estos son los umbrales que marca Google. Una URL solo aprueba cuando el 75% de las visitas se queda en la banda buena.
Métrica | Qué mide | Bien | Mal |
|---|---|---|---|
LCP | Velocidad de carga | 2,5 s o menos | Más de 4 s |
INP | Capacidad de respuesta | 200 ms o menos | Más de 500 ms |
CLS | Estabilidad visual | 0,1 o menos | Más de 0,25 |
Largest Contentful Paint (LCP)
El LCP mide lo que tarda en aparecer el elemento más grande de la primera pantalla, o sea, lo que se ve sin hacer scroll. Casi siempre es la imagen de cabecera o el bloque de texto principal.
Por debajo de 2,5 segundos vas bien, y a partir de 4 Google lo da por malo. Suele fallar por un servidor que tarda en responder, imágenes de varios megas sin comprimir y hojas de estilo o scripts que el navegador tiene que descargar antes de dibujar la página.
Interaction to Next Paint (INP)
Cada vez que un usuario pulsa un botón, abre un menú o escribe en un formulario, el navegador tarda un rato en reaccionar y en mostrar el cambio. El INP mide ese retardo durante toda la visita y se queda con la peor interacción.
El listón está en 200 milisegundos, y por encima de 500 el usuario ya nota que la web va con retraso. El problema suele venir del JavaScript: ocupa el hilo principal del navegador y lo deja sin atender los clics del usuario.
El 12 de marzo de 2024 INP sustituyó a FID como métrica estable, según el anuncio oficial de Google. La diferencia es que FID solo medía la primera interacción de la visita. Si te cruzas con documentación anterior a esa fecha que hable de First Input Delay, está describiendo el modelo viejo.
Cumulative Layout Shift (CLS)
El usuario va a pulsar un enlace, se carga un banner justo encima, el contenido baja y acaba pulsando otra cosa. El CLS mide esos saltos: cuánto contenido se desplaza y cuánta distancia recorre.
De las tres, es la única que se mide con una puntuación en vez de en tiempo. Aprueba con 0,1 o menos y suspende a partir de 0,25. Empeora con las imágenes y los vídeos sin dimensiones declaradas, con los anuncios que empujan el texto hacia abajo y con las fuentes que cargan tarde.
Cuánto pesan las Core Web Vitals en el posicionamiento
Las Core Web Vitals cuentan como factor de posicionamiento desde el verano de 2021, cuando Google desplegó en móvil la actualización de experiencia en la página, y desde febrero de 2022 también en escritorio. Google mira además otras cosas de la página, como que se sirva por HTTPS, aunque avisa de que esas otras señales no te suben de posición por su cuenta.
Google enseña el contenido más relevante aunque la experiencia de página sea mediocre, y lo dice así de claro en esa misma documentación. El contenido pesa más que las Core Web Vitals. Lo que sí dice es que, cuando hay mucho contenido bueno peleando por la misma búsqueda, una buena experiencia ayuda a quedarse con el sitio.
Para que veas un ejemplo real, Vodafone rehízo la carga de su web en Italia, mejoró el LCP un 31% y acabó vendiendo un 8% más. Ir rápido no solo ayuda a que te encuentren, también a que quien ya ha entrado no se marche antes de comprar.
Herramientas para medir las Core Web Vitals
Los datos de campo los generan los usuarios que ya han pasado por tu web y son los que cuentan para el ranking. Los de laboratorio son simulaciones en condiciones fijas, útiles para diagnosticar y para probar cambios antes de subirlos, pero una buena nota ahí no garantiza una buena métrica de campo. Cada herramienta usa unos, otros o los dos.
Search Console te da la vista general del sitio con datos de campo y agrupa las URLs con comportamiento parecido, así ves de un vistazo cuántas están en rojo. Se empieza por aquí, en el mismo panel donde ya revisas posiciones, clics e impresiones.
PageSpeed Insights analiza una página suelta y junta las dos fuentes: los datos de campo de los últimos 28 días, si esa URL tiene visitas suficientes, y una prueba de laboratorio con recomendaciones. Úsala cuando ya sabes qué URL falla.
Lighthouse es laboratorio puro y te devuelve una nota con la lista de mejoras de la página que le pases, útil para comparar el antes y el después de un cambio, aunque esa nota no equivale a lo que Google mide en tus usuarios.
El panel de rendimiento de Chrome DevTools también es laboratorio y te enseña la secuencia de carga segundo a segundo. Lo abres cuando ya sabes que hay un problema y quieres ver qué script concreto lo provoca.
Con Search Console ves qué URLs fallan y con las otras tres averiguas por qué. Si tu web no reúne visitas suficientes para el informe de campo, solo vas a tener datos de laboratorio, así que te toca guiarte por ahí y asumir que el dato es aproximado.
Cuatro cambios para que tu web vaya rápida
Estos cuatro cambios van por tipo y no por métrica, porque tocar las imágenes o el JavaScript mejora varias a la vez. Casi todo se hace en el código, la plantilla o el servidor, así que esto es lo que tienes que pedirle a quien lleve la parte técnica de tu web.
Optimiza y comprime las imágenes
Las imágenes son sobre todo cosa del LCP: en la mayoría de webs, el elemento más grande de la primera pantalla es una imagen. Pásalas a formatos modernos como WebP o AVIF, guárdalas al tamaño en el que se van a ver y evita cargar una foto de 2.000 píxeles de ancho para mostrarla a 600.
El lazy loading, o carga en diferido, deja las imágenes para cuando el usuario baja. Es un error habitual dejarlo puesto también en la imagen de cabecera, que es justo la que Google cronometra. Esa imagen se carga con el atributo fetchpriority y el valor high, y el diferido lo dejas para el resto. Comprimir suele dar el mayor resultado con el menor esfuerzo, y por eso empezamos por ahí cuando ponemos a punto la velocidad de una web.
Aligera el JavaScript que bloquea la carga
Tocar el JavaScript mejora el INP y de paso el LCP: ocupa el hilo principal del navegador, y mientras se ejecuta no se dibuja la página ni se atienden los clics. Con los atributos defer y async le dices al navegador que puede dejar un script para más tarde. Ponlos en todo lo que no haga falta para pintar la primera pantalla y parte las tareas largas en trozos de menos de 50 milisegundos, para que pueda atender un clic entre medias.
Revisa también qué scripts de terceros tienes, normalmente el chat, el mapa, el píxel de publicidad y el gestor de etiquetas que nadie ha tocado en dos años. Cada uno suma milisegundos al INP. Quita lo que no uses y deja el resto para cuando el usuario ya pueda interactuar.
Reserva el espacio de lo que carga tarde
Dile al navegador cuánto espacio va a ocupar cada cosa antes de que llegue y el CLS deja de subir. Declara el ancho y el alto de imágenes y vídeos con los atributos width y height, o su proporción en el CSS, y deja una altura fija reservada para banners, anuncios y avisos de cookies.
Las fuentes dan el otro problema habitual, porque si el texto se dibuja primero con una tipografía y luego cambia, el párrafo entero se recoloca. Precárgalas con rel=preload si van en la primera pantalla y coloca los elementos nuevos por debajo de lo que el usuario ya está leyendo.
Apóyate en una CDN y en la caché
Una CDN es una red de servidores repartidos por el mundo que sirve tus archivos desde el más cercano a quien visita la web. La caché, por su parte, evita repetir el mismo trabajo en cada visita. Actívalas desde el panel de tu hosting o pon una CDN por delante: las dos cosas recortan el tiempo hasta el primer byte, o sea, lo que tarda tu servidor en empezar a contestar.
El LCP arranca ahí. Un hosting compartido saturado lo empeora por muy optimizadas que tengas las imágenes, y llega un punto en el que seguir tocando la página ya no compensa lo que tarda el servidor. Si el LCP falla solo en algunas URLs, suele ser cosa de la plantilla; si falla en todas por igual, mira el alojamiento.
Por dónde empezar
Abre Search Console, entra en el informe de Core Web Vitals y apunta cuántas URLs te salen en rojo. Esa lista es lo primero que hay que llevarle a quien toque tu web, porque sin ella se arregla a ciegas.
Ten paciencia con el resultado, eso sí. Los datos de campo se calculan sobre los últimos 28 días, así que entre que se sube el arreglo y Search Console lo pinta en verde pasan semanas.
Y no es un trabajo de una vez. Cada plantilla nueva y cada script que añades las mueve, así que van en el informe de cada mes y se revisan a fondo después de cada cambio grande.
Si sospechas que tu web va lenta y no sabes por dónde tirar del hilo, te hacemos un análisis SEO gratuito. Te decimos qué está frenando tus métricas y qué arreglaríamos primero, y si hace falta nos encargamos de optimizar las Core Web Vitals.
