Core Web Vitals, quali numeri contano davvero

Le Core Web Vitals sono tre: il tempo di comparsa del contenuto principale, la reattività alle interazioni e la stabilità visiva. Le soglie sono 2,5 secondi, 200 millisecondi e 0,1. Quello che quasi nessuno guarda è che contano i dati degli utenti veri, non quelli del test che hai appena lanciato.

Le tre metriche, e cosa misurano davvero

Largest Contentful Paint misura quanto ci mette a comparire l’elemento più grande della parte visibile della pagina, di solito l’immagine principale o il titolo. Secondo web.dev dovrebbe avvenire entro 2,5 secondi.

Interaction to Next Paint misura quanto tempo passa tra un’interazione e il momento in cui lo schermo risponde. La soglia è 200 millisecondi. Ha sostituito First Input Delay, promossa a metrica stabile nel 2024, e il cambio non è cosmetico: la vecchia misurava solo il primo clic, questa misura tutte le interazioni della sessione.

Cumulative Layout Shift misura quanto gli elementi si spostano mentre la pagina si carica. La soglia è 0,1. È quella che fa cliccare il pulsante sbagliato perché il contenuto è saltato mentre stavi premendo.

Il test che fai tu non è il dato che conta

Gli strumenti che danno un punteggio da zero a cento simulano una visita da un dispositivo di riferimento con una connessione di riferimento. Servono a capire cosa sistemare, non a sapere come sta il sito.

Il dato che Google usa arriva dalle visite reali, raccolte dai browser degli utenti veri, con i loro telefoni e le loro connessioni. Si legge nel rapporto sull’esperienza sulla pagina in Search Console, e riguarda gruppi di pagine simili invece che singoli indirizzi.

La differenza è grande. Un sito può avere un punteggio simulato di 95 e stare male sui dati reali, perché metà dei visitatori arriva da telefoni di quattro anni fa con una connessione mobile in centro città alle sei di sera.

Quanto pesa sul posizionamento, senza esagerare

Poco, e va detto. Le prestazioni sono un fattore di ordinamento tra pagine che rispondono allo stesso bisogno in modo equivalente. Non fanno salire una pagina mediocre sopra una buona.

Dove pesano davvero è sulle conversioni. Una pagina che si muove sotto le dita mentre qualcuno sta per comprare produce errori, frustrazione e abbandoni, e quel danno non compare in nessun rapporto di posizionamento.

Il modo giusto di inquadrarle è questo: non le sistemi per Google, le sistemi perché il 17 per cento di chi abbandona un carrello secondo Baymard lo fa per errori tecnici del sito. Le prestazioni sono una parte di quel 17.

Le cause, in ordine di frequenza

L’immagine grande in cima alla pagina, caricata a dimensione piena e non nel formato giusto. È la prima causa di LCP lento sui siti aziendali italiani e si risolve in un pomeriggio.

I caratteri tipografici caricati da un servizio esterno senza istruzioni su cosa mostrare nell’attesa. Producono testo invisibile per qualche centinaio di millisecondi, oppure uno spostamento quando il carattere definitivo sostituisce quello di sistema.

Gli script di terze parti, cioè consenso ai cookie, chat, statistiche, mappe, pixel pubblicitari. Ognuno sembra piccolo e insieme pesano più del sito. Sono anche la prima causa di INP alto, perché occupano il processore proprio mentre l’utente tocca lo schermo.

E i banner che compaiono dopo, senza che nessuno abbia riservato lo spazio dove andranno. Tipico dell’avviso sui cookie e delle immagini senza dimensioni dichiarate.

Su WordPress, in ordine di resa

Prima le immagini: formati moderni, dimensioni corrette, caricamento differito per tutto tranne quella principale. Su un sito con molte foto questo da solo sposta il LCP sotto la soglia nella maggior parte dei casi.

