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 rilasciato il fix, ora dobbiamo aspettare 28 giorni per vedere se ha funzionato". Questo è sbagliato. I dati non sono vecchi di 28 giorni. Hanno circa due giorni. La confusione nasce da come Google calcola i numeri e, una volta capito questo, il panico dei 28 giorni svanisce.

Ultima revisione di Arjen Karel a marzo 2026

I dati CrUX hanno due giorni, non 28

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

Da dove arrivano allora i 28 giorni?

Quello che vedi in PageSpeed Insights è il 75° percentile calcolato sugli ultimi 28 giorni di dati degli utenti reali. Google usa una finestra mobile di 28 giorni, non perché vuole 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 dà un'immagine stabile e rappresentativa di come gli utenti reali vivono il tuo sito.

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

Una cosa che molti sbagliano: questo è un 75° percentile, non una media. Diverse guide popolari (inclusa quella di Vercel) lo chiamano erroneamente media. La distinzione è importante. Un p75 significa che il 75% delle esperienze utente si trova a questo valore o al di sotto. È 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 rilasci un fix per le prestazioni, i tuoi nuovi dati si mescolano 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 ben 28 giorni per rinnovare 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à all'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 rilasciato un fix

Ecco una sequenza temporale realistica di cosa succede dopo aver rilasciato un miglioramento delle prestazioni:

• Giorno 0: Rilasci il fix. In CrUX non cambia ancora nulla.
• Giorno 2-3: I primi dati migliorati entrano nella finestra di 28 giorni. Se monitori da vicino, potrebbero apparire piccoli spostamenti.
• Giorno 7: Circa un quarto della finestra contiene dati post-fix. Le tendenze iniziano a diventare visibili in CrUX History.
• Giorno 14: Metà della finestra è formata da dati nuovi. Se il tuo fix è stato significativo (ad esempio, il LCP è sceso da 4s a 2s), il p75 si sarà spostato notevolmente.
• Giorno 28: La finestra è completamente rinnovata. CrUX ora riflette le tue prestazioni attuali.

L'entità dello spostamento dipende da tre cose: quanto è stato grande il miglioramento, quanto traffico riceve il tuo sito (più traffico significa più nuovi dati al giorno) e quanto è costante il fix su tutti i caricamenti di pagina.

Tre posti, tre velocità di aggiornamento

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

• API CrUX e PageSpeed Insights: aggiornati quotidianamente (~2 giorni di ritardo). Questo è ciò che usa la maggior parte delle persone.
• API CrUX History: aggiornata settimanalmente il lunedì, con i dati fino al sabato precedente. Alimenta lo strumento 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 di un mese.

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

Non aspettare 28 giorni. Usa il RUM.

I dati CrUX sono di Google. Ti dicono come Google vede il tuo sito. Ma non devi stare seduto ad aspettare. Con il Real User Monitoring puoi tracciare i Core Web Vitals su base giornaliera o persino per singolo caricamento di pagina. Saprai nel giro di ore se il tuo fix 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 quel 44% che ancora non li supera, non lasciare che il mito del "ritardo di 28 giorni" ti impedisca di fare modifiche. I dati sono quasi in tempo reale. La finestra si limita a smussarli.