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

Entiende lo que Google realmente quiere decir cuando afirma que los datos de Core Web Vitals tienen un retraso de 28 días

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

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

La noción de que los datos de Core Web Vitals experimentan un retraso de 28 días es un error común en la comunidad de desarrollo web. Esta creencia ha llevado a afirmaciones como "No podemos ver los cambios durante otros 28 días" o "Esperemos que funcione; lo sabremos en 28 días." Sin embargo, esta percepción es inexacta y se basa en una mala interpretación de cómo se procesan y presentan los datos del Chrome User Experience Report (CrUX).

¡La realidad de los datos de CrUX!

Contrariamente a la creencia popular, los datos de CrUX no están sujetos a un retraso de 28 días. De hecho, los datos son notablemente actuales, típicamente con solo dos días de antigüedad. Esto se puede verificar consultando la Google CrUX API, que demuestra claramente la actualidad de los datos!

crux json 2 day delay

Entendiendo la ventana de 28 días

La confusión surge de la forma en que Google presenta los datos de Core Web Vitals. Lo que los usuarios realmente están viendo es el valor del percentil 75 calculado sobre los últimos 28 días. Este enfoque estadístico está diseñado para proporcionar una medida más estable y representativa del rendimiento de un sitio web a lo largo del tiempo, en lugar de reflejar fluctuaciones a corto plazo.

Por qué parece que hay un retraso

El uso de una ventana móvil de 28 días para calcular el percentil 75 puede crear la ilusión de un retraso al ver mejoras. Esta es la razón:

  • Reemplazo gradual de datos: Inicialmente, estos nuevos datos se mezclan con datos más antiguos, potencialmente de peor rendimiento. Cada día se añaden datos a la ventana de rendimiento de 28 días y se elimina un día de los datos más antiguos. Se necesitarán 28 días completos para que todos los datos sean reemplazados.
  • Cálculo del percentil: Dado que se utiliza el percentil 75, se necesita tiempo para que suficientes puntos de datos mejorados desplacen esta métrica significativamente. Esto puede parecer contradictorio, pero no se puede pensar en las puntuaciones de percentil de la misma manera que en los promedios. En resumen, el percentil 75 puede ser 'resistente al cambio' cuando se trata de  fluctuaciones repentinas.

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

La rapidez con la que el frasco se vuelve mayoritariamente verde (el percentil 75) depende de cuántas canicas rojas ya contiene. Si hay muchas canicas rojas, tardará más en volverse verde. Pero si hay menos canicas rojas, el frasco se volverá verde más rápidamente.

Implicaciones para los desarrolladores web

Comprender este mecanismo tiene implicaciones importantes para los desarrolladores web y propietarios de sitios:

  • Monitoreo continuo: En lugar de esperar 28 días para ver resultados, monitorea tus Core Web Vitals regularmente, preferiblemente con seguimiento RUM que pueda calcular el percentil 75 en intervalos diarios.
  • Mejoras incrementales: Incluso pequeñas mejoras pueden contribuir a desplazar gradualmente el percentil 75 con el tiempo.
  • Paciencia y persistencia: Aunque no veas cambios dramáticos inmediatos en las métricas reportadas, las mejoras constantes eventualmente se reflejarán.


Performance is a Feature.

Treating speed as an afterthought fails. Build a performance culture with a dedicated 2-sprint optimization overhaul.

Initialize Project >>

  • 2-Sprint Overhaul
  • Culture Building
  • Sustainable Speed
Por qué el retraso de 28 días en Core Web Vitals es un mitoCore Web Vitals Por qué el retraso de 28 días en Core Web Vitals es un mito