La ventana móvil de 28 días de CrUX

Desplegamos un fix de un problema de rendimiento, verificamos que funciona con herramientas de laboratorio y nos quedamos mirando CrUX esperando que el número baje. Pasa una semana y no se mueve. Pasa otra y sigue igual. La sensación es que los datos llegan tarde, o que el cambio no ha servido de nada.

Ninguna de las dos cosas es cierta (bueno, la segunda no lo puedo asegurar). En las auditorías es una de las confusiones que más veces tengo que aclarar, y casi siempre nace del mismo malentendido: mezclar dos cosas que son independientes.

Por un lado está el tamaño de la ventana de agregación. Por otro, la cadencia de publicación. La ventana siempre son 28 días. Diario, semanal y mensual no son ventanas distintas: son cadencias distintas sobre los mismos datos.

Cuatro puertas al mismo dataset

Todas las fuentes de CrUX agregan los datos sobre una ventana móvil de 28 días. Lo que cambia entre ellas es cada cuánto se actualiza el dato y con qué granularidad podemos dividirlo.

La parte que más se malinterpreta: el dato no tiene 28 días de antigüedad, tiene dos. Lo que tarda 28 días es que la ventana rote por completo.

La fila de la History API es la más densa de la tabla, porque no describe un dato sino una serie temporal. Merece un desglose:

• Cada punto es un collection period cuyo valor se calcula sobre una ventana de 28 días.
• Los puntos van semana a semana. Cada uno abarca 28 días pero solo avanza 7, así que se solapan entre sí; lo vemos en detalle más abajo con CrUX Vis.
• La API devuelve 25 puntos por defecto y hasta 40 si los pides con collectionPeriodCount, de unos 6 a unos 10 meses de histórico.

Qué le pasa a la ventana tras un deploy

Cada día que pasa, la ventana suelta un día viejo y coge uno nuevo. Al principio el fix está en una franja mínima; a medida que avanzan los días, va ocupando más proporción de la ventana.

Mueve el control para ver cuánta parte de la ventana contiene ya sesiones posteriores al fix, y qué percentil del dato antiguo estás leyendo en realidad.

Ese tercer indicador es lo que explica la sensación de que no pasa nada. CrUX no reporta la media, reporta el percentil 75, y el p75 de una mezcla no se mueve de forma lineal con la fracción de datos nuevos.

Por qué el p75 parece atascado y luego cae en picado

Suponiendo que el fix mete todas las sesiones nuevas en el bucket bueno, cuando una fracción f de la ventana ya está renovada, el p75 de la mezcla equivale a leer el percentil (0.75 − f) / (1 − f) de la distribución antigua.

Traducido a la práctica:

• f = 0.25: estás leyendo el p67 del dato antiguo. Un desplazamiento pequeño, fácil de confundir con ruido.
• f = 0.50: estás leyendo el p50. Aquí es donde normalmente se cruza el umbral.
• f = 0.75: el p75 pasa a estar determinado por completo por el dato nuevo.

Por eso durante la primera semana y media parece que nada se mueve, y luego, entre la segunda y la tercera semana, baja de golpe. El dato no llega tarde: la métrica es resistente al cambio por diseño. Y si el tráfico no es uniforme, ya sea por fines de semana o por estacionalidad regional, la curva se distorsiona todavía más, porque CrUX pondera por volumen de navegaciones, no por día.

Qué estás viendo en realidad en CrUX Vis

CrUX Vis visualiza la History API, no la API diaria. Esto tiene dos consecuencias concretas:

• Cada punto es una ventana, no una semana. Hay 40 puntos, uno por semana, y cada uno lleva la etiqueta de la fecha de fin de su propia ventana de 28 días, siempre un sábado.
• Dos puntos consecutivos se solapan en 21 días. Solo 7 días de cada punto son nuevos. Tres cuartas partes ya estaban en el punto anterior.

Mueve el control para separar los dos puntos y ver cómo mengua el solapamiento. Las fechas son un ejemplo real de CrUX Vis: el punto A cierra su ventana el sábado 10 de enero y el punto B es el que viene una o varias semanas después.

Por eso la serie se ve tan suave: cada punto ya es un agregado de 28 días, y CrUX Vis los dibuja solapados semana a semana. Un salto entre dos puntos adyacentes nunca representa un cambio semanal real, representa el efecto de intercambiar 7 días de 28.

CrUX es el marcador, no el bucle de feedback

El error de fondo es tratar CrUX como un sistema de feedback rápido. Su lentitud es una propiedad deliberada: suaviza el ruido para que el número se mantenga estable, porque es la fuente de datos de campo de referencia detrás de la evaluación de Core Web Vitals. El feedback rápido va en otra capa.

• Sintético · minutos. DebugBear, Lighthouse CI. Por deploy y en pre-producción. Cero espera, pero es laboratorio.
• Nuestro propio RUM · a las pocas horas. Datos de campo reales con atribución: qué elemento es el LCP, qué target provoca el INP, qué shift dispara el CLS. Ese nivel de detalle CrUX no nos lo va a dar nunca.
• CrUX API diaria · confirmación. Verifica que el fix se está asentando en la fuente que nos puntúa. Conviene consultarla a diario, no una vez al mes.

Una nota operativa: si necesitamos consultar por país, BigQuery es la única fuente de CrUX que expone esa dimensión. La API diaria y la History API solo dan form factor. Para análisis regional, el dataset mensual no es “el lento”, es el único que responde a la pregunta.

Conclusión

CrUX no mide nuestro deploy. Mide a quienes navegan durante 28 días. Si queremos saber si el fix ha funcionado hoy, se lo preguntamos a nuestra herramienta RUM. Si queremos saber si Google lo ha registrado, se lo preguntamos a CrUX dentro de tres semanas.

Referencias: metodología de CrUX, History API y CrUX Vis en Chrome for Developers.