Poi il consenso ai cookie, che quasi sempre è lo script più pesante della pagina e blocca tutto il resto. Spostarlo, alleggerirlo o sostituirlo cambia i numeri più di qualsiasi plugin di ottimizzazione.

Poi i plugin. Non quanti sono, quali caricano codice su tutte le pagine anche dove non servono. Un plugin per i moduli che carica il suo JavaScript anche sulle pagine senza moduli è lavoro sprecato su ogni visita.

La cache viene dopo, non prima. È il primo intervento che tutti fanno e nasconde i problemi invece di risolverli, perché migliora il tempo di risposta del server senza toccare quello che rallenta davvero il browser.

Perché INP è più severa di quello che ha sostituito

First Input Delay misurava solo il ritardo della prima interazione, e misurava l’attesa prima che il browser cominciasse a rispondere, non il tempo fino a quando qualcosa compariva sullo schermo.

Interaction to Next Paint misura tutte le interazioni della sessione e conta fino al momento in cui lo schermo si aggiorna. È molto più vicina a quello che percepisce chi usa il sito, ed è anche il motivo per cui tanti siti che erano a posto con la vecchia metrica si sono trovati fuori soglia con la nuova.

La conseguenza pratica è che i menu a tendina, i filtri e i caroselli, cioè le parti che si usano dopo il caricamento, contano adesso quanto la velocità iniziale.

Cosa non fare

Non inseguire il punteggio cento. Gli ultimi punti costano sproporzionatamente e non corrispondono a niente che un utente percepisca.

Non installare tre plugin di ottimizzazione insieme. Fanno la stessa cosa, si pestano i piedi, e quando il sito si rompe non si capisce quale disattivare.

E non misurare subito dopo aver cambiato qualcosa. I dati reali di Search Console si muovono su una finestra di ventotto giorni, quindi un intervento fatto oggi si vede fra un mese. Chi misura il giorno dopo con lo strumento simulato sta guardando un numero diverso.

Il sospetto da verificare per primo

Quando i numeri peggiorano senza che nessuno abbia toccato il sito, la causa è quasi sempre qualcosa che è stato aggiunto da fuori: un nuovo pixel di tracciamento, una chat, un banner promozionale, uno strumento di test.

Sono cose che vengono installate da chi si occupa di marketing, spesso senza passare da chi gestisce il sito, e ognuna aggiunge codice che gira sul telefono di ogni visitatore.

Prima di aprire il codice del tema, la domanda giusta da fare in azienda è cosa è stato aggiunto nell’ultimo mese. Nella metà dei casi la risposta chiude il problema.

Come si imposta il controllo

Una volta al mese, dieci minuti. Si apre il rapporto sull’esperienza sulla pagina, si guarda la quota di indirizzi considerati buoni su mobile, e si annota. Mobile e non desktop, perché è lì che sta il traffico e lì che i problemi si vedono.

Se la quota scende senza che nessuno abbia toccato il sito, quasi sempre è stato aggiunto uno script da qualcun altro: un nuovo pixel, una chat, un banner promozionale. È la domanda da fare prima di aprire il codice.

Quando il sito è vecchio e il problema è strutturale invece che di configurazione, nessun plugin lo risolve e la discussione diventa un’altra, che abbiamo messo per iscritto nell’articolo su quando conviene rifare il sito. Per il resto, le prestazioni sono parte del lavoro ordinario nello sviluppo e nella manutenzione dei siti.

Due letture che completano il quadro. Cosa rallenta concretamente un sito WordPress, voce per voce, è in cosa rallenta davvero un sito WordPress. E se il problema che volete risolvere non è la velocità in sé ma le richieste che non arrivano, le cause si controllano nell’ordine indicato in cosa blocca le richieste dal sito.

Aggiornato al 29 luglio 2026.

Fonti

• web.dev, Web Vitals, soglie e ciclo di vita delle metriche
• Baymard Institute, Cart abandonment rate statistics (aggiornamento 2025)
• Search Console Help, Rapporto Indicizzazione delle pagine

---