In breve
I Core Web Vitals sono tre metriche di Google che misurano l’esperienza reale di chi visita il sito: LCP (velocità del contenuto principale, buono entro 2,5 secondi), INP (reattività ai clic, buono entro 200 millisecondi) e CLS (stabilità del layout, buono entro 0,1). Su WordPress si migliorano soprattutto con hosting e cache, immagini ottimizzate, meno JavaScript di terze parti e dimensioni dichiarate per immagini e banner.
Se Google Search Console ti segnala URL “scadenti” o “da migliorare”, stai guardando i Core Web Vitals. Su WordPress come altrove, queste sigle misurano cose molto concrete: quanto aspetta una persona prima di vedere la pagina, quanto la pagina risponde quando tocca un pulsante e quanto gli elementi si spostano mentre legge. Ognuno ha soglie ufficiali precise, e nei siti WordPress che gestiamo le cause dei problemi sono quasi sempre le stesse.
Cosa sono i Core Web Vitals?
I Core Web Vitals sono tre metriche definite da Google per misurare caricamento, reattività e stabilità visiva di una pagina, calcolate sulle visite reali degli utenti. Una pagina li supera quando almeno il 75% delle visite rientra nella fascia “buona” per tutte e tre.
Il riferimento ufficiale è web.dev, il sito di Google dedicato alle prestazioni. Conta il 75° percentile, separato per mobile e desktop: devi garantire una buona esperienza anche a chi ha un telefono di fascia media e una connessione non perfetta.
| Metrica | Cosa misura | Buono | Da migliorare | Scarso |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Quando compare l’elemento più grande visibile | ≤ 2,5 s | tra 2,5 e 4 s | > 4 s |
| INP (Interaction to Next Paint) | Quanto la pagina risponde a clic, tocchi e tasti | ≤ 200 ms | tra 200 e 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Quanto si sposta il contenuto durante la visita | ≤ 0,1 | tra 0,1 e 0,25 | > 0,25 |
Le soglie sono quelle pubblicate su web.dev nelle schede dedicate a LCP, INP e CLS. L’INP ha sostituito il vecchio FID (First Input Delay) dal 12 marzo 2024, come annunciato sul blog di web.dev.
Dove vedi i Core Web Vitals del tuo sito?
Li vedi in due posti: in PageSpeed Insights, pagina per pagina, e nel report “Core Web Vitals” di Google Search Console, che raggruppa gli URL del sito con problemi simili. Entrambi usano i dati reali del Chrome User Experience Report.
PageSpeed Insights mostra in alto i dati di campo (le visite reali degli ultimi 28 giorni) e più in basso i dati di laboratorio, cioè una simulazione ripetibile utile per trovare le cause. Se il sito ha poco traffico, i dati di campo possono mancare: in quel caso usa il laboratorio come indicazione, sapendo che non è la stessa cosa. La differenza tra i due tipi di dato è spiegata meglio nella guida su come velocizzare WordPress.
Come si migliora l’LCP su WordPress?
L’LCP migliora riducendo il tempo di risposta del server e facendo arrivare prima e più leggero l’elemento principale della pagina, che nella maggior parte dei siti WordPress è l’immagine di copertina o il titolo in alto. È la metrica su cui l’hosting e la cache incidono di più.
Secondo web.dev, l’elemento considerato per l’LCP può essere un’immagine, il poster di un video, un’immagine di sfondo caricata via CSS o un blocco di testo. Per capire quale sia nel tuo caso, PageSpeed Insights lo indica nella sezione diagnostica.
Le cause più frequenti
- Server lento: se il primo byte arriva dopo un secondo, restano pochissimi margini. Serve una cache di pagina e un hosting adeguato.
- Immagine principale pesante: un banner da 2 MB in JPEG. Va ridimensionato e convertito in WebP o AVIF.
- Immagine principale caricata in differita: il lazy load applicato anche alla prima immagine ne ritarda il download. La prima immagine visibile non deve avere
loading="lazy"e può riceverefetchpriority="high". - Immagine di sfondo impostata via CSS: il browser la scopre solo dopo aver letto il foglio di stile. Se possibile, usa un’immagine vera nell’HTML per l’elemento principale.
- CSS e font che bloccano il rendering: troppi fogli di stile nel
<head>o font esterni senzafont-display: swapritardano la comparsa del testo.
Come si migliora l’INP su WordPress?
L’INP migliora riducendo il JavaScript che occupa il browser, soprattutto quello di terze parti (chat, pixel, widget) e quello di plugin e page builder che eseguono molto codice a ogni interazione. Dipende molto più dalla quantità di script che dal peso delle immagini.
L’INP misura il tempo tra un’interazione (clic, tocco o tasto; lo scorrimento non conta) e il momento in cui lo schermo mostra la risposta. Se il browser è impegnato a eseguire altri script, la risposta arriva in ritardo e l’utente ha la sensazione di un sito “che non risponde”. Interventi tipici:
- Riduci gli script esterni: elimina pixel e tag non più usati, carica chat e mappe solo quando servono.
- Controlla i plugin che aggiungono JavaScript ovunque, come slider, popup, animazioni allo scorrimento, contatori.
- Semplifica le pagine molto lunghe. Un DOM enorme (migliaia di elementi annidati, tipico di alcuni page builder) rende più lenta ogni modifica dello schermo.
- Non esagerare con il rinvio degli script: rimandare tutto il JavaScript a dopo il caricamento migliora l’LCP in laboratorio, ma può concentrare l’esecuzione proprio quando l’utente inizia a interagire.
Come si migliora il CLS su WordPress?
Il CLS migliora riservando in anticipo lo spazio a tutto ciò che arriva dopo: immagini, video, banner, annunci e font. Gli spostamenti nascono quasi sempre da elementi che compaiono senza dimensioni note e spingono giù il contenuto.
web.dev indica come cause principali i media senza dimensioni, i font che cambiano ingombro quando sostituiscono quello di riserva e i contenuti di terze parti che si ridimensionano da soli. Su WordPress questo si traduce in:
- Immagini senza
widtheheight: WordPress le aggiunge per le immagini inserite dall’editor, ma temi e plugin personalizzati a volte no. - Banner cookie e barre promozionali che si inseriscono in alto spingendo giù la pagina. Meglio sovrapporli (in basso, in posizione fissa) o riservare lo spazio.
- Video e mappe incorporati senza un contenitore con proporzioni fisse.
- Font web molto diversi da quello di riserva: il testo cambia larghezza e sposta tutto. Pochi pesi, caricati localmente e con un font di riserva simile, riducono il problema.
- Contenuti caricati dopo (prodotti correlati, recensioni, annunci) inseriti sopra contenuti già visibili.
Come procedere, passo per passo?
Procedi partendo dal report di Search Console per capire quali gruppi di pagine hanno problemi, poi analizzi un URL rappresentativo con PageSpeed Insights e correggi una causa alla volta, verificando ogni volta in laboratorio. Prima di tutto, un backup.
- Apri Search Console, sezione “Core Web Vitals”, e annota quale metrica fallisce e su quali gruppi di URL (per esempio tutti gli articoli o tutte le schede prodotto).
- Scegli un URL rappresentativo del gruppo e analizzalo con PageSpeed Insights su mobile.
- Fai un backup completo del sito e, se possibile, lavora in staging.
- Applica una correzione alla volta partendo dalla metrica peggiore e verifica in laboratorio che migliori senza rompere nulla.
- Pubblica, svuota la cache e controlla la pagina da un telefono reale.
- In Search Console avvia la convalida della correzione e attendi: i dati di campo si aggiornano su una finestra di 28 giorni.
Se l’LCP è alto su tutto il sito, il primo sospettato è il server: vale la pena leggere anche hosting condiviso o gestito per WordPress. Se il sito è costruito con un page builder, molti problemi di INP e CLS nascono dalla struttura delle pagine: leggi come alleggerire un sito Elementor lento.
Quanto contano i Core Web Vitals per Google?
Contano come parte dei segnali sull’esperienza della pagina, ma non superano la pertinenza e la qualità dei contenuti: un sito veloce ma poco utile non si posiziona per questo. Misurano però problemi reali, che fanno perdere visitatori e clienti.
Un LCP scarso significa persone che aspettano, un INP scarso pulsanti che sembrano non funzionare, un CLS scarso clic sul punto sbagliato. Se vuoi che qualcuno se ne occupi con misure prima e dopo, c’è il servizio di ottimizzazione della velocità.
Search Console ti segnala URL scadenti?
Ti diciamo quale metrica pesa di più sul tuo sito e da dove conviene iniziare, analizzandolo dall’esterno.
Domande frequenti
Perché PageSpeed Insights non mostra i dati dei Core Web Vitals del mio sito?
I dati di campo arrivano dal Chrome User Experience Report e compaiono solo se la pagina o il sito hanno abbastanza visite di utenti Chrome. Per i siti con poco traffico puoi usare i dati di laboratorio come riferimento e misurare le visite reali con strumenti propri.
Ho corretto il problema ma il report di Search Console non cambia. È normale?
Sì. I dati di campo si basano sugli ultimi 28 giorni di visite, quindi un miglioramento richiede alcune settimane per riflettersi completamente. Dopo la correzione puoi avviare la convalida nel report e attendere.
Che fine ha fatto il FID?
Il First Input Delay misurava solo il ritardo della prima interazione. Dal 12 marzo 2024 è stato sostituito dall’INP, che considera la reattività di tutte le interazioni durante la visita ed è quindi più rappresentativo.
Basta avere un buon punteggio su mobile?
La valutazione è separata per mobile e desktop, quindi conviene controllarle entrambe. In pratica il mobile è quasi sempre il caso più difficile: se superi le soglie lì, il desktop di solito le supera a sua volta.