Core Web Vitals: qué miden de verdad y cómo mejorarlos

Casi todo lo que se escribe sobre Core Web Vitals los trata como si las tres métricas midieran la misma cosa: si tu web carga rápido. Por eso hay tanta gente comprimiendo imágenes durante semanas y suspendiendo igual al final del mes.

Soy Armen Andonian, consultor SEO en Barcelona y fundador de ACERO Digital. Cuando reviso el informe de un cliente, la métrica que aparece en rojo casi nunca es la de la carga. Es la que mide si la página responde cuando alguien la toca, y esa no se arregla tocando imágenes.

Así que aquí van las tres por separado, qué mide cada una, qué las estropea de verdad y en qué orden merece la pena arreglarlas.

¿Qué son los Core Web Vitals?

Los Core Web Vitals son tres métricas con las que Google mide la experiencia real de quien visita tu web: cuánto tarda en aparecer el contenido principal, cuánto tarda la página en reaccionar a un clic y cuánto se mueve la maquetación mientras la persona intenta leer.

La palabra importante es real. No salen de un test que lanzas tú, sino de las visitas de usuarios de Chrome que aceptan compartir sus datos, con sus móviles de hace cuatro años y su cobertura de metro. Google agrega esa información en el Informe sobre la experiencia del usuario en Chrome y de ahí sale lo que ves en Search Console.

Y no son una nota media. Son tres exámenes independientes, y basta con suspender uno para que la URL entre en el grupo de las que necesitan mejoras.

Las tres métricas y cuándo se considera que apruebas

Apruebas una métrica cuando el 75 % de las visitas reales a esa página queda dentro del umbral bueno. Da igual lo bien que vaya para el usuario medio: si una de cada cuatro personas lo pasa mal, suspendes.

Ese detalle del percentil 75 explica casi todas las discusiones que he tenido con equipos de desarrollo. Ellos abren la web en un portátil nuevo conectado a fibra y la ven volar. El dato de Google viene de un Android de gama media en Sants con tres pestañas abiertas.

¿Qué pasó con FID y por qué ahora suspende INP?

En marzo de 2024 Google retiró First Input Delay y puso Interaction to Next Paint en su lugar. Ese cambio es el motivo de que muchas webs que llevaban años en verde amanecieran un día en ámbar sin haber tocado una línea de código.

FID medía solo una cosa: el retraso hasta que el navegador empezaba a atender la primera interacción de la visita. No medía cuánto tardaba en terminarla ni si la pantalla llegaba a cambiar. Era un examen tan generoso que lo aprobaba prácticamente todo el mundo, y por eso servía de poco.

INP mide el ciclo entero: desde que la persona toca hasta que el siguiente fotograma aparece en pantalla con el resultado. Además no se queda con la primera interacción, sino que vigila prácticamente todas las de la visita y se queda con las peores. Si tu menú desplegable tarda medio segundo en abrirse en el tercer clic, ahí queda registrado.

Mi opinión, sin adornos: INP es la mejor métrica que ha publicado Google en años, porque castiga exactamente lo que más molesta a un usuario. La sensación de haber pulsado y que no pase nada.

LCP: qué elemento mide y cómo hacer que aparezca antes

El LCP marca el momento en que se pinta el elemento más grande del área visible, que en la mayoría de webs es la imagen de cabecera o el titular grande. Antes de optimizar nada, averigua cuál es ese elemento en tu página: PageSpeed Insights te lo señala con nombre y apellidos, y a veces sorprende.

Lo que más veces me he encontrado estropeando el LCP no es el peso de la imagen, es la carga diferida aplicada a todo. Alguien activa el lazy loading global desde un plugin, la imagen de cabecera entra en el saco, y el navegador se pone a esperar para descargar justo lo primero que la persona necesita ver.

Ordena la carga en lugar de solo aligerarla. Quita el diferido de la imagen de cabecera, márcala con fetchpriority="high", y sírvela en formato moderno con un tamaño acorde a la pantalla. Si tu servidor tarda más de medio segundo en devolver el HTML, el problema está antes de la imagen y ninguna compresión te va a salvar: ahí toca revisar de dónde salen los segundos de la web entera.

INP: por qué tu web tarda en responder al clic

El INP se hunde por JavaScript ocupando el hilo principal del navegador, no por el peso de tus fotos. Cuando alguien pulsa, el navegador tiene que terminar la tarea que estaba haciendo, ejecutar tu código de respuesta y luego pintar el resultado. Cualquiera de esos tres momentos puede alargarse.

