Per molti responsabili di siti web, il rapporto Core Web Vitals di Google Search Console è il primo, e spesso l’unico, contatto con le metriche di prestazione. È lì che compaiono le URL «scadenti» o «da migliorare», le e-mail di avviso di Google, i grafici che salgono o scendono. Ed è anche uno dei rapporti più fraintesi: numeri che non tornano con PageSpeed Insights, pagine segnalate che sembrano velocissime, correzioni che non producono alcun effetto per settimane.
Quasi tutte queste incomprensioni hanno una spiegazione nel modo in cui il rapporto è costruito. In questo articolo vediamo da dove vengono i dati, come funzionano i gruppi di URL, come leggere stati e conteggi, perché le correzioni si vedono in ritardo e come usare il rapporto per decidere davvero dove intervenire.
Da dove vengono i dati
Il rapporto, nella sezione Esperienza di Search Console, si basa esclusivamente sui dati di campo del Chrome UX Report: le misure raccolte dai browser Chrome degli utenti reali che visitano il sito. Non contiene test di laboratorio, non usa Lighthouse, non dipende da quante volte si analizza una pagina con PageSpeed Insights. Ogni valore rappresenta il 75° percentile delle esperienze degli utenti nell’arco degli ultimi 28 giorni, come spiegato nell’articolo sulla finestra di 28 giorni.
Il rapporto è diviso in due sezioni, dispositivi mobili e computer, che vanno lette separatamente: le esperienze sono molto diverse, e un sito può essere nello stato buono da desktop e scadente da mobile. Le soglie sono quelle ufficiali delle tre metriche: LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS entro 0,1 per lo stato buono; oltre 4 secondi, 500 millisecondi e 0,25 per lo stato scadente.
I gruppi di URL
Il concetto più importante, e il meno intuitivo, è quello di gruppo. Search Console non valuta ogni URL con i propri dati: raggruppa le URL che ritiene simili, per struttura e contenuto, e valuta il gruppo nel suo insieme. Ogni URL del gruppo eredita lo stato del gruppo. È per questo che una pagina specifica, magari velocissima quando la si prova, può risultare «scadente»: fa parte di un gruppo che, nel complesso, non raggiunge le soglie.
Il raggruppamento ha una logica: la maggior parte delle pagine di un sito non ha abbastanza traffico per avere dati propri, mentre le pagine costruite con lo stesso modello tendono ad avere prestazioni simili. In pratica, i gruppi corrispondono spesso ai modelli di pagina: schede prodotto, articoli, categorie, pagine istituzionali. Aprendo un problema segnalato, il rapporto mostra alcune URL di esempio con il valore del gruppo; è da lì che conviene partire per capire quale modello di pagina è coinvolto.
Lo stato complessivo di un gruppo, e quindi delle sue URL, è determinato dalla metrica peggiore. Un gruppo con LCP e CLS buoni ma INP da migliorare è «da migliorare». Per questo, nel rapporto, la stessa URL può comparire in più problemi, uno per ciascuna metrica fuori soglia, ma verrà conteggiata una sola volta nel totale con lo stato peggiore.
Leggere i conteggi
Il grafico principale mostra, giorno per giorno, il numero di URL in ciascuno stato. Due precisazioni evitano molte interpretazioni sbagliate. La prima: le URL conteggiate non sono tutte le pagine del sito, ma solo quelle per cui esistono dati, direttamente o tramite il gruppo. Un sito di diecimila pagine può mostrarne poche centinaia, e il numero può cambiare senza che sia cambiato nulla nel sito, semplicemente perché cambia il traffico e quindi la disponibilità di dati.
La seconda: il numero di URL non indica l’importanza del problema. Un gruppo di quattromila schede prodotto poco visitate pesa sul grafico molto più di una home page con migliaia di visite al giorno, ma la seconda può essere molto più importante per il business. Il conteggio va sempre letto insieme al traffico delle pagine coinvolte, che si trova nel rapporto sul rendimento della stessa Search Console o negli analytics.
Salti improvvisi nel grafico, in un senso o nell’altro, hanno spesso cause esterne al sito. Google può ricalcolare i gruppi, e URL prima considerate simili possono essere separate o unite. Il passaggio da FID a INP, nel marzo 2024, ha spostato molti siti dallo stato buono a quello da migliorare senza alcuna modifica, perché la nuova metrica è più esigente. E un cambiamento del traffico, come l’arrivo di visitatori da una campagna con dispositivi o connessioni diversi, può modificare il 75° percentile senza che le pagine siano cambiate.
Perché non coincide con PageSpeed Insights
Una delle domande più frequenti riguarda le differenze con PageSpeed Insights. La sezione superiore di PageSpeed Insights mostra anch’essa dati di campo del Chrome UX Report, ma per la singola URL quando ha abbastanza traffico, altrimenti per l’intera origine. Search Console mostra invece il valore del gruppo. Tre livelli diversi, URL, gruppo e origine, possono dare tre valori diversi, tutti corretti. La sezione inferiore di PageSpeed Insights, il test di Lighthouse, è invece un test di laboratorio e non ha alcun ruolo nel rapporto, come spiegato nell’articolo sulle differenze tra PageSpeed Insights e Lighthouse.
La convalida delle correzioni
Dopo aver corretto un problema, Search Console permette di avviare la convalida. Il pulsante non accelera l’aggiornamento dei dati: avvia un monitoraggio di 28 giorni durante il quale Google verifica se le URL del gruppo rientrano nelle soglie. Se al termine il gruppo è nello stato buono, la convalida è superata; altrimenti fallisce, e va ripetuta.
Il ritardo è intrinseco al modo in cui vengono calcolati i dati. Il giorno dopo una correzione, 27 dei 28 giorni della finestra contengono ancora le esperienze precedenti. Il valore del rapporto migliora gradualmente, e supera la soglia solo quando i dati nuovi sono abbastanza da spostare il 75° percentile. A questo si aggiunge qualche giorno di ritardo nell’elaborazione. In pratica, tra una correzione efficace e il suo riflesso completo nel rapporto passano spesso da tre a sei settimane.
Per non restare al buio in questo periodo, conviene seguire gli effetti con strumenti più tempestivi: il Real User Monitoring, che mostra i dati giorno per giorno, o le serie settimanali della CrUX History API, che permettono di vedere l’andamento con maggiore granularità. Quando il rapporto finalmente si aggiorna, dovrebbe solo confermare ciò che questi dati indicavano già.
Le pagine senza dati
Un sito nuovo o con poco traffico può mostrare un rapporto vuoto, o con dati solo per una delle due sezioni. Non significa che le prestazioni siano buone o cattive, ma solo che non ci sono abbastanza visite da Chrome per calcolare statistiche affidabili. In questi casi le Core Web Vitals non vengono usate come segnale per quelle pagine, e il modo più utile per valutarle sono i test di laboratorio e, se il traffico lo permette, un sistema di misura proprio.
Come usare il rapporto per decidere
Letto nel modo giusto, il rapporto è uno strumento di priorità più che di diagnosi. Un metodo pratico segue pochi passi.
- Partire dal mobile. È dove si concentrano la maggior parte dei problemi e, per molti siti, la maggior parte del traffico.
- Identificare i gruppi. Per ogni problema, aprire le URL di esempio e capire a quale modello di pagina corrispondono.
- Pesare con il traffico. Dare priorità ai gruppi che ricevono più visite organiche o che contano di più per le conversioni.
- Diagnosticare altrove. Usare PageSpeed Insights e i DevTools su alcune URL rappresentative del gruppo per capire la causa, e il RUM se disponibile per l’attribuzione.
- Annotare e convalidare. Registrare la data di ogni intervento, avviare la convalida e seguire l’andamento con strumenti più rapidi nelle settimane successive.
Annotare le date è un dettaglio che fa risparmiare molto tempo. Search Console non registra i rilasci del sito, e a distanza di settimane è difficile ricordare cosa sia cambiato e quando. Un semplice registro con data, pagine coinvolte e tipo di intervento permette di collegare ogni variazione del grafico alla sua causa, e di distinguere gli effetti delle proprie modifiche da quelli di fattori esterni.
Un esempio di lettura
Immaginiamo un negozio online che riceve un avviso: da mobile, oltre quattromila URL sono passate allo stato scadente per l’LCP. A prima vista sembra un disastro. Aprendo il problema, le URL di esempio sono tutte schede prodotto, e il valore del gruppo è 3,4 secondi. Il rapporto sul rendimento mostra però che queste pagine, prese singolarmente, ricevono poco traffico organico, mentre le categorie, che portano la maggior parte delle visite da Google, sono nello stato buono.
Il problema è reale, perché le schede prodotto sono le pagine in cui si decide l’acquisto, ma la sua urgenza va ridimensionata rispetto all’allarme iniziale. Un test su alcune schede rappresentative mostra che l’immagine principale viene caricata in modo differito da un plugin di ottimizzazione aggiornato di recente: la data del peggioramento coincide con quella dell’aggiornamento. Corretta l’impostazione, il RUM mostra un LCP da mobile di 2,1 secondi già dal giorno successivo; il rapporto di Search Console riporterà il gruppo nello stato buono dopo circa quattro settimane, e la convalida si chiuderà di conseguenza.
Esportare e integrare i dati
Il rapporto permette di esportare i dati dei grafici e gli elenchi di URL di esempio, utili per archiviare la situazione prima e dopo un intervento. Per analisi più approfondite, gli stessi dati di origine sono disponibili attraverso la CrUX API, che restituisce i valori per URL o per origine, e la CrUX History API, che fornisce serie settimanali per diversi mesi. Con strumenti di visualizzazione come Looker Studio si possono costruire cruscotti che mettono insieme dati di CrUX, traffico organico e conversioni: una vista unica che rende molto più semplice spiegare a chi decide perché un intervento sulle prestazioni vale il suo costo.
Le e-mail di avviso
Search Console invia un’e-mail quando rileva un nuovo problema o un aumento di URL in uno stato peggiore. Sono avvisi utili, ma vanno accolti senza allarmismi. Il rapporto non è un sistema di penalizzazioni: segnala una situazione che, come spiegato nell’articolo su Core Web Vitals e SEO, ha un peso nel posizionamento soprattutto a parità di pertinenza. Prima di intervenire conviene verificare se il peggioramento riguarda pagine importanti, se coincide con un rilascio o con un cambiamento del traffico, e se è confermato da altri dati.
In sintesi
Il rapporto Core Web Vitals di Search Console mostra i dati di campo del Chrome UX Report, al 75° percentile su 28 giorni, separati per mobile e desktop e organizzati in gruppi di URL simili. Ogni URL eredita lo stato del gruppo, e lo stato è quello della metrica peggiore. I conteggi riguardano solo le pagine con dati e non indicano l’importanza dei problemi, che va valutata con il traffico.
Le correzioni si vedono con settimane di ritardo, perché la finestra di 28 giorni deve rinnovarsi; la convalida avvia un monitoraggio, non un aggiornamento immediato. Usato come strumento di priorità, affiancato da test di laboratorio per la diagnosi e da dati più tempestivi per verificare gli interventi, è il modo più diretto per sapere come Google vede l’esperienza offerta dal proprio sito.
