La velocità di un sito: i Core Web Vitals spiegati

01Tre secondi in un parcheggio: perché la velocità conta

Una persona è in macchina, nel parcheggio davanti al tuo negozio, e vuole sapere se sei aperto. Apre il tuo sito dal telefono, con due tacche di segnale. Lo schermo resta bianco. Poi compare un'immagine enorme, poi il testo, poi un riquadro dei cookie che spinge giù tutto proprio mentre tocca «Orari»: ha premuto «Offerte». Torna indietro, apre la scheda di un concorrente. Tre secondi, e hai perso un cliente che era già davanti alla porta.

È esattamente questa esperienza che Google ha deciso di misurare con tre numeri, i Core Web Vitals, i «segnali vitali» di una pagina web. Non misurano quanto è bello il sito né quanto è ricco: misurano tre momenti precisi dell'esperienza di chi lo visita.

• Vedo qualcosa di utile? Lo misura l'LCP.
• Se tocco, risponde? Lo misura l'INP.
• Sta ferma, o mi scappa da sotto il dito? Lo misura il CLS.

Google raccomanda apertamente di avere buoni Core Web Vitals e li considera parte dell'esperienza della pagina che i suoi sistemi premiano. Ma è onesto anche sull'altro lato: il motore cerca sempre di mostrare il contenuto più pertinente, anche quando l'esperienza non è perfetta. Tradotto: la velocità non sostituisce un buon contenuto, ma a parità di contenuto fa la differenza, e soprattutto fa la differenza con le persone, che sono quelle che comprano.

Nel capitolo sull'infrastruttura web ho spiegato il TTFB, il tempo che il server impiega a cominciare a rispondere. Qui guardiamo tutto quello che succede dopo, dentro al browser: è lì che si decide la maggior parte dei tre numeri.

02Le tre misure e le loro soglie

Ogni misura ha tre fasce: buona, da migliorare e scarsa. Le soglie le pubblica Google nella sua guida per gli sviluppatori, e sono le stesse per ogni sito, dal negozio di quartiere al grande portale.

Perché il 75%, e non la media

La media nasconde i problemi: dieci visite velocissime dal computer dell'ufficio coprono tre visite disastrose da un telefono economico in campagna. Il 75° percentile è più severo e più giusto: dice che tre visitatori su quattro hanno avuto un'esperienza almeno così buona. Per passare non basta che il sito vada bene per te; deve andare bene per quasi tutti, anche per chi ha un telefono di qualche anno fa e una connessione ballerina.

03LCP: quando compare il contenuto che conta

L'LCP (Largest Contentful Paint, la più grande porzione di contenuto disegnata) misura quando appare sullo schermo l'elemento più grande visibile all'apertura: di solito l'immagine principale, oppure il blocco di testo più grande, come il titolo con il paragrafo d'apertura. È il momento in cui chi visita pensa «ecco, è arrivato».

Per l'LCP contano le immagini, le immagini di sfondo caricate dal CSS, le copertine dei video e i blocchi di testo. Un disegno vettoriale scritto direttamente nella pagina, invece, non è candidato. Il tempo si conta da quando la pagina comincia a caricare, quindi dentro all'LCP c'è tutto: l'attesa del server, il download dei file, il disegno.

Le cause più frequenti e i rimedi

• Immagini troppo pesanti. Una foto scattata col telefono pesa facilmente qualche megabyte; sullo schermo di un telefono ne bastano poche centinaia di kilobyte. Si ridimensiona alla misura vera di visualizzazione, si comprime, si usano formati moderni come WebP o AVIF, e si offrono misure diverse per schermi diversi.
• L'immagine principale «pigra». Il caricamento differito (loading="lazy") è ottimo per le immagini in fondo alla pagina, ma sull'immagine in cima ritarda proprio l'LCP. Quella va caricata subito, anzi annunciata con priorità alta.
• CSS e caratteri che bloccano. Finché il browser non ha scaricato i fogli di stile non disegna niente. Pochi file, piccoli, e caratteri caricati in modo da mostrare subito il testo con un carattere di riserva.
• Un server lento. Se il TTFB già si mangia un secondo, il resto ha poco margine: è la parte che racconto nel capitolo sull'infrastruttura.
• Contenuto costruito dal JavaScript. Se il testo principale compare solo dopo che uno script lo ha scaricato e montato, l'LCP aspetta lo script. Il contenuto importante deve arrivare già scritto nella pagina.

04INP: la pagina risponde quando la tocchi?

