Qué son las Web Vitals y cuáles son las Core
La estructura del programa: qué distingue una Core Web Vital de las demás, qué papel juegan TTFB y FCP, y por qué el conjunto ha cambiado dos veces.
Web Vitals es una iniciativa que intenta resolver un problema real: hasta 2020, cada herramienta medía cosas distintas con nombres parecidos y nadie sabía cuál mirar. La aportación no fue inventar métricas nuevas sino elegir un subconjunto pequeño, definirlo con precisión, fijarle umbrales justificados y hacerlo medible tanto en campo como en laboratorio. Conviene entender la estructura antes de entrar en las definiciones.
- Distinguir las Core Web Vitals de las demás métricas del programa.
- Explicar el papel de TTFB y FCP como métricas de diagnóstico y no de objetivo.
- Enumerar los cambios que ha sufrido el conjunto y qué motivó cada uno.
- Justificar por qué son exactamente tres y no cinco ni una.
Tres métricas, tres fases, un criterio de selección
Las Core Web Vitals actuales son tres y cubren una fase cada una, exactamente las tres que estructuran el track: LCP para la carga, INP para la interacción y CLS para la estabilidad visual.
| Métrica | Qué mide | Fase | Bueno | Malo |
|---|---|---|---|---|
| LCP | Cuándo se renderiza el elemento de contenido más grande visible | Carga | ≤ 2.500 ms | > 4.000 ms |
| INP | Latencia de la peor interacción de la visita, hasta el siguiente pintado | Interacción | ≤ 200 ms | > 500 ms |
| CLS | La mayor ráfaga de desplazamientos de layout inesperados | Estabilidad | ≤ 0,1 | > 0,25 |
Los tres umbrales se evalúan al percentil 75 de las visitas, segmentado entre móvil y escritorio. Una página se clasifica como buena en una métrica si al menos el 75% de sus visitas cumplen el umbral bueno, y como mala si al menos el 25% de sus visitas caen en la zona mala.
Para que una métrica entre en el conjunto Core tiene que cumplir tres condiciones simultáneas, y esa es la razón de que sean tres y no más:
- Aplicable a cualquier página web. No a las de comercio, no a las aplicaciones: a todas. Eso descarta métricas específicas de dominio, por interesantes que sean.
- Medible en campo. Tiene que existir una API del navegador que la exponga en un usuario real, en producción. Esto descarta cualquier cosa que solo se pueda observar en laboratorio con instrumentación especial.
- Reflejar un aspecto distinto de la experiencia. Dos métricas que se correlacionan fuertemente no aportan información independiente y sobra una.
El resto de métricas del programa que no cumplen las tres, o que aún están en evaluación, forman parte de Web Vitals sin ser Core.
Las métricas de diagnóstico
TTFB y FCP no son Core Web Vitals y aparecen constantemente. Su papel es distinto: no son objetivos, son instrumentos de diagnóstico que descomponen el LCP.
TTFB, Time to First Byte, mide desde que el usuario inicia la navegación hasta que el navegador recibe el primer byte de la respuesta del documento. Incluye redirecciones, resolución de DNS, apertura de conexión, negociación TLS y el tiempo de proceso del servidor. Un TTFB alto hace prácticamente imposible un LCP bueno, porque el LCP lo contiene: si tardas 2 segundos en el primer byte, ya has consumido el 80% del presupuesto de 2,5.
FCP, First Contentful Paint, mide cuándo se pinta el primer contenido, sea texto, imagen o cualquier otro elemento con contenido. Marca el final del periodo de pantalla en blanco.
Su valor está en las diferencias, no en los valores absolutos:
- Una diferencia grande entre TTFB y FCP indica que el navegador está descargando muchos recursos que bloquean el renderizado, o que necesita mucho trabajo antes de pintar algo. Es la firma clásica del renderizado en cliente.
- Una diferencia grande entre FCP y LCP indica que el recurso del elemento LCP no estaba disponible pronto para el navegador, o que había otro trabajo pendiente antes de poder mostrarlo.
Estas dos diferencias resuelven, en dos restas, la mitad de los diagnósticos de carga. Vale la pena tenerlas siempre a mano junto al LCP.
Aunque las dos métricas lleven la palabra contentful, no consideran el mismo conjunto de elementos. FCP marca cuándo se pinta cualquier contenido, incluidos elementos que el LCP excluye explícitamente, como imágenes de marcador de posición o imágenes que ocupan toda la ventana y que el navegador considera fondo y no contenido. El LCP es deliberadamente más selectivo porque su objetivo es señalar cuándo aparece el contenido principal, no cuándo aparece contenido cualquiera.
Cómo ha cambiado el conjunto
El grupo de tres no ha sido siempre el mismo, y los dos cambios que ha habido enseñan bastante sobre cómo se diseñan las métricas.
Salió FID, entró INP. First Input Delay medía solo el retraso de la primera interacción, es decir, cuánto tardaba el navegador en empezar a ejecutar el manejador de eventos. No medía cuánto tardaba el manejador, ni cuándo aparecía la respuesta en pantalla, ni qué pasaba con las demás interacciones. Como métrica era muy fácil de aprobar y muy poco informativa: la gran mayoría de sitios tenían un FID bueno mientras sus usuarios se quejaban de que la interfaz no respondía. INP lo sustituyó como métrica estable en marzo de 2024.
Cambió la definición de CLS. En su primera versión, CLS era la suma de todos los desplazamientos de layout durante toda la vida de la página. Eso penalizaba brutalmente a las páginas de sesión larga: una aplicación que el usuario deja abierta ocho horas acumulaba puntuación indefinidamente aunque cada desplazamiento individual fuese minúsculo. La definición actual, basada en la mayor ráfaga dentro de una ventana de sesión, corrige exactamente ese problema.
Ambos cambios comparten una lección: una métrica que se puede aprobar sin mejorar la experiencia es una mala métrica, y una métrica que penaliza patrones legítimos también. El equilibrio entre las dos cosas es lo que se está afinando en cada revisión.
Hay una asimetría que casi nadie tiene en cuenta al planificar el trabajo. Como cada métrica se evalúa por separado al percentil 75, y la etiqueta global de una página exige aprobar las tres, la métrica que peor está determina el resultado entera. Eso tiene una implicación de priorización contundente: mejorar de 2,6 a 2,4 la métrica que está justo al borde vale más, en términos de la etiqueta, que mejorar de 5,0 a 4,0 la que está lejos. Y tiene otra implicación menos obvia y más incómoda: si estás muy lejos del umbral en una métrica, las mejoras intermedias no se ven en el semáforo aunque tus usuarios sí las noten. He visto equipos desmoralizarse porque un trimestre de trabajo real no movió ningún color. La defensa es mirar siempre la distribución completa, no solo el percentil 75: si el porcentaje de visitas buenas sube del 45% al 62%, has mejorado la vida de uno de cada seis usuarios aunque el percentil 75 siga en rojo. Ese es el número que hay que enseñar en la reunión, no el semáforo.
Dónde se miden
Las tres métricas están disponibles en dos mundos que conviene no mezclar.
En campo, con usuarios reales: el conjunto de datos público del navegador Chrome, las herramientas que se apoyan en él, y tu propia instrumentación con la librería web-vitals. Es lo que manda para decidir si hay un problema.
En laboratorio, con una carga sintética: Lighthouse, el panel de rendimiento de las herramientas de desarrollo, y las herramientas de prueba en la nube. Es lo que sirve para averiguar la causa.
Hay una asimetría importante entre las tres: el INP no se mide bien en laboratorio, porque depende de qué interacciones haga el usuario y cuándo. Una herramienta que carga la página y no la toca no puede reportar INP. Por eso, en laboratorio se usa a menudo el Total Blocking Time como aproximación, sabiendo que es un sustituto y no un equivalente.
Las cuatro lecciones siguientes definen cada métrica con precisión quirúrgica, empezando por la que más gente cree conocer.