Tutti gli articoli
Core Web VitalsPerformanceTechnical SEO

Core Web Vitals 2025: le metriche che Google usa davvero per il ranking

INP ha sostituito FID, LCP rimane critico e CLS si misura diversamente. Guida aggiornata alle Core Web Vitals 2025 con soglie, strumenti e fix pratici.

Redazione MiServeunseo.it25 aprile 20269 min di lettura

Se pensi che le Core Web Vitals siano "quella roba del 2021 che fa diventare verde il PageSpeed", è il momento di aggiornare la tua mappa mentale. A partire dal 2024 le metriche sono cambiate profondamente, i threshold sono più severi, e Google le usa in modo più diretto come segnale di ranking di quanto molti SEO ammettano.

Cosa sono le Core Web Vitals oggi

Le Core Web Vitals sono tre metriche di esperienza utente che Google misura attraverso i Chrome User Experience Report (CrUX) — dati reali raccolti da Chrome su milioni di utenti, non simulazioni di laboratorio.

Le tre metriche attuali sono:

  • LCP — Largest Contentful Paint (caricamento)
  • INP — Interaction to Next Paint (interattività)
  • CLS — Cumulative Layout Shift (stabilità visiva)

FID (First Input Delay) è stato rimosso nel 2024 e sostituito da INP.

LCP — Largest Contentful Paint

Cosa misura: il tempo necessario per renderizzare l'elemento visivo più grande visibile nel viewport iniziale — tipicamente un'immagine hero, un'intestazione H1 grande, o un blocco di testo principale.

Soglie:

ValutazioneSoglia
✅ Buono≤ 2,5 secondi
⚠️ Da migliorare2,5 – 4,0 secondi
❌ Scarso> 4,0 secondi

Cause comuni di LCP lento:

  • Immagini hero non ottimizzate (WebP/AVIF non usati, niente fetchpriority="high")
  • Server slow (TTFB alto)
  • CSS render-blocking
  • Fonts caricati senza font-display: swap

Fix prioritari:

<!-- Preload esplicito dell'immagine LCP -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<!-- Immagine con fetchpriority -->
<img src="/hero.webp" fetchpriority="high" loading="eager" alt="...">

Se il tuo LCP è un'immagine di sfondo CSS, Google non la rileva come tale. Spostala su un tag <img> è spesso il fix più impattante.

INP — Interaction to Next Paint

INP è la metrica più recente e quella che più sorprende i team di sviluppo.

Cosa misura: la latenza della peggiore interazione (tra click, tap e pressione di tasti) durante tutta la sessione utente — non solo la prima come faceva FID. Misura il tempo tra l'input dell'utente e il momento in cui il browser ha effettivamente aggiornato visivamente la pagina.

Soglie:

ValutazioneSoglia
✅ Buono≤ 200ms
⚠️ Da migliorare200 – 500ms
❌ Scarso> 500ms

Perché INP è più severo di FID

FID misurava solo il ritardo di input della prima interazione, e spesso passava anche su siti con JavaScript pesante. INP misura ogni interazione durante tutta la navigazione, quindi un click su un accordion, l'apertura di un menu mobile, il submit di un form — tutto conta.

Cause comuni di INP alto:

  • Long Tasks JavaScript: script che bloccano il main thread per >50ms
  • Gestori di eventi costosi: click handler che fanno troppo lavoro sincrono
  • Layout thrashing: lettura e scrittura del DOM alternata nello stesso frame
  • Terze parti: widget di chat, tracking, analytics

Come diagnosticarlo:

La metrica è visibile su:

  • Chrome DevTools → Performance → Total Blocking Time + Long Tasks
  • Web Vitals Extension di Chrome (mostra INP in tempo reale)
  • PageSpeed Insights (dati CrUX reali)
  • Google Search Console → Report Core Web Vitals
// Misura INP in real user monitoring
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.interactionId) {
      console.log('INP candidate:', entry.duration);
    }
  }
}).observe({ type: 'event', buffered: true, durationThreshold: 16 });

