Perché il ritardo di 28 giorni dei Core Web Vitals è un mito

Sfatare il mito del ritardo di 28 giorni dei Core Web Vitals

Lo sento dire continuamente: "Abbiamo implementato la correzione, ora dobbiamo aspettare 28 giorni per vedere se ha funzionato." Questo è sbagliato. I dati non risalgono a 28 giorni fa. Risalgono a circa due giorni fa. La confusione deriva da come Google calcola i numeri e, una volta compreso questo, il panico dei 28 giorni svanisce.

Ultima revisione di Arjen Karel a marzo 2026

I dati CrUX risalgono a due giorni fa, non a 28

Il Chrome User Experience Report (CrUX) si aggiorna quotidianamente intorno alle 04:00 UTC. Quando interroghi la CrUX API, la risposta include un campo collectionPeriod che mostra l'intervallo di date esatto. La data di fine è tipicamente ieri o l'altro ieri. Da dicembre 2024, anche PageSpeed Insights mostra queste date, così puoi verificarlo di persona.

Quindi da dove vengono i 28 giorni?

Quello che vedi in PageSpeed Insights è il 75° percentile calcolato sugli ultimi 28 giorni di dati di utenti reali. Google utilizza una finestra mobile di 28 giorni non perché voglia ritardare i tuoi dati, ma perché riduce il rumore. Un singolo giorno negativo non affonda il tuo punteggio. Un singolo giorno positivo non lo salva. La finestra ti offre un quadro stabile e rappresentativo di come gli utenti reali vivono l'esperienza sul tuo sito.

Ogni giorno, i dati del giorno più vecchio vengono eliminati e vengono aggiunti quelli del giorno più recente. Non c'è alcun ritardo. La finestra si sposta semplicemente in avanti, un giorno alla volta.

Una cosa su cui molte persone si sbagliano: si tratta di un 75° percentile, non di una media. Diverse guide popolari (inclusa quella di Vercel) la definiscono erroneamente una media. La distinzione è importante. Un p75 significa che il 75% delle esperienze utente è pari o inferiore a questo valore. È più resistente ai cambiamenti rispetto a una media perché i valori anomali sul lato veloce non lo abbassano altrettanto rapidamente.

Perché i miglioramenti sembrano lenti

Quando implementi una correzione delle prestazioni, i tuoi nuovi dati vengono mescolati con un massimo di 27 giorni di dati vecchi. Il 75° percentile si sposta gradualmente, non da un giorno all'altro.

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 28 giorni interi per aggiornare completamente l'intera scatola, ma non c'è mai stato alcun ritardo!

La velocità con cui la scatola diventa per lo più verde (il 75° percentile si sposta) dipende da quante biglie rosse c'erano già al suo interno. Se il tuo sito era costantemente lento, ci sono molte biglie rosse da sostituire. Se era al limite, la scatola diventa verde molto più velocemente.

Cosa aspettarsi dopo aver implementato una correzione

Ecco una sequenza temporale realistica di ciò che accade dopo aver implementato un miglioramento delle prestazioni:

• Giorno 0: Implementi la correzione. Non cambia ancora nulla in CrUX.
• Giorno 2-3: I primi dati migliorati entrano nella finestra di 28 giorni. Se monitori attentamente, potrebbero apparire minuscoli spostamenti.
• Giorno 7: Circa un quarto della finestra contiene dati post-correzione. Le tendenze iniziano a diventare visibili nel CrUX History.
• Giorno 14: Metà della finestra è costituita da dati nuovi. Se la tua correzione è stata significativa (ad esempio, il LCP scende da 4s a 2s), il p75 si sarà spostato in modo evidente.
• Giorno 28: La finestra è completamente aggiornata. CrUX ora riflette le tue prestazioni attuali.

Quanto sia drastico lo spostamento dipende da tre fattori: l'entità del miglioramento, quanto traffico riceve il tuo sito (più traffico significa più nuovi punti dati al giorno) e quanto sia coerente la correzione su tutti i caricamenti di pagina.

Tre luoghi, tre velocità di aggiornamento

Non tutti i dati CrUX si aggiornano allo stesso ritmo. Questa è un'altra fonte di confusione:

• CrUX API e PageSpeed Insights: aggiornati quotidianamente (ritardo di ~2 giorni). Questo è ciò che usa la maggior parte delle persone.
• CrUX History API: aggiornata settimanalmente il lunedì, con i dati fino al sabato precedente. Alimenta il tool CrUX History e i grafici delle tendenze.
• CrUX BigQuery: aggiornato mensilmente, il secondo martedì dopo la fine del periodo di raccolta. Se controlli solo BigQuery, può davvero sembrare un ritardo lungo un mese.

Se aspetti con impazienza che i tuoi numeri si muovano, controlla PageSpeed Insights (giornaliero), non BigQuery (mensile).

Non aspettare 28 giorni. Usa RUM.

CrUX sono i dati di Google. Ti dicono come Google vede il tuo sito. Ma non devi stare seduto ad aspettarli. Con il Real User Monitoring puoi tracciare i Core Web Vitals su base giornaliera o persino per ogni caricamento di pagina. Saprai nel giro di poche ore se la tua correzione sta funzionando, non di giorni.

CrUX attualmente traccia 18,56 milioni di origini con un tasso di superamento dei Core Web Vitals del 55,8%. Se il tuo sito è tra il 44% che ancora non li supera, non lasciare che il mito del "ritardo di 28 giorni" ti impedisca di apportare modifiche. I dati sono quasi in tempo reale. La finestra li stabilizza semplicemente.