Perché il ritardo di 28 giorni dei Core Web Vitals è un mito
Comprendi cosa intende veramente Google quando afferma che i dati dei Core Web Vitals hanno un ritardo di 28 giorni

Sfatare il mito del ritardo di 28 giorni dei Core Web Vitals
L'idea che i dati dei Core Web Vitals subiscano un ritardo di 28 giorni è un malinteso comune nella comunità dello sviluppo web. Questa convinzione ha portato ad affermazioni come "Non possiamo vedere i cambiamenti per altri 28 giorni" o "Speriamo che funzioni; lo sapremo tra 28 giorni." Tuttavia, questa percezione è inesatta e si basa su un'incomprensione di come i dati del Chrome User Experience Report (CrUX) vengono elaborati e presentati.
La realtà dei dati CrUX!
Contrariamente alla credenza popolare, i dati CrUX non sono soggetti a un ritardo di 28 giorni. In realtà, i dati sono notevolmente aggiornati, in genere vecchi solo di circa due giorni. Questo può essere verificato interrogando la Google CrUX API, che dimostra chiaramente la tempestività dei dati!

Comprendere la finestra di 28 giorni
La confusione nasce dal modo in cui Google presenta i dati dei Core Web Vitals. Quello che gli utenti vedono in realtà è il valore del 75° percentile calcolato negli ultimi 28 giorni. Questo approccio statistico è progettato per fornire una misura più stabile e rappresentativa delle prestazioni di un sito web nel tempo, piuttosto che riflettere fluttuazioni a breve termine.
Perché sembra esserci un ritardo
L'uso di una finestra mobile di 28 giorni per il calcolo del 75° percentile può creare l'illusione di un ritardo nel vedere i miglioramenti. Ecco perché:
- Sostituzione graduale dei dati: Inizialmente, questi nuovi dati vengono mescolati con dati sulle prestazioni più vecchi e potenzialmente peggiori. Ogni giorno vengono aggiunti dati alla finestra di prestazioni di 28 giorni e viene rimosso un giorno dei dati più vecchi. Ci vorranno 28 giorni interi perché tutti i dati vengano sostituiti.
- Calcolo del percentile: Poiché viene utilizzato il 75° percentile, ci vuole tempo perché un numero sufficiente di dati migliorati modifichi significativamente questa metrica. Questo potrebbe sembrare controintuitivo, ma non si può pensare ai punteggi percentili allo stesso modo in cui si penserebbe alle medie. Il punto è che il 75° percentile può essere 'resistente al cambiamento' quando si tratta di fluttuazioni improvvise.
Pensala in questo modo: Hai una scatola con 28 biglie rosse. Ogni giorno togli una vecchia biglia rossa e la sostituisci con una nuova biglia verde. Ci vorranno ben 28 giorni per rinnovare completamente l'intera scatola, ma non c'è mai stato alcun ritardo!
La rapidità con cui il barattolo diventa per lo più verde (il 75° percentile) dipende da quante biglie rosse ci sono già. Se ci sono molte biglie rosse, ci vorrà più tempo per diventare verde. Ma se ci sono meno biglie rosse, il barattolo diventerà verde più rapidamente.
Implicazioni per gli sviluppatori web
Comprendere questo meccanismo ha importanti implicazioni per gli sviluppatori web e i proprietari di siti:
- Monitoraggio continuo: Piuttosto che aspettare 28 giorni per vedere i risultati, monitora regolarmente i tuoi Core Web Vitals, preferibilmente con un tracciamento RUM che può calcolare il 75° percentile su un intervallo giornaliero.
- Miglioramenti incrementali: Anche i piccoli miglioramenti possono contribuire a spostare gradualmente il 75° percentile nel tempo.
- Pazienza e persistenza: Sebbene potresti non vedere cambiamenti drammatici immediati nelle metriche riportate, miglioramenti coerenti alla fine si rifletteranno.
17 years of fixing PageSpeed.
I have optimized platforms for some of the largest publishers and e-commerce sites in Europe. I provide the strategy, the code, and the RUM verification. Usually in 1 to 2 sprints.
View Services