Fix pratici:

  1. Spezza i Long Tasks con scheduler.yield() o setTimeout(..., 0) per cedere il controllo al browser
  2. Lazy load degli script di terze parti — carica i widget di chat solo dopo il primo scroll
  3. Evita layout thrashing: raggruppa le letture DOM prima delle scritture
  4. Usa Web Workers per operazioni computazionalmente costose

CLS — Cumulative Layout Shift

Cosa misura: la somma degli spostamenti di layout inattesi durante la vita della pagina. Se un elemento si sposta perché un'immagine senza dimensioni si carica, o perché una banner appare sopra il contenuto, il CLS aumenta.

Soglie:

ValutazioneSoglia
✅ Buono≤ 0,1
⚠️ Da migliorare0,1 – 0,25
❌ Scarso> 0,25

Windowed CLS

Google ha modificato il calcolo: non somma più tutti gli shift della sessione, ma considera solo la finestra temporale di 1 secondo con il CLS peggiore. Questo avvantaggia le pagine con contenuto che viene caricato molto in ritardo (infinite scroll, lazy loading aggressivo).

Fix prioritari:

<!-- Sempre specificare width e height per le immagini -->
<img src="foto.webp" width="800" height="600" alt="...">

<!-- Per i font, usa font-display: optional per eliminare il FOUT -->
@font-face {
  font-display: optional;
}

<!-- Riserva spazio per gli annunci -->
<div style="min-height: 250px;">
  <!-- spazio per banner -->
</div>

Come monitorare in produzione

PageSpeed Insights e Lighthouse ti danno dati di laboratorio, ma ciò che conta per il ranking sono i dati CrUX (utenti reali). Puoi accedervi da:

  1. Google Search Console → Esperienza → Core Web Vitals: il modo più diretto per vedere quante URL del tuo sito passano la soglia
  2. PageSpeed Insights: mostra sia dati di laboratorio che CrUX nella stessa pagina
  3. CrUX Dashboard su Looker Studio: gratuita, aggiornata mensilmente
  4. web-vitals.js: libreria JavaScript open-source per raccogliere dati in real user monitoring nel tuo analytics

Core Web Vitals e ranking: quanto contano davvero?

La risposta onesta è: contano, ma non sono il fattore dominante. Google ha confermato che le CWV fanno parte del Page Experience signal, che però rimane un fattore di ranking secondario rispetto a rilevanza del contenuto e autorità.

Detto questo, nelle SERP competitive dove due pagine hanno contenuto comparabile, le CWV possono fare la differenza. E soprattutto: un sito lento e instabile danneggia le conversioni indipendentemente dal SEO — gli studi di Google mostrano che ogni secondo aggiuntivo di LCP riduce le conversioni del 4–12%.

La regola pratica: non ossessionarti per passare da 72 a 80 su PageSpeed se il tuo contenuto non è buono. Ma se hai URL con valutazione "Scarso" in Search Console, risolvile — stai lasciando performance sul tavolo sia SEO che UX.

Checklist

Prima di chiudere, una checklist rapida per il tuo audit:

  • Verifica le URL "Scarso" e "Da migliorare" in Search Console
  • Controlla LCP: è un'immagine? Ha fetchpriority="high" e preload?
  • Controlla INP: installa la Web Vitals Extension e naviga il sito come un utente
  • Controlla CLS: tutte le immagini hanno width e height espliciti?
  • I font usano font-display: swap o optional?
  • Gli script di terze parti sono caricati con defer o async?
  • Usi una CDN con HTTP/2 o HTTP/3?

Le Core Web Vitals non sono un traguardo da raggiungere una volta e dimenticare: sono un monitoraggio continuo. Integralo nel tuo processo di sviluppo e avrai un vantaggio strutturale sui competitor che ci pensano solo quando Google manda un avviso.

Tag

Core Web Vitals
Performance
Technical SEO
Tutti gli articoli

Cerchi un consulente SEO?

MiServeunseo.it è la directory italiana dei professionisti SEO. Trova il consulente giusto per il tuo progetto, con profili verificati e contatto diretto.

Cerca consulenti SEO