Por qué el retraso de 28 días de los Core Web Vitals es un mito

Los datos de CrUX tienen dos días, no 28. Esto es lo que realmente significa la ventana móvil de 28 días.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-07-14

Desmintiendo el mito del retraso de 28 días en los Core Web Vitals

Lo escucho todo el tiempo: «Desplegamos la corrección, ahora tenemos que esperar 28 días para ver si funcionó». Esto es falso. Los datos no tienen 28 días de antigüedad. Tienen unos dos días. La confusión proviene de cómo Google calcula los números, y una vez que entiendes eso, el pánico de los 28 días desaparece.

Última revisión de Arjen Karel en marzo de 2026

Los datos de CrUX tienen dos días de antigüedad, no 28

El Chrome User Experience Report (CrUX) se actualiza a diario alrededor de las 04:00 UTC. Cuando consultas la API de CrUX, la respuesta incluye un campo collectionPeriod que muestra el rango de fechas exacto. La fecha de finalización suele ser ayer o anteayer. Desde diciembre de 2024, PageSpeed Insights también muestra estas fechas, para que puedas comprobarlo por ti mismo.

crux json 2 day delay

Entonces, ¿de dónde salen los 28 días?

Lo que ves en PageSpeed Insights es el percentil 75 calculado sobre los últimos 28 días de datos reales de los usuarios. Google usa una ventana móvil de 28 días, no porque quieran retrasar tus datos, sino porque suaviza el ruido. Un solo día malo no hunde tu puntuación. Un solo día bueno no la salva. La ventana te ofrece una imagen estable y representativa de cómo los usuarios reales experimentan tu sitio.

Cada día, los datos del día más antiguo desaparecen y se añaden los datos del día más reciente. No hay ningún retraso. La ventana simplemente avanza, un día a la vez.

Algo en lo que muchos se equivocan: esto es un percentil 75, no una media. Varias guías populares (incluida la de Vercel) lo llaman media de forma incorrecta. La diferencia importa. Un p75 significa que el 75 % de las experiencias de usuario son iguales o inferiores a este valor. Es más resistente al cambio que una media porque los valores atípicos del lado rápido no lo reducen tan rápido.

Por qué las mejoras parecen lentas

Cuando despliegas una corrección de rendimiento, tus nuevos datos se mezclan con hasta 27 días de datos antiguos. El percentil 75 se desplaza gradualmente, no de la noche a la mañana.

Piénsalo así: tienes una caja con 28 canicas rojas. Cada día sacas una canica roja vieja y la reemplazas por una canica verde nueva. Tomará 28 días completos renovar toda la caja, ¡pero nunca hubo ningún retraso!

La rapidez con la que la caja se vuelve mayormente verde (el percentil 75 se desplaza) depende de cuántas canicas rojas hubiera ya en ella. Si tu sitio era sistemáticamente lento, hay muchas canicas rojas que reemplazar. Si estaba en el límite, la caja se vuelve verde mucho más rápido.

Qué esperar después de desplegar una corrección

Esta es una línea de tiempo realista de lo que sucede después de desplegar una mejora de rendimiento:

  • Día 0: Despliegas la corrección. Aún no cambia nada en CrUX.
  • Días 2-3: Los primeros puntos de datos mejorados entran en la ventana de 28 días. Si monitoreas de cerca, pueden aparecer pequeños cambios.
  • Día 7: Aproximadamente una cuarta parte de la ventana contiene datos posteriores a la corrección. Las tendencias empiezan a ser visibles en el historial de CrUX.
  • Día 14: La mitad de la ventana son datos nuevos. Si tu corrección fue significativa (por ejemplo, el LCP baja de 4 s a 2 s), el p75 se habrá movido notablemente.
  • Día 28: La ventana se ha renovado por completo. CrUX ahora refleja tu rendimiento actual.

Lo dramático del cambio depende de tres cosas: qué tan grande fue la mejora, cuánto tráfico recibe tu sitio (más tráfico significa más puntos de datos nuevos por día) y cuán consistente es la corrección en todas las cargas de la página.

Tres lugares, tres velocidades de actualización

No todos los datos de CrUX se actualizan al mismo ritmo. Esta es otra fuente de confusión:

  • API de CrUX y PageSpeed Insights: se actualizan a diario (desfase de unos 2 días). Esto es lo que usa la mayoría de la gente.
  • API del historial de CrUX: se actualiza semanalmente los lunes, con datos hasta el sábado anterior. Alimenta la herramienta del historial de CrUX y los gráficos de tendencias.
  • BigQuery de CrUX: se actualiza mensualmente, el segundo martes después de que termine el periodo de recopilación. Si solo revisas BigQuery, realmente puede parecer un retraso de un mes.

Si esperas con impaciencia a que tus números se muevan, revisa PageSpeed Insights (a diario), no BigQuery (mensual).

No esperes 28 días. Usa RUM.

CrUX son los datos de Google. Te dicen cómo ve Google tu sitio. Pero no tienes que sentarte a esperar. Con Real User Monitoring puedes rastrear los Core Web Vitals por día o incluso por carga de la página. Sabrás en unas horas si tu corrección funciona, no en días.

CrUX rastrea actualmente 18,56 millones de orígenes con una tasa de aprobación de los Core Web Vitals del 55,8 %. Si tu sitio se encuentra entre el 44 % que aún no aprueba, no dejes que el mito del «retraso de 28 días» te impida hacer cambios. Los datos son casi en tiempo real. La ventana simplemente los suaviza.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

CoreDash trae MCP de serie.

Conéctalo a Claude o a cualquier AI agent. Pregúntale por qué se disparó tu INP el martes pasado.

Mira cómo funciona
Por qué el retraso de 28 días de los Core Web Vitals es un mito Core Web Vitals Por qué el retraso de 28 días de los Core Web Vitals es un mito