Le Core Web Vitals esistono dal 2020, e in pochi anni sono diventate il riferimento comune per parlare di prestazioni web: sviluppatori, responsabili marketing, agenzie e clienti usano gli stessi tre nomi, LCP, INP e CLS, e le stesse soglie. Proprio per questo, ogni volta che Google annuncia un cambiamento, il settore si interroga: cosa cambierà, quando, e cosa bisogna fare?
Prevedere il futuro in dettaglio è impossibile, ma la storia di questi anni e il modo in cui il programma è organizzato permettono di capire come le metriche evolvono, quali direzioni sono già visibili e come prepararsi senza inseguire ogni novità. In questo articolo ripercorriamo i cambiamenti avvenuti, spieghiamo il ciclo di vita di una metrica, guardiamo alle aree in sperimentazione e proponiamo un modo di lavorare che resti valido qualunque cosa succeda.
Da dove veniamo
Prima delle Core Web Vitals, le metriche di prestazione erano molte e disomogenee: tempo di caricamento completo, tempo al primo byte, indici di velocità visiva, punteggi aggregati. Ciascuno strumento misurava a modo suo, e i confronti erano difficili. Nel 2020 Google ha proposto un insieme ridotto di metriche, scelte con alcuni criteri precisi: centrate sull’esperienza dell’utente, misurabili sugli utenti reali, rappresentative di aspetti distinti dell’esperienza. Le prime tre erano il Largest Contentful Paint per il caricamento, il First Input Delay per la reattività e il Cumulative Layout Shift per la stabilità visiva.
Da allora i cambiamenti sono stati pochi ma significativi. Nel 2021 l’esperienza della pagina è entrata tra i segnali di posizionamento per le ricerche da mobile, e l’anno successivo anche da desktop, come abbiamo visto nell’articolo su Core Web Vitals e SEO. Sempre nel 2021 il calcolo del CLS è stato modificato: invece di sommare tutti gli spostamenti della vita della pagina, considera la finestra di sessione peggiore, un cambiamento che ha reso la metrica più equa per le pagine lunghe e per le sessioni prolungate. Nel 2023 Google ha annunciato l’INP come successore del FID, e a marzo 2024 la sostituzione è diventata effettiva.
La lezione del FID
Il passaggio dal FID all’INP è il caso più istruttivo per capire come evolvono le metriche. Il FID misurava solo il ritardo prima che il browser iniziasse a gestire la prima interazione dell’utente, non il tempo complessivo per mostrare la risposta, e ignorava tutte le interazioni successive. Era facile da superare: la grande maggioranza dei siti otteneva valori buoni, anche quando gli utenti percepivano chiaramente interfacce lente. La metrica, in altre parole, non descriveva bene l’esperienza che voleva rappresentare.
L’INP considera tutte le interazioni della visita e misura il tempo fino al disegno della risposta. È una metrica molto più esigente, e al momento della sostituzione molti siti che risultavano nello stato buono con il FID sono passati allo stato da migliorare senza alcuna modifica. La lezione è chiara: chi aveva ottimizzato per il numero, sfruttando i limiti del FID, si è trovato scoperto; chi aveva lavorato sulla reattività reale, riducendo il JavaScript e i lunghi task, ha attraversato il cambiamento senza problemi.
Il ciclo di vita di una metrica
Per rendere prevedibili i cambiamenti, Google ha descritto un ciclo di vita per le metriche del programma Web Vitals. Una metrica nasce come sperimentale: viene proposta, implementata nel browser, discussa con la comunità e corretta in base ai dati raccolti. Se dimostra di essere utile e affidabile, diventa in attesa: viene annunciata come futura Core Web Vital, con un periodo di preavviso che permette ai siti di prepararsi. Infine diventa stabile ed entra nelle valutazioni. Una metrica stabile può essere ritirata quando ne arriva una migliore, come è successo al FID.
Google ha anche indicato che le metriche stabili non cambiano più di una volta l’anno, e sempre con un annuncio anticipato. Accanto alle Core Web Vitals esistono poi le metriche diagnostiche, come il TTFB, il First Contentful Paint e il Total Blocking Time: non fanno parte della valutazione, ma aiutano a capire le cause dei problemi. Non tutte le novità, quindi, sono destinate a diventare Core Web Vitals: molte restano strumenti diagnostici, utili per chi lavora sulle prestazioni ma senza conseguenze sulla valutazione.
Anche i dettagli cambiano
Oltre ai cambiamenti annunciati, le implementazioni delle metriche nel browser vengono aggiornate periodicamente per correggere casi particolari: quali elementi possono essere candidati all’LCP, come trattare le immagini di sfondo a basso contenuto informativo o gli elementi inizialmente trasparenti, come considerare gli spostamenti causati da certe animazioni. Questi aggiornamenti sono documentati in un registro pubblico delle modifiche alle metriche, e di solito hanno effetti piccoli. Possono però spiegare variazioni improvvise nei dati di campo non legate a modifiche del sito, ed è utile sapere dove verificarle.
Le direzioni già visibili
Le navigazioni soft
L’area di lavoro più avanzata riguarda le applicazioni a pagina singola. Oggi, come abbiamo visto nell’articolo sulle Single Page Application, le navigazioni interne di queste applicazioni non producono nuove misure di caricamento, e CLS e INP si accumulano su tutta la sessione. Chrome sta sperimentando da tempo un meccanismo per riconoscere queste navigazioni e misurarle come pagine separate. Se diventasse stabile, cambierebbe in modo significativo i valori di molti siti costruiti con i framework JavaScript: alcune pagine migliorerebbero, perché i problemi della sessione non sarebbero più attribuiti alla pagina d’ingresso, altre peggiorerebbero, perché navigazioni lente oggi invisibili verrebbero finalmente misurate.
L’attribuzione delle cause
Una seconda direzione non riguarda nuove metriche ma la capacità di capire quelle esistenti. La Long Animation Frames API, disponibile in Chrome, indica quali script contribuiscono ai fotogrammi lenti e quindi alle interazioni lente; le versioni con attribuzione delle librerie di misura scompongono LCP e INP nelle loro fasi. È una tendenza che rende le metriche più utilizzabili, spostando l’attenzione dal «quanto» al «perché», e che probabilmente continuerà.
La fluidità
Un aspetto dell’esperienza che le Core Web Vitals attuali non coprono direttamente è la fluidità: animazioni e scorrimenti che procedono a scatti, fotogrammi persi durante una transizione. Il tema è stato esplorato più volte con metriche sperimentali, senza arrivare finora a una proposta stabile. È plausibile che in futuro emerga qualcosa in questa direzione, anche perché le API come quella dei fotogrammi lunghi forniscono già parte dei dati necessari.
Oltre Chrome
Le API su cui si basano le metriche sono nate in Chromium, e per anni solo i browser basati su questo motore le hanno supportate. Negli ultimi anni altri motori hanno iniziato a implementarne alcune, e il lavoro di standardizzazione nei gruppi del W3C prosegue. Un supporto più ampio permetterebbe di misurare le prestazioni degli utenti di tutti i browser con gli stessi strumenti, un vantaggio soprattutto per i siti con molti visitatori da dispositivi Apple, oggi in parte invisibili ai dati del Chrome UX Report.
Le soglie potrebbero cambiare?
Una domanda frequente riguarda le soglie: 2,5 secondi per l’LCP, 200 millisecondi per l’INP, 0,1 per il CLS. Sono state scelte in base a ricerche sulla percezione degli utenti e alla loro raggiungibilità da parte di una quota significativa dei siti, e dal 2020 non sono cambiate. Man mano che reti e dispositivi migliorano e che i siti si ottimizzano, la quota di pagine nello stato buono cresce, e non si può escludere che in futuro le soglie diventino più esigenti. Anche in quel caso, però, il cambiamento seguirebbe lo stesso ciclo di annuncio e preavviso delle metriche, e chi ha valori ben dentro le soglie attuali, e non appena sotto il limite, avrebbe poco da temere.
Cosa significa per un sito WordPress
Per chi gestisce un sito WordPress, l’evoluzione del core va nella stessa direzione delle metriche: caricamento selettivo degli stili dei blocchi, priorità automatica per l’immagine principale, supporto al caricamento speculativo delle pagine, moduli JavaScript caricati solo quando servono. Seguire gli aggiornamenti di WordPress, preferire temi e plugin che adottano queste funzioni e ridurre le dipendenze da codice datato è, di fatto, un modo di prepararsi anche alle metriche future.
Come prepararsi
La lezione del FID suggerisce la strategia più robusta: ottimizzare per l’esperienza che le metriche cercano di descrivere, non per le metriche stesse. Un sito con un server veloce, pagine leggere, poco JavaScript eseguito al momento giusto, un layout stabile e interazioni che rispondono subito attraverserà qualsiasi cambiamento di metrica senza sorprese, perché ogni nuova metrica cercherà di descrivere meglio proprio queste qualità. Al contrario, le ottimizzazioni che puntano a sfruttare i limiti di una metrica, come abbiamo visto parlando del cloaking delle prestazioni, sono le prime a diventare inutili quando la metrica cambia.
Sul piano pratico, alcune abitudini aiutano a non essere colti di sorpresa.
- Misurare le metriche sperimentali. Un sistema di Real User Monitoring può raccogliere, oltre alle metriche stabili, quelle in sperimentazione: quando una di queste viene annunciata, si conoscono già i propri valori e si hanno mesi di vantaggio.
- Seguire le fonti ufficiali. Gli annunci sul programma Web Vitals, il registro delle modifiche alle metriche e le note di rilascio mensili del Chrome UX Report sono sufficienti per conoscere in anticipo ciò che cambierà.
- Guardare le metriche diagnostiche. TTFB, Total Blocking Time e le scomposizioni di LCP e INP indicano problemi che probabilmente diventeranno rilevanti anche per le metriche future.
- Mantenere i budget. Un budget di prestazioni su quantità di JavaScript, peso delle pagine e numero di script di terze parti protegge le qualità di fondo del sito, indipendentemente dalle metriche usate per valutarle.
Cosa probabilmente non cambierà
Più interessante di cosa cambierà, forse, è cosa resterà. Le tre domande a cui rispondono le Core Web Vitals, quanto velocemente compare il contenuto principale, quanto rapidamente la pagina risponde, quanto è stabile ciò che si vede, descrivono aspetti fondamentali dell’esperienza di chiunque usi un sito, e difficilmente perderanno importanza. Le metriche potranno diventare più precise, coprire più casi, estendersi a più browser; le qualità che misurano resteranno le stesse. Così come resterà il principio di fondo del programma: misurare l’esperienza degli utenti reali, non il comportamento del sito in un laboratorio.
Anche il legame con il business difficilmente cambierà. Un sito veloce, stabile e reattivo trattiene più visitatori, converte di più e costa meno da far funzionare, qualunque sia il modo in cui Google decida di valutarlo, come abbiamo visto nell’articolo sul ritorno economico delle prestazioni. Le metriche sono il termometro; la salute del sito è ciò che conta.
In sintesi
In pochi anni le Core Web Vitals sono cambiate poco ma in modo significativo: il CLS è passato alle finestre di sessione, l’INP ha sostituito il FID, le soglie di LCP e CLS sono rimaste stabili. I cambiamenti seguono un ciclo di vita pubblico, dalla sperimentazione alla stabilità, con preavvisi di mesi, e le metriche stabili non cambiano più di una volta l’anno. Le direzioni già visibili riguardano le navigazioni soft, l’attribuzione delle cause, la fluidità e il supporto negli altri browser.
Il modo migliore di prepararsi è lo stesso che serve oggi: lavorare sull’esperienza reale e non sul numero, misurare gli utenti reali anche con le metriche sperimentali, seguire le fonti ufficiali e proteggere le qualità di fondo del sito con budget e controlli. Chi lo fa non deve temere il futuro delle Core Web Vitals: ogni nuova metrica, in fondo, cercherà solo di descrivere meglio ciò che quel sito sta già facendo bene.
