Con il core update di dicembre 2025, Google ha alzato la posta sulle metriche di performance: i Core Web Vitals non sono più un requisito accessorio ma un fattore discriminante nelle SERP competitive. LCP, INP e CLS vengono valutati su sessioni reali degli utenti, non sui test di laboratorio, e chi non raggiunge le soglie “buone” rischia di cedere posizioni a competitor con contenuto simile ma sito più rapido.
Le tre metriche e le soglie ufficiali
Le soglie “buone” definite da Google Search Central sono le seguenti:
- LCP (Largest Contentful Paint): caricamento dell’elemento principale visibile. Soglia buona: sotto 2,5 secondi. Da migliorare: 2,5-4 secondi. Scarso: oltre 4 secondi.
- INP (Interaction to Next Paint): reattività complessiva della pagina alle interazioni (clic, tocco, tastiera). Soglia buona: sotto 200 millisecondi. Da migliorare: 200-500ms. Scarso: oltre 500ms.
- CLS (Cumulative Layout Shift): stabilità visiva, misura quanto gli elementi si spostano durante la navigazione. Soglia buona: sotto 0,1. Da migliorare: 0,1-0,25. Scarso: oltre 0,25.
Un dettaglio tecnico che molti sottovalutano: Google valuta queste metriche al 75° percentile delle sessioni reali raccolte dal Chrome User Experience Report (CrUX). Non basta che il sito sia veloce per l’80% degli utenti: quel quarto di sessioni con esperienza peggiore continua a pesare sulla valutazione. Questo significa che la distribuzione delle performance, non solo il valore medio, è il punto critico su cui lavorare.
INP ha sostituito FID (First Input Delay) a marzo 2024, diventando la metrica più ostica da correggere tra le tre. FID misurava solo il ritardo alla prima interazione; INP misura la peggior interazione sull’intera sessione, escludendo solo i valori anomali. La conseguenza pratica: un singolo script lento caricato in modo sincrono può far saltare l’INP anche su un sito che per il resto si comporta bene.
Il core update di dicembre 2025 e i numeri sul traffico
L’aggiornamento di dicembre 2025 ha consolidato la tendenza già visibile nei core update precedenti: i segnali tecnici di performance contano di più quando i contenuti tra i siti in competizione sono comparabili. Secondo l’analisi condotta da ALM Corp sul core update di dicembre 2025, i siti con performance scadenti hanno registrato cali significativi:
- Siti con LCP superiore a 3,0 secondi: perdita di traffico del 23% in più rispetto a competitor con contenuto simile ma LCP nella soglia buona.
- Siti con INP superiore a 300ms su mobile: perdita del 31% di traffico in più, concentrata sulle query da smartphone.
- Siti con CLS superiore a 0,15: calo del 19% in più.
Va detto con chiarezza che Google stessa afferma come contenuto, pertinenza e segnali E-E-A-T continuino a pesare più delle metriche di performance. I Core Web Vitals operano principalmente come fattore di pareggio: a parità di qualità editoriale, il sito tecnicamente migliore guadagna posizioni. Raptive ha confermato che l’aggiornamento di dicembre 2025 ha mostrato una tendenza chiara sull’esperienza di pagina, non solo sulla qualità del contenuto.
In mercati locali competitivi, come le SERP su Perugia, Foligno, Spoleto o Gubbio, dove spesso i competitor pubblicano contenuti molto simili, questo fattore discriminante può valere 2-4 posizioni nelle query più contese.
Perché tanti siti italiani sono ancora fuori soglia
L’analisi dei siti WordPress di PMI italiane rivela pattern ricorrenti che degradano le metriche in modo sistematico.
Sul fronte LCP, i problemi più diffusi sono immagini hero non convertite in formato moderno (WebP o AVIF), assenza del tag fetchpriority="high" sull’immagine principale above the fold, e un TTFB (Time to First Byte) alto per via di hosting condivisi economici. Un server condiviso con TTFB superiore a 800ms compromette qualsiasi ottimizzazione front-end: anche con immagini perfettamente ottimizzate, il LCP resterà sopra soglia. Passare a un server VPS con configurazione dedicata e stack Nginx con FastCGI cache porta il TTFB sotto i 200ms nella maggior parte dei casi, con un impatto immediato sul LCP.
Sul fronte INP, il problema principale nei siti WordPress è il JavaScript generato da builder visuali come Elementor, Divi e WPBakery. Questi strumenti caricano centinaia di kilobyte di script che occupano il main thread del browser, rendendo la pagina non reattiva per centinaia di millisecondi dopo il caricamento. A questo si aggiungono plugin di marketing (chat live, popup, strumenti di heatmap) caricati in modo sincrono, script di pixel pubblicitari non gestiti correttamente tramite Tag Manager, e font Google non self-hosted che generano richieste esterne bloccanti. Il risultato tipico: un sito Elementor non ottimizzato su mobile si attesta tra 600ms e 1000ms di INP, con punteggio “scarso” che pesa sul ranking.
Sul fronte CLS, le cause più frequenti sono immagini senza attributi width e height nell’HTML, banner cookie e popup che si inseriscono dopo il rendering iniziale spostando il contenuto, font web che sostituiscono il fallback in modo visibile (flash of unstyled text). Il CLS è spesso la metrica più semplice da portare in soglia, una volta identificata la causa.
Per chi parte da zero, framework come Astro e Next.js gestiscono il JavaScript in modo molto più efficiente rispetto a un CMS non ottimizzato: garantiscono performance di default già dall’architettura. È l’approccio che seguo quando il progetto lo consente; i dettagli sono nell’area realizzazione siti web, dove l’architettura tecnica viene definita prima di grafica e contenuti.
Come misurare: field data vs lab data
La distinzione tra dati di laboratorio e dati di campo è critica per interpretare i risultati correttamente:
- Dati di campo (field data): misurati su sessioni reali degli utenti, raccolti dal CrUX. Sono questi che Google usa per il ranking.
- Dati di laboratorio (lab data): generati da Lighthouse su una singola simulazione. Utili per la diagnosi, ma non corrispondono necessariamente ai dati di campo.
Un sito può avere un punteggio Lighthouse di 90 e allo stesso tempo valori CrUX “da migliorare”: succede quando il laboratorio non riproduce le condizioni reali degli utenti (dispositivi lenti, connessioni variabili, script di terze parti che si comportano diversamente in produzione).
Gli strumenti da usare, in ordine:
Google Search Console (sezione Esperienza > Core Web Vitals): mostra lo stato aggregato per gruppi di URL, diviso tra desktop e mobile. Usa dati di campo. È il punto di partenza obbligatorio: un sito con molte URL in stato “scarso” su mobile ha un problema strutturale, non puntuale.
PageSpeed Insights: analizza singole URL combinando dati CrUX (se disponibili) con dati Lighthouse. Utile per diagnosticare pagine specifiche e capire quali ottimizzazioni hanno impatto immediato.
Chrome DevTools, pannello Performance: identifica i long task JavaScript che degradano l’INP. Mostra visivamente quali script bloccano il main thread e per quanto tempo.
Web Vitals Chrome Extension: misura LCP, INP e CLS in tempo reale durante la navigazione, simulando l’esperienza utente reale su desktop.
La frequenza di audit corretta è trimestrale, non solo reattiva. Gli aggiornamenti di plugin e temi WordPress introducono spesso regressioni silenziose: un plugin aggiornato può aumentare l’INP di 200ms senza che nessuno se ne accorga fino al calo di traffico successivo.
Interventi prioritari per chi è fuori soglia
Per un sito con metriche “da migliorare” o “scarse” su mobile, l’ordine di intervento per impatto effettivo:
1. Server e hosting. Se il TTFB supera i 600ms, nessuna ottimizzazione front-end recupererà un LCP accettabile. Il primo intervento è lì.
2. Immagine LCP. Conversione in WebP o AVIF, compressione, dimensionamento corretto, aggiunta del tag fetchpriority="high" sull’immagine hero, preconnect ai CDN di riferimento.
3. JavaScript e INP. Rimozione dei plugin inutilizzati, defer sistematico degli script non critici, sostituzione dei builder pesanti con temi leggeri (GeneratePress, Kadence, Blocksy), self-hosting dei font Google.
4. CLS. Aggiunta di width e height a tutte le immagini, spazi riservati per elementi dinamici, gestione corretta del banner cookie che non sposta il layout.
5. Cache. Cache a livello server (FastCGI cache o Redis object cache) più cache plugin (WP Rocket, LiteSpeed Cache). La cache server ha impatto diretto sul TTFB e quindi sul LCP.
Per un e-commerce su WooCommerce o Shopify, la complessità cresce perché le pagine prodotto e il checkout sono dinamici e aggregano spesso 40-60 script di terze parti. L’approccio corretto è il caricamento condizionale: script di pagamento solo sul checkout, pixel di tracking solo dove necessario, non globalmente su tutto il sito.
Per chi punta a competere su keyword nazionali ad alta concorrenza, una consulenza digitale strategica include sempre un audit tecnico CWV come primo passo: investire in link building o contenuti con un sito fuori soglia su mobile significa ottimizzare senza aver risolto il problema a monte.
Google non ha in programma di ridurre il peso dei Core Web Vitals: la direzione è opposta. Search Console mostra gratuitamente lo stato attuale del sito in dieci minuti. Il momento giusto per fare l’audit non è dopo il calo di traffico.