Velocità del sito: cosa misura Google davvero

• I Core Web Vitals sono tre: LCP (quanto tardi compare il contenuto principale), INP (quanto tardi il sito risponde a un clic) e CLS (quanto la pagina salta mentre carica).
• Le soglie «buone» sono LCP entro 2,5 secondi, INP entro 200 millisecondi, CLS sotto 0,1.
• Contano i dati di campo, non il punteggio del test. Google guarda il 75° percentile dei visitatori reali degli ultimi 28 giorni: tre utenti su quattro devono stare sotto la soglia.
• Pesano sul posizionamento, ma poco. Sono un criterio a parità di contenuto. Un sito lento con la risposta giusta batte un sito velocissimo che non risponde alla domanda.

LCP — Largest Contentful Paint. Il momento in cui compare l'elemento più grande visibile senza scorrere: di solito l'immagine di apertura o il titolo. Non è «quando finisce di caricare»: è quando il visitatore vede qualcosa di sostanziale. Buono entro 2,5 secondi, da sistemare oltre i 4.

INP — Interaction to Next Paint. Quanto tempo passa tra un clic e il momento in cui lo schermo mostra il risultato, misurato su tutte le interazioni della visita e non solo sulla prima. Ha sostituito il vecchio FID nel marzo 2024, ed è una metrica molto più severa: il FID misurava solo il ritardo iniziale, l'INP misura la risposta completa. Buono entro 200 millisecondi, da sistemare oltre i 500.

CLS — Cumulative Layout Shift. Quanto la pagina si muove sotto le dita mentre carica. È la metrica che misura la sensazione più fastidiosa del web mobile: il pulsante che si sposta nell'istante in cui lo premete. Buono sotto 0,1, da sistemare sopra 0,25.

Quando aprite PageSpeed Insights vedete due blocchi. Sopra, se il sito ha traffico sufficiente, ci sono i dati di campo: misurazioni raccolte dai browser Chrome di visitatori veri, sui loro telefoni e sulle loro connessioni, negli ultimi 28 giorni. Sotto c'è il test di laboratorio: una simulazione su un dispositivo di fascia media con connessione rallentata, eseguita adesso.

Il punteggio da 0 a 100 con il cerchio colorato appartiene al laboratorio. È utile per capire dove intervenire, perché è ripetibile e dà una diagnosi. Non è quello che Google usa: il segnale di ranking viene dai dati di campo.

Questo spiega due situazioni che sembrano paradossali e non lo sono. Un sito con 62 di punteggio può avere tutti e tre i Core Web Vitals verdi, perché i suoi visitatori reali sono in fibra su telefoni recenti. E un sito con 98 può averli rossi, se metà del traffico arriva da rete mobile in zone mal coperte. Il secondo caso è il più comune fuori dalle città.

Se il vostro sito ha poco traffico i dati di campo non compaiono affatto. In quel caso il laboratorio è tutto quello che avete, e va letto per quello che è: un'indicazione, non un verdetto.

I Core Web Vitals sono un fattore di ranking dichiarato, dentro il gruppo dei segnali sull'esperienza di pagina. Sono anche un fattore debole, e Google lo ha detto in modo esplicito: servono a distinguere fra pagine di valore paragonabile, non a far salire una pagina che non risponde alla domanda.

Tradotto: se siete in nona posizione, il problema quasi mai è LCP. È il contenuto, o i link, o il fatto che la pagina non corrisponde all'intenzione di chi cerca. Sistemare la velocità non vi porta in prima pagina da soli.

Dove la velocità conta davvero, e molto più del ranking, è sulla conversione. Un checkout che risponde in 150 millisecondi e uno che risponde in 600 vendono in modo diverso, a parità di posizione. Questo è il motivo per cui vale la pena lavorarci: non per Google.

• Immagini grandi e nel formato sbagliato. È il motivo numero uno di un LCP alto. Una fotografia da 3 MB in PNG mostrata larga 600 pixel è un errore che si ripete su tre siti su quattro. WebP o AVIF, dimensioni reali, e un solo file davvero grande: quello dell'apertura.
• Troppo JavaScript, e tutto subito. Ogni script che il browser deve scaricare ed eseguire prima di disegnare la pagina è tempo aggiunto. È la causa principale di un INP alto, soprattutto su telefoni di fascia media, dove il costo non è la rete ma la CPU.
• Script di terze parti. Chat, banner cookie, pixel pubblicitari, mappe incorporate, caroselli di recensioni. Ognuno sembra innocuo, insieme spesso pesano più del sito. Il banner cookie merita un controllo a parte: è il primo a partire e blocca tutto il resto.
• Immagini e riquadri senza dimensioni dichiarate. Causa diretta di CLS: il browser non sa quanto spazio riservare, la pagina si assesta a immagine caricata e tutto salta. Si risolve scrivendo width e height, o un rapporto d'aspetto, su ogni elemento che arriva dopo.
• Font caricati male. Un font web senza precaricamento e senza una strategia di sostituzione produce testo invisibile per qualche centinaio di millisecondi, oppure un salto quando il font definitivo arriva.
• Nessuna compressione e nessuna cache. Attivare gzip o brotli e mettere una cache lunga sugli elementi che non cambiano mai è mezz'ora di configurazione e cambia i numeri più di molte riscritture del codice.

Vale la pena raccontarlo perché è il caso più istruttivo che abbiamo sottomano. La homepage di questo sito è multilingua e, per farla leggere ai motori di ricerca senza eseguire JavaScript, i testi sono presenti nell'HTML in forma statica. Il dizionario con le cinque lingue viveva però dentro la stessa pagina: circa 135 KB di testo che ogni visitatore scaricava per intero, per poi usarne un quinto.

La correzione è stata banale una volta vista: dizionario fuori dalla pagina, un file per lingua, la pagina carica solo il proprio e le altre lingue arrivano in sottofondo quando il browser è libero. L'HTML della homepage è passato da circa 325 a 154 KB, e la parte più pesante è uscita dal percorso critico.

La lezione non è tecnica, è di metodo: il problema non si vedeva nel punteggio e non si vedeva nel design. Si vedeva solo guardando cosa il browser doveva leggere prima di poter disegnare qualcosa. È lì che si trovano quasi sempre i secondi veri.

• Guardate il rapporto Segnali web essenziali in Search Console, non il punteggio del test. Raggruppa gli indirizzi per tipo di problema e vi dice quali modelli di pagina sono messi male, che è l'informazione utile.
• Cominciate dall'immagine di apertura. Formato moderno, dimensione giusta, precaricata, mai in lazy load. Da sola sistema una buona parte degli LCP fuori soglia.
• Poi togliete, non aggiungete. Ogni script di terze parti va giustificato. Il criterio: se domani sparisse, qualcuno se ne accorgerebbe?
• Misurate di nuovo dopo 28 giorni. I dati di campo si muovono su una finestra mobile: un intervento fatto oggi si vede completamente solo un mese dopo. Chi vi mostra il miglioramento il giorno stesso vi sta mostrando il laboratorio.

E una cosa da non fare: inseguire il 100. Gli ultimi punti costano sproporzionatamente e non li vede nessun visitatore. Verde su tutti e tre i Core Web Vitals nei dati di campo è il traguardo; il resto è vanità.