Core Web Vitals nel 2026: cosa incide davvero sul posizionamento

Cosa misurano oggi i Core Web Vitals

I Core Web Vitals sono tre metriche che descrivono come i visitatori reali percepiscono una pagina. Il Largest Contentful Paint (LCP) misura il caricamento: quanto tempo passa prima che l’immagine o il blocco di testo principale sia visibile. L’Interaction to Next Paint (INP) misura la reattività: quanto impiega la pagina a reagire visibilmente dopo un tocco, un clic o la pressione di un tasto. Il Cumulative Layout Shift (CLS) misura la stabilità visiva: quanto si spostano i contenuti mentre la pagina si carica.

Una pagina supera la valutazione quando almeno il 75% delle visite rientra nella fascia “buona”: LCP pari o inferiore a 2,5 secondi, INP pari o inferiore a 200 millisecondi e CLS pari o inferiore a 0,1. Mobile e desktop vengono valutati separatamente, e il mobile è quasi sempre il più difficile.

A marzo 2024 l’INP ha sostituito il First Input Delay (FID) come Core Web Vital. Il FID misurava solo il ritardo prima della prima interazione; l’INP considera le interazioni più lente dell’intera visita. Molti siti che erano tranquillamente in verde con il FID sono passati al giallo o al rosso con l’INP.

Quanto incidono sul posizionamento?

I Core Web Vitals fanno parte dei segnali di page experience di Google. Non contano più della pertinenza: una pagina lenta con la risposta migliore batterà comunque una pagina veloce con una risposta debole. Contano tra pagine di qualità simile e nella conversione: i visitatori abbandonano le pagine lente e instabili, qualunque sia il loro posizionamento.

Per questo trattiamo i vitals prima come metrica di business e poi come metrica SEO. Pagine più veloci vendono di più, generano più richieste e costano meno in traffico a pagamento.

Dati sul campo e dati di laboratorio

I punteggi di laboratorio di Lighthouse e PageSpeed Insights simulano una sola visita su un dispositivo rallentato. Sono utili per il debug, ma Google posiziona in base ai dati sul campo del Chrome User Experience Report (CrUX), raccolti dagli utenti reali di Chrome in 28 giorni.

Parti dal report Core Web Vitals di Search Console per vedere quali gruppi di URL non superano la valutazione e su quale metrica. Poi usa PageSpeed Insights per i dati sul campo di un singolo URL e il pannello Performance di Chrome DevTools per trovare la causa.

Come migliorare l’LCP

La maggior parte dei problemi di LCP ha quattro origini: una risposta lenta del server, un’immagine hero scoperta tardi, CSS e font che bloccano il rendering, o un’immagine semplicemente troppo pesante.

• Porta il Time to First Byte sotto circa 800 ms: cache dell’intera pagina per i visitatori anonimi, una CDN e query al database veloci.
• Non usare mai il lazy-load sull’immagine LCP. Assegnale fetchpriority="high" e precaricala se è impostata nel CSS.
• Servi AVIF o WebP nella dimensione giusta con srcset e sizes, invece di un unico JPEG pesante.
• Inserisci inline il CSS critico e carica il resto senza blocchi; ospita i font in locale e usa font-display: swap.

Come migliorare l’INP

L’INP è quasi sempre un problema di JavaScript. Quando il thread principale è occupato da un task lungo, cioè oltre 50 ms, il browser non può rispondere al tocco dell’utente finché non ha terminato.

Controlla prima gli script di terze parti: widget di chat, heatmap, strumenti di A/B testing e più container di tag aggiungono spesso centinaia di millisecondi. Caricali dopo l’interazione o solo su pagine specifiche. Nel tuo codice, mantieni piccoli gli event handler, applica il debounce agli handler di input e suddividi il lavoro lungo in blocchi più piccoli, così il browser può disegnare tra uno e l’altro. Anche un DOM molto grande (diverse migliaia di elementi) rallenta ogni interazione, ed è frequente con i page builder.

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

Come migliorare il CLS

• Imposta sempre width e height (o aspect-ratio) su immagini, video e iframe.
• Riserva lo spazio per annunci, embed e banner dei cookie invece di spingere giù i contenuti quando si caricano.
• Evita di inserire banner o avvisi sopra i contenuti esistenti dopo che la pagina è stata visualizzata.
• Usa font di fallback con metriche corrispondenti (size-adjust), così il testo non si riposiziona quando arriva il web font.

Specificità di Laravel e WordPress

Su Laravel, i risultati rapidi arrivano dalle cache di produzione (php artisan config:cache, route:cache, view:cache), da OPcache, da Redis per cache e sessioni e dall’eager loading per eliminare le query N+1 che rallentano il primo byte. Compila gli asset con Vite perché CSS e JavaScript siano minificati e versionati, e sposta in coda il lavoro lento come email e chiamate API.

Su WordPress, la maggior parte dei problemi viene dai plugin. Rimuovi quelli che non ti servono, usa una vera cache delle pagine (LiteSpeed Cache sui server LiteSpeed funziona molto bene), ottimizza le immagini al caricamento, mantieni PHP su una versione 8.x supportata e fai attenzione ai page builder pesanti.

Misura, poi aspetta

Aggiungi la libreria open source web-vitals per inviare i valori reali di LCP, INP e CLS a GA4 o a un tuo endpoint, così vedi i cambiamenti in pochi giorni invece di aspettare CrUX. Il report di Search Console usa una finestra mobile di 28 giorni, quindi dopo una correzione servono circa quattro settimane prima che lo stato diventi verde. Convalida la correzione lì quando arrivano i nuovi dati.

Se vuoi una prima panoramica rapida del tuo sito, il nostro controllo gratuito segnala risposte lente, compressione assente e altre cause comuni.