Core Web Vitals: cómo medirlas y mejorarlas

Seguro que has hecho esto alguna vez: metes tu web en PageSpeed Insights, esperas el numerito y sale un naranja de esos que duelen. Primer impulso, instalar un plugin de caché y volver a medir. El numerito sube. ¿Ha mejorado algo para la persona que entra desde el móvil mientras espera el autobús? Ni idea. El numerito no lo dice.

Las Core Web Vitals son tres métricas de experiencia real que miden cuándo aparece el contenido principal, cuánto tarda la página en responder y si el diseño se mueve mientras carga. Google las usa dentro de sus sistemas de experiencia de página. Y no, una buena puntuación no te garantiza posiciones.

El diagnóstico útil no empieza persiguiendo el 100. Empieza por saber qué métrica falla, en qué grupo de páginas y por qué.

Qué miden LCP, INP y CLS

Cada métrica cuenta un problema distinto. LCP habla de carga, INP de respuesta y CLS de estabilidad visual.

Un matiz que casi nadie mira: Google evalúa estos umbrales en el percentil 75 de las visitas reales. Tu prueba rápida en el portátil de la oficina, con fibra, no representa esa distribución. La documentación oficial de Core Web Vitals mantiene las métricas y los umbrales vigentes.

Datos de campo y laboratorio no son intercambiables

Piensa en la diferencia entre el consumo homologado de un coche y lo que gasta de verdad en tu trayecto diario. Eso son laboratorio y campo. Los datos de campo salen de usuarios reales. Los de laboratorio simulan una carga controlada para encontrar causas.

PageSpeed Insights combina ambos cuando hay muestra suficiente. CrUX aporta las experiencias agregadas de Chrome y Lighthouse ejecuta la prueba de laboratorio. Una URL puede aprobar en laboratorio y suspender en campo: dispositivos más lentos, conexiones peores, el banner de cookies, scripts que solo aparecen en algunas sesiones.

También pasa al revés. Acabas de mejorar la página, Lighthouse te aplaude y el informe de campo sigue arrastrando visitas de hace semanas. Google explica ese desfase en la documentación de Chrome UX Report.

Cómo afecta esto al SEO

Menos de lo que promete quien vende la puntuación perfecta y más de lo que cree quien la ignora. Core Web Vitals forma parte de la experiencia de página, pero no sustituye la relevancia, el contenido ni los enlaces. Corregir una URL lenta elimina fricción. No convierte una página irrelevante en el mejor resultado.

Por eso en THECOOKIES no usamos la puntuación como promesa SEO. La tratamos como una señal técnica que afecta a rastreo, experiencia y conversión. En la guía de velocidad de carga web está el contexto amplio. Aquí vamos a lo concreto: diagnosticar las tres métricas.

Si falla el LCP

Primero localiza el elemento que Google considera contenido principal: en Lighthouse o DevTools se ve directamente. Después separa dónde se pierde el tiempo, porque el culpable puede ser el servidor, la imagen hero, una fuente, CSS bloqueante o contenido renderizado en el navegador.

El orden que seguimos nosotros:

1. Localizar el elemento LCP en Lighthouse o DevTools.
2. Separar tiempo de servidor, descubrimiento del recurso, descarga y renderizado.
3. Comprobar tamaño, formato y prioridad de la imagen principal.
4. Revisar si CSS, fuentes o JavaScript retrasan su aparición.
5. Repetir la prueba en la plantilla, no solo en una URL.

¿Por qué tanto desglose? Porque comprimir una imagen no arregla un LCP cuyo problema está antes de pedirla. Nos hemos encontrado webs con todas las imágenes en WebP impecables y un servidor que tardaba más en contestar que todo lo demás junto. La recomendación correcta aplicada al cuello de botella equivocado no mueve nada.

Si falla el INP

INP mide cuánto tarda la página en reaccionar cuando alguien toca algo. Menús, filtros, formularios y el gestor de consentimiento son los sospechosos habituales.

La forma de encontrarlo: reproducir la interacción lenta y registrar qué tarea ocupa el navegador antes de pintar la respuesta. Dividir tareas largas, reducir JavaScript y aplazar trabajo secundario suele dar más resultado que retocar una animación.

Un detalle: INP necesita interacciones reales. Una página con poca muestra puede no enseñar esta métrica en CrUX, aunque Lighthouse sí señale el trabajo bloqueante.

Si falla el CLS

CLS es el clásico «iba a pulsar el botón y se me ha movido». Se corrige reservando espacio antes de que lleguen imágenes, fuentes, banners y contenido dinámico.

Las causas de siempre: imágenes sin dimensiones, avisos que aparecen encima del contenido, fuentes que cambian el tamaño del texto y componentes que se insertan después de cargar. La solución pasa por definir proporciones, reservar contenedores y no meter nada por encima de lo que la persona está leyendo.

Ojo con quedarse en el valor agregado. Una animación iniciada por el usuario no cuenta igual que un salto inesperado, así que hay que reproducir el recorrido, no solo leer el número.

Cómo priorizar las mejoras

Por plantilla, no por URL suelta. Una corrección en la cabecera común mejora cientos de páginas de golpe. Ajustar una página aislada puede no mover el percentil del grupo.

Nuestro orden de trabajo:

• Agrupar URLs por plantilla y problema en Search Console.
• Reproducir una URL representativa con datos de laboratorio.
• Corregir la causa compartida en un entorno de prueba.
• Comparar antes y después con la misma configuración.
• Desplegar y vigilar los datos de campo en la siguiente ventana de medición.

Las Core Web Vitals no se arreglan instalando un plugin y dándose por satisfecho. Se corrige el sistema que genera el problema. Y cuando eso exige tocar renderizado, componentes o arquitectura, ya estamos hablando de desarrollo web a medida, no de una capa de pintura.