Por qué el retraso de 28 días en Core Web Vitals es un mito
Los datos de CrUX tienen dos días de antigüedad, no 28. Esto es lo que realmente significa la ventana móvil de 28 días.

Desmintiendo el mito del retraso de 28 días en Core Web Vitals
Lo escucho todo el tiempo: "Implementamos la corrección, ahora tenemos que esperar 28 días para ver si funcionó". Esto es incorrecto. Los datos no tienen 28 días de antigüedad. Tienen alrededor de dos días. La confusión proviene de cómo Google calcula las cifras, y una vez que lo entiendes, el pánico de los 28 días desaparece.
Última revisión por Arjen Karel en marzo de 2026
Table of Contents!
- Desmintiendo el mito del retraso de 28 días en Core Web Vitals
- Los datos de CrUX tienen dos días de antigüedad, no 28
- Entonces, ¿de dónde salen los 28 días?
- Por qué las mejoras parecen lentas
- Qué esperar tras implementar una corrección
- Tres lugares, tres velocidades de actualización
- No esperes 28 días. Usa RUM.
Los datos de CrUX tienen dos días de antigüedad, no 28
El Informe de experiencia del usuario de Chrome (CrUX) se actualiza diariamente 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.

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 de usuarios reales. Google utiliza 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 retraso. La ventana simplemente avanza, un día a la vez.
Una cosa en la que mucha gente se equivoca: esto es un percentil 75, no un promedio. Varias guías populares (incluida la de Vercel) lo llaman incorrectamente un promedio. La distinción es importante. Un p75 significa que el 75% de las experiencias de los usuarios están en o por debajo de este valor. Es más resistente al cambio que un promedio porque los valores atípicos en el lado rápido no lo reducen tan rápidamente.
Por qué las mejoras parecen lentas
Cuando implementas una mejora de rendimiento, tus nuevos datos se mezclan con hasta 27 días de datos antiguos. El percentil 75 cambia gradualmente, no de la noche a la mañana.
Piénsalo de esta manera: Tienes una caja con 28 canicas rojas. Cada día sacas una canica roja vieja y la reemplazas por una nueva canica verde. Tomará 28 días completos renovar por completo toda la caja, ¡pero nunca hubo ningún retraso!
La rapidez con la que la caja se vuelve mayormente verde (el cambio del percentil 75) depende de cuántas canicas rojas ya hubiera en ella. Si tu sitio era consistentemente 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 tras implementar una corrección
Esta es una cronología realista de lo que sucede después de implementar una mejora de rendimiento:
- Día 0: Implementas la corrección. Aún no cambia nada en CrUX.
- Día 2-3: Los primeros puntos de datos mejorados entran en la ventana de 28 días. Si supervisas de cerca, pueden aparecer pequeños cambios.
- Día 7: Alrededor de una cuarta parte de la ventana contiene datos posteriores a la corrección. Las tendencias comienzan 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 (digamos, una caída del LCP de 4s a 2s), el p75 se habrá movido notablemente.
- Día 28: La ventana se ha renovado por completo. CrUX ahora refleja tu rendimiento actual.
Lo drástico 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 qué tan 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: actualización diaria (retraso de ~2 días). Esto es lo que usa la mayoría de la gente.
- API de historial de CrUX: se actualiza semanalmente los lunes, con datos hasta el sábado anterior. Alimenta la herramienta de historial de CrUX y los gráficos de tendencias.
- BigQuery de CrUX: se actualiza mensualmente, el segundo martes después de que finalice el período de recopilación. Si solo verificas BigQuery, realmente puede parecer un retraso de un mes.
Si esperas impacientemente a que tus números se muevan, verifica PageSpeed Insights (diariamente), no BigQuery (mensualmente).
No esperes 28 días. Usa RUM.
CrUX son los datos de Google. Te dice cómo ve Google tu sitio. Pero no tienes que sentarte y esperarlo. Con Real User Monitoring puedes rastrear los Core Web Vitals por día o incluso por carga de página. Sabrás en cuestión de horas si tu corrección está funcionando, no en días.
Actualmente, CrUX rastrea 18,56 millones de orígenes con una tasa de aprobación de Core Web Vitals del 55,8%. Si tu sitio se encuentra entre el 44% que aún no la 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.
Performance degrades unless you guard it.
I do not just fix the metrics. I set up the monitoring, the budgets, and the processes so your team keeps them green after I leave.
Start the Engagement
