De dónde salen los umbrales y qué no capturan
El método con el que se eligieron 2,5 s, 200 ms y 0,1, por qué el percentil es 75 y no 95, y el inventario completo de lo que las tres métricas dejan sin medir.
Los tres umbrales no son cifras redondas elegidas por comodidad: son el resultado de cruzar investigación en percepción humana con datos reales de millones de sitios, sometidos a dos criterios en tensión. Entender ese método sirve para dos cosas: para dejar de tratarlos como dogma, y para reconocer el territorio que las tres métricas dejan sin cubrir.
- Enunciar los tres criterios con los que se define un umbral y la tensión entre ellos.
- Reconstruir cómo se eligieron 2,5 s, 200 ms y 0,1 a partir de los datos publicados.
- Justificar la elección del percentil 75 frente a alternativas más altas o más bajas.
- Enumerar lo que las tres métricas no miden.
Los criterios
Cada umbral tiene que cumplir tres condiciones, y las tres entran en conflicto entre sí.
Calidad de la experiencia. El umbral bueno debe corresponder a una experiencia de calidad según la investigación en percepción e interacción persona-ordenador. El matiz importante es que esa investigación casi nunca da un valor único: da un rango. Lo que se resume popularmente como “un segundo” es en realidad un intervalo que va de unos cientos de milisegundos a varios segundos, según el usuario y el contexto. Los propios datos agregados del navegador muestran una distribución suave y continua del punto en que la gente abandona, no un escalón.
Alcanzable por el contenido web existente. De nada sirve un umbral que nadie cumple. El criterio operativo es exigente y concreto: al menos el 10% de los orígenes debe cumplir el umbral bueno, y además el contenido bien optimizado tiene que cumplirlo de forma consistente, no por casualidad. Para el umbral malo, el criterio simétrico es que caiga ahí el 10-30% peor de los orígenes.
El mismo umbral para móvil y escritorio. Podría parecer razonable poner umbrales distintos, porque las capacidades de dispositivo y la fiabilidad de red son muy distintas. Se decidió no hacerlo por dos razones: las expectativas del usuario no dependen del dispositivo aunque la alcanzabilidad sí, y clasificar dispositivos es un lío que no termina nunca. La consecuencia es que los umbrales están fijados básicamente por lo alcanzable en móvil, que es el caso restrictivo.
Cómo salió cada número
LCP: 2,5 segundos. La investigación de Card y Miller sitúa el tiempo antes de que el usuario pierda el foco en un rango de aproximadamente 0,3 a 3 segundos. Como el umbral bueno de FCP ya estaba en 1 segundo y el LCP ocurre por definición después del FCP, el rango de candidatos se acotó de 1 a 3 segundos. Después se miró la alcanzabilidad con datos reales:
| Umbral candidato | 1 s | 1,5 s | 2 s | 2,5 s | 3 s |
|---|---|---|---|---|---|
| Orígenes buenos en móvil | 3,5% | 13% | 27% | 42% | 55% |
| Orígenes buenos en escritorio | 6,9% | 19% | 36% | 51% | 64% |
Un segundo queda descartado por no llegar al 10%. De los demás, el criterio decisivo fue la consistencia: analizando los sitios mejor optimizados de la web, 1,5 y 2 segundos no se alcanzaban de forma consistente al percentil 75, y 2,5 sí. Para el umbral malo, 4 segundos clasificaba como malo alrededor del 26% de orígenes móviles y el 19% de escritorio, dentro del objetivo del 10-30%.
INP: 200 milisegundos. Aquí la brecha entre lo deseable y lo alcanzable es la mayor de las tres. La investigación apunta con bastante consenso a 100 ms: los experimentos de Michotte sobre percepción de causalidad muestran que con retardos de hasta unos 100 ms el observador atribuye el efecto a la causa, entre 100 y 200 la percepción es ambigua, y por encima de 200 la conexión causal se pierde. Trabajos más recientes sobre botones virtuales en pantalla táctil encuentran que con retardos de 85 ms o menos los participantes reportan simultaneidad tres de cada cuatro veces, y que la calidad percibida cae a partir de los 100 ms y se desploma hacia los 300.
Pero el dato de alcanzabilidad era demoledor: con umbral de 100 ms, solo el 12% de los orígenes móviles clasificaba como bueno frente al 83% de los de escritorio. Con 200 ms, el 56% en móvil y el 96% en escritorio. De ahí el compromiso.
Para el umbral malo hubo un giro interesante. Con los datos globales, 300 ms habría encajado en el rango del 10-30%. Pero el INP tiene una correlación inversa con la popularidad: los sitios más visitados son más complejos y tienden a peor INP. Mirando los diez mil sitios más populares, un umbral malo de 300 ms habría clasificado como malos a la mayoría de ellos en móvil, lo cual habría hecho que la métrica dejase de discriminar. Con 500 ms el porcentaje vuelve al rango objetivo.
CLS: 0,1. Es la única de las tres sin investigación previa aplicable, por ser una métrica nueva sin equivalente en la literatura. El método fue evaluar páginas reales con distintas cantidades de desplazamiento y observar a partir de dónde se percibía como disruptivo. El resultado: a partir de 0,15 se percibía consistentemente como disruptivo, y hasta 0,1 se notaba pero no molestaba en exceso.
La alcanzabilidad daba margen para ser más estrictos: casi el 50% de los orígenes móviles ya estaba en 0,05 o menos. Se eligió 0,1 en lugar de 0,05 por una razón pragmática y explícita: el contenido incrustado de terceros, como las publicaciones de redes sociales, muchas veces no revela su altura hasta que termina de cargar, y eso hace muy difícil bajar de 0,05. La documentación deja constancia de la esperanza de poder endurecerlo en el futuro. Para el umbral malo, 0,25 clasificaba como malos alrededor del 20% de orígenes móviles y el 18% de escritorio.
La documentación oficial es explícita: son umbrales amplios pensados para aplicarse a toda la web, y muchos sitios se beneficiarían de optimizar más allá del umbral bueno y de correlacionar el rendimiento con sus propias métricas de negocio. Aprobar no es la meta, es el punto donde deja de haber un problema evidente.
Por qué el percentil 75
La elección del percentil responde a dos objetivos que tiran en direcciones opuestas.
El primero es que la mayoría de las visitas experimenten el nivel objetivo, lo cual empuja hacia percentiles altos. El segundo es que el valor no lo determinen unos pocos valores atípicos, lo cual empuja hacia percentiles bajos.
El argumento cuantitativo que resuelve la tensión es directo. Con una página de 100 visitas evaluada al percentil 95, bastan 5 visitas anómalas para que el valor lo decidan ellas. Al percentil 75, harían falta 25 visitas anómalas de 100, que es posible pero mucho menos probable. A cambio, el percentil 75 sigue garantizando que tres de cada cuatro visitas viven el nivel objetivo o mejor.
Vale la pena aterrizar lo que significa en la práctica. Un percentil 75 de LCP en 2,4 segundos no dice “mis usuarios tardan 2,4 segundos”. Dice “una de cada cuatro visitas tarda más de 2,4 segundos”, y ese cuarto puede llegar a tardar quince. Por eso la distribución completa aporta información que el percentil oculta, y por eso conviene mirar siempre el porcentaje de visitas en cada franja además del valor puntual.
El inventario de lo que no capturan
Las tres métricas cubren tres fases y dejan fuera bastante más de lo que la gente supone.
No hay métrica de fluidez. Ninguna Core Web Vital mide si las animaciones o el desplazamiento van a tirones. Es la laguna más grande, y afecta especialmente a productos de interacción continua: mapas, editores, listas largas, visores.
El INP ignora tres gestos completos. Desplazamiento, paso del ratón por encima y zoom quedan fuera por definición. Solo se observan clic, toque y pulsación de tecla.
El LCP mide un solo elemento. No dice si lo que apareció es útil, ni cuándo termina de aparecer el resto. Una página cuyo elemento LCP es el logotipo puede tener un LCP magnífico y un contenido que tarda seis segundos.
Ninguna mide interactividad funcional. Que la página esté pintada y responda a los clics no significa que el formulario funcione, que la validación esté cargada, o que el botón de comprar haga algo. No hay métrica estándar para eso.
Las transiciones en aplicaciones de una sola página no se miden. Cuando la navegación se hace con JavaScript en lugar de con una navegación real del navegador, la plataforma atribuye toda la experiencia a la carga inicial. Es una limitación conocida de las APIs sobre las que se construyen las métricas, no un descuido.
No se mide memoria ni consumo de batería. Una página que va bien durante dos minutos y luego arrastra el dispositivo por presión de memoria puede tener las tres métricas en verde.
El CLS excluye el arrastre y el desplazamiento del indicador de entrada reciente. Solo la entrada discreta activa la exclusión, así que un salto durante un gesto continuo cuenta como desplazamiento inesperado.
Hay una implicación de la metodología que casi nadie extrae y que cambia cómo lees tus propios datos. Como el umbral bueno se fija exigiendo que al menos el diez por ciento de los orígenes lo cumpla, y como se aplica el mismo umbral a móvil y escritorio calibrado por el caso móvil, resulta que aprobar en escritorio es enormemente más fácil que en móvil: con 200 milisegundos de INP aprobaba el 96 por ciento de los orígenes de escritorio frente al 56 por ciento de los de móvil. Si miras tus métricas agregadas sin segmentar y tu tráfico es mayoritariamente de escritorio, vas a aprobar las tres casi por defecto y el semáforo no te va a decir nada sobre tu producto. Y si tu tráfico es mayoritariamente móvil, el mismo semáforo te va a parecer injustamente duro. En ninguno de los dos casos el problema es la métrica: es que el número agregado mezcla dos poblaciones cuya dificultad difiere en un factor grande. La regla operativa que se deriva de esto es sencilla y no negociable: nunca mires una Core Web Vital sin segmentar por tipo de dispositivo. El número agregado no significa nada y varía con la mezcla de tráfico, así que se mueve solo cuando cambia tu campaña de marketing.