Core Web Vitals: cosa sposta davvero i numeri
I Core Web Vitals sono tre misurazioni sul campo di come si percepisce una pagina: quanto ci mette a comparire il contenuto principale, quanto si muove durante il caricamento, e quanto in fretta risponde all'input. Sono un segnale di posizionamento e, cosa più importante, sono correlati al fatto che le persone restino.
Questa guida copre cosa misura ciascuna metrica, le cause precise dietro i punteggi scarsi, e le correzioni che spostano i dati sul campo e non solo i punteggi di laboratorio.
Cosa misurano le tre metriche#
Ciascuna ha una soglia per «buono» e un piccolo numero di cause abituali. Nota che il numero che conta per il posizionamento sono i dati sul campo di visitatori veri, non un punteggio di laboratorio dal tuo portatile.
| Metrica | Buono | Misura | Causa abituale quando è scarsa |
|---|---|---|---|
| LCP | Sotto 2,5 s | Tempo fino al disegno dell'elemento visibile più grande | Immagine di testata non ottimizzata, server lento, CSS che blocca il rendering |
| CLS | Sotto 0,1 | Quanto si muove l'impaginazione durante il caricamento | Immagini senza dimensioni, banner inseriti, font web tardivi |
| INP | Sotto 200 ms | Reattività all'interazione dell'utente | Lunghe attività JavaScript che bloccano il thread principale |
Gli strumenti di laboratorio misurano un caricamento su una macchina. I dati sul campo sono il 75° percentile di visite reali, che comprende telefoni vecchi su reti scadenti — proprio i visitatori più propensi ad andarsene.
Correggere l'LCP#
L'LCP è quasi sempre un'immagine o un titolo bloccato dietro qualcos'altro. Procedi in ordine; i primi due punti risolvono la maggior parte dei siti.
- Individua il vero elemento LCP nei dati sul campo. Ottimizzare l'immagine sbagliata è lo sforzo sprecato più comune.
- Non caricare mai in differita l'immagine dell'LCP. Dalle invece fetchpriority="high".
- Servila in un formato moderno alla dimensione in cui viene mostrata, con srcset per gli schermi più piccoli.
- Precarica il font usato dal testo dell'LCP e usa font-display: swap perché il testo non sia invisibile durante l'attesa.
- Togli dall'head il CSS e il JavaScript che bloccano il rendering; incorpora il CSS critico se la pagina è abbastanza piccola.
- Riduci il Time to First Byte con cache e un CDN: nessun lavoro sul front-end compensa un server lento.
- Taglia gli script di terze parti nel percorso critico. Ciascuno è una risoluzione DNS, una connessione e un file imprevedibile.
Correggere il CLS#
Lo spostamento dell'impaginazione è quasi del tutto evitabile e le correzioni costano poco. È anche la metrica che i visitatori avvertono più fisicamente: è ciò che fa toccare la cosa sbagliata.
- Imposta gli attributi width e height su ogni immagine e video perché il browser riservi lo spazio.
- Riserva spazio per pubblicità, incorporamenti e iframe con un contenitore a rapporto d'aspetto fisso.
- Non inserire mai contenuto sopra quello esistente dopo il caricamento: i banner dei cookie vanno in basso, o sovrapposti.
- Allinea le metriche del font di ripiego a quelle del font web, o usa size-adjust, perché lo scambio non ricomponga la pagina.
- Evita di animare proprietà di impaginazione. Anima transform e opacity, che non provocano ricalcolo.
- Dai alle sezioni caricate dinamicamente una min-height perché non si espandano da zero.
Correggere l'INP#
L'INP ha sostituito il First Input Delay ed è più difficile, perché misura ogni interazione della visita anziché solo la prima. Un INP scarso è quasi sempre troppo JavaScript in esecuzione sul thread principale.
| Causa | Correzione |
|---|---|
| Grande bundle analizzato al caricamento | Suddividere il codice; caricare solo ciò che serve alla pagina |
| Attività lunghe oltre i 50 ms | Spezzare il lavoro in blocchi e restituire il thread principale |
| Gestori di evento costosi | Applicare il debounce e togliere il lavoro pesante dal percorso di interazione |
| Tag di terze parti pesanti | Caricare dopo l'interazione, o rimuovere: verifica cosa rende ciascuno |
| DOM grande (oltre 10.000 nodi) | Virtualizzare gli elenchi lunghi; semplificare il markup molto annidato |
| Sollecitazione dell'impaginazione nei gestori | Raggruppare letture e scritture anziché alternarle |
Sui siti editoriali la correzione INP di maggior valore consiste di solito nel cancellare JavaScript anziché ottimizzarlo. Chiediti cosa rende ogni script; i gestori di tag accumulano script che nessuno ricorda di aver aggiunto.
Domande frequenti
Quanto incidono i Core Web Vitals sul posizionamento?
Sono un segnale reale ma moderato, e agiscono da spareggio anziché da sostituto della pertinenza. Una pagina veloce sull'argomento sbagliato non supera una pagina più lenta che risponde alla domanda. L'argomento più forte per correggerli è comportamentale: pagine lente e che saltano perdono visitatori prima ancora che entri in gioco il posizionamento.
Perché il mio punteggio Lighthouse è buono e i dati sul campo scarsi?
Perché Lighthouse simula un caricamento sulla tua macchina con la tua connessione, e i dati sul campo sono il 75° percentile di visite reali, telefoni di tre anni su reti mobili congestionate compresi. Quando i due divergono, contano i dati sul campo. Usa gli strumenti di laboratorio per diagnosticare, non per dare voti.
Devo correggere tutte e tre le metriche?
Correggi quelle che stanno fallendo, nell'ordine di ciò che vivono i tuoi visitatori. Il CLS è di solito il meno costoso da correggere e il più fastidioso per gli utenti, quindi è un buon punto di partenza. L'LCP ha l'effetto maggiore sul fatto che le persone aspettino. L'INP conta di più sui siti interattivi e di meno sugli articoli statici.
Quanto ci vuole perché i miglioramenti si vedano?
I dati sul campo sono una finestra mobile di 28 giorni, quindi un movimento significativo richiede circa quattro settimane da quando una correzione raggiunge tutti i visitatori. Non giudicare un cambiamento dopo tre giorni. Controlla invece subito le metriche di laboratorio per confermare che la correzione abbia fatto ciò che ti aspettavi.
core web vitalslcpclsinpvelocità di paginaprestazioni web