Los culpables habituales tienen nombre. El gestor de cookies que se ejecuta justo cuando la persona empieza a moverse por la página. El widget de chat que carga su propio paquete de código. Un contenedor de Tag Manager al que se le han ido añadiendo etiquetas durante cuatro años y nadie ha limpiado nunca.

La primera medida no es técnica, es de inventario: abre tu Tag Manager y borra lo que ya no usa nadie. En muchas webs eso solo ya devuelve la métrica al verde.

Después vienen los arreglos de código, y ahí necesitas a quien mantenga la web. Partir las tareas largas para devolver el control al navegador entre trozo y trozo. Evitar el layout thrashing, que es leer medidas del diseño justo después de haberlo modificado. Reducir el número de elementos del DOM, porque cada actualización obliga al navegador a recalcular más. Para bloques largos fuera de pantalla, la propiedad content-visibility evita renderizar lo que aún nadie ve.

CLS: los saltos de maquetación que te cuestan pedidos

El CLS mide cuánto se desplaza el contenido visible sin que el usuario haya hecho nada, y es la métrica más barata de arreglar de las tres. También es la que más dinero pierde en silencio, porque un salto en el momento justo convierte un clic en “Comprar” en un clic en “Suscríbete a la newsletter”.

Las causas son casi siempre las mismas cuatro. Imágenes sin atributos de ancho y alto, así que el navegador no reserva su hueco. Banners publicitarios o avisos de cookies que se inyectan encima del contenido ya pintado. Fuentes personalizadas que sustituyen a la de reserva y cambian la altura del texto. Y contenido cargado tarde por JavaScript que empuja lo demás hacia abajo.

Ninguna necesita rehacer la web. Declara las dimensiones de imágenes y de vídeos, reserva por CSS el espacio del bloque que vas a inyectar, y monta los avisos de cookies como una capa superpuesta en lugar de como una barra que empuja la página. Un rato de trabajo, y esta métrica suele ser la primera en ponerse verde.

¿Qué significa exactamente aprobar los Core Web Vitals?

Aprobar significa que las tres métricas quedan dentro del umbral bueno en el percentil 75 de tus visitas reales de los últimos 28 días, contando móvil y ordenador como dos evaluaciones distintas. Es una ventana móvil, no una foto del día.

De ahí sale la queja que escucho cada vez que alguien arregla algo un martes. El miércoles el informe sigue igual, y la conclusión precipitada es que el arreglo no ha servido. Lo que pasa es que el dato todavía carga con casi un mes de visitas anteriores al cambio.

Hay otro detalle que confunde mucho en Search Console: el informe agrupa URLs parecidas y les asigna el resultado del grupo. Si tienes una plantilla de producto con dos mil direcciones, verás dos mil URLs afectadas por un solo problema de plantilla. Suena catastrófico en el panel y suele ser un arreglo único.

¿Cuál de las tres arreglo primero?

Empieza por el CLS. Es el que menos horas de desarrollo consume, el que da resultado visible antes y el que está estropeando conversiones ahora mismo en tu móvil. Cuando el CLS está resuelto, ataca el LCP, que también es bastante autónomo.

Deja el INP para el final, no porque importe menos, sino porque suele exigir decisiones que no son solo técnicas: quitar un chat, renunciar a una etiqueta de medición, discutir con marketing por un script. Esa conversación va mejor cuando ya has enseñado dos métricas en verde.

Si trabajas sobre una web con años encima, esta priorización sale sola de una auditoría SEO que cruce el informe de campo con la plantilla que genera cada grupo de URLs. Arreglar plantillas rinde muchísimo más que arreglar páginas sueltas.

Lo que cambia de verdad cuando los arreglas

Voy a ser honesto con lo que puedes esperar. Como factor de posicionamiento, los Core Web Vitals pesan poco y funcionan como desempate entre resultados que responden igual de bien a la búsqueda. Nadie sube veinte posiciones por bajar su INP, y quien te lo prometa te está vendiendo humo. Si tu página todavía no compite por relevancia, lo que mueve la aguja está en lo que hagas dentro de la propia página, no en el rendimiento.

Donde sí lo notas es en lo que pasa después del clic. Una página que responde al instante y no se mueve bajo el dedo retiene a gente que antes se iba antes de ver tu oferta, y eso aparece en el carrito y en el formulario, no en el ranking. Por eso trato estas tres métricas como un asunto de negocio con una recompensa de SEO al lado, y no al revés.

Mira tu informe de Core Web Vitals esta semana y quédate con una sola cosa: cuál de las tres está en rojo. Si es el CLS, lo resuelve tu equipo en una tarde. Si es el INP y no sabes por dónde entrar, escríbeme y lo miramos juntos, o echa un vistazo a cómo trabajamos en consultoría SEO.