Ti è mai capitato di toccare «Aggiungi al carrello» e di non vedere succedere niente, toccarlo di nuovo, e ritrovarti con due prodotti? Quella mezza sensazione di «si è bloccato?» ha un nome: INP (Interaction to Next Paint, dall'interazione al disegno successivo).

L'INP osserva tutti i clic, i tocchi e i tasti premuti durante la visita, e misura quanto tempo passa da ciascuno al momento in cui lo schermo mostra la reazione. Il valore finale rappresenta, in sostanza, una delle interazioni più lente della visita. Sotto i 200 millisecondi la pagina sembra immediata; oltre i 500 sembra rotta.

Il nemico si chiama «compito lungo»

Il browser ha un solo filo principale per eseguire il JavaScript e disegnare la pagina. Se uno script lo occupa per molto tempo di fila (si parla di compiti lunghi quando superano i 50 millisecondi), il tocco dell'utente aspetta in coda. I colpevoli abituali:

• troppi script di terze parti: chat, contatori, widget social, pubblicità, ognuno con il suo peso;
• page builder e decine di plugin che caricano il loro codice su ogni pagina, anche dove non serve. È il tema del capitolo sul valore del professionista del codice;
• codice che fa tutto subito: calcoli, animazioni e caricamenti avviati all'apertura, invece che quando servono;
• pagine enormi, con migliaia di elementi da ricalcolare a ogni cambiamento.

I rimedi seguono: meno script, caricati solo dove servono e dopo il contenuto; compiti spezzati in pezzi piccoli che lasciano respirare il browser; una risposta visiva immediata al tocco (anche solo il pulsante che si accende) prima dei calcoli pesanti.

05CLS: la pagina che scappa da sotto il dito

Il CLS (Cumulative Layout Shift, lo spostamento cumulativo dell'impaginazione) misura quanto il contenuto visibile si sposta senza che tu abbia fatto niente. È il difetto più irritante dei tre, perché fa sbagliare: leggi una riga e ti scappa, vuoi toccare un pulsante e tocchi quello che è appena arrivato al suo posto.

Come si calcola, in parole semplici

Ogni spostamento riceve un punteggio dato da due fattori moltiplicati fra loro: quanta parte dello schermo è coinvolta e di quanto si sono mossi gli elementi rispetto alla misura dello schermo. La guida di Google fa questo esempio: se gli elementi instabili occupano il 75% dello schermo e si spostano di un quarto, il punteggio è 0,75 × 0,25 = 0,1875. Già da solo, oltre la soglia buona di 0,1.

Gli spostamenti vicini nel tempo si sommano in «raffiche» (con meno di un secondo fra uno e l'altro, per un massimo di cinque secondi), e il CLS della pagina è la raffica peggiore. Due dettagli importanti:

• gli spostamenti che avvengono entro mezzo secondo da un tuo tocco o tasto non contano: se apri un menu e il contenuto si sposta, è una reazione che ti aspetti;
• le animazioni fatte con le trasformazioni (spostare o ingrandire un elemento senza cambiare l'impaginazione intorno) non producono spostamenti: sono il modo giusto di animare.

I rimedi, quasi tutti gratis

• Dare sempre larghezza e altezza alle immagini (o un rapporto d'aspetto nel CSS): il browser riserva lo spazio prima ancora di scaricarle.
• Riservare il posto a tutto ciò che arriva dopo: banner, mappe incorporate, video, recensioni caricate da altri servizi.
• Non inserire contenuto sopra quello che l'utente sta già guardando, a meno che non l'abbia chiesto lui.
• Caricare i caratteri con giudizio, scegliendo caratteri di riserva di misura simile, così il passaggio dall'uno all'altro non sposta le righe.

06Laboratorio e realtà: due modi di misurare

«Ho fatto il test e mi dà 98, perché Google dice che il sito è lento?» È una delle domande che sento più spesso, e la risposta è che si stanno guardando due cose diverse.

Come leggere PageSpeed Insights in tre mosse

1. Guarda prima la parte in alto, quella dei dati reali: dice se la pagina supera la valutazione dei Core Web Vitals. Se c'è scritto che non ci sono abbastanza dati, la pagina ha poche visite e si guarda il dato dell'intero sito.
2. Scegli la scheda del telefono: per un'attività locale è quasi sempre il dispositivo della maggioranza, e il più severo.
3. Usa il laboratorio per le cause: la sezione delle diagnosi elenca immagini da ridurre, script che bloccano, spostamenti, con i file responsabili.

07Il piano di lavoro: da dove si comincia

Migliorare i Core Web Vitals non è una gara di trucchi. È un lavoro ordinato, che parte da quello che pesa di più e misura ogni passo.

Per un'attività locale, la velocità sul telefono pesa ancora di più: chi cerca «vicino a me» lo fa quasi sempre in movimento, e sceglie in pochi secondi. È il tema del capitolo sulla SEO locale. E se il sito deve diventare anche un'app da tenere sul telefono, i Core Web Vitals sono la base su cui costruire una PWA che si apre come un'app vera.

Domande frequenti

Fonti

1. web.dev (Google), «Web Vitals»: le tre misure, le soglie e il 75° percentile.
2. web.dev, «Largest Contentful Paint», «Interaction to Next Paint» e «Cumulative Layout Shift»: definizioni, fasce e calcolo del punteggio.
3. web.dev, l'annuncio del 12 marzo 2024: l'INP sostituisce il FID.
4. Google Search Central, «Core Web Vitals e risultati di ricerca» e «Esperienza sulla pagina».
5. Chrome for Developers, metodologia del rapporto CrUX: chi viene conteggiato e quali pagine.
6. web.dev, guide per ottimizzare LCP, INP e CLS.

Capitolo aggiornato a ottobre 2026. Soglie e definizioni vengono dalla documentazione ufficiale di Google; i tempi nelle tavole sono esempi per mostrare le proporzioni, non misure di un sito in particolare.