Il tuo sito carica in 3 secondi, il design è pulito, i contenuti sono curati. Eppure in Search Console vedi un avviso: "Problemi relativi ai Core Web Vitals". Le posizioni in SERP calano, il traffico organico arranca.
Succede più spesso di quanto credi. Noi di Meteora Web lo vediamo ogni giorno nei progetti che ci arrivano: siti con buona strategia ma prestazioni tecniche insufficienti. E Google oggi le misura con tre parametri precisi: LCP, INP, CLS. Non sono opinioni, sono numeri.
In questa guida ti spieghiamo cosa significano, quali sono le soglie da rispettare (aggiornate al 2026) e come incidono sul tuo posizionamento. Il tutto con esempi pratici, codice reale e nessuna teoria astratta.
Che cosa sono i Core Web Vitals e perché Google li usa
I Core Web Vitals sono un insieme di metriche introdotte da Google per misurare l'esperienza utente su una pagina web. Non guardano solo la velocità grezza, ma tre aspetti specifici: quanto velocemente viene mostrato il contenuto principale (LCP), quanto è reattiva la pagina ai click e tocchi (INP) e quanto è stabile visivamente durante il caricamento (CLS).
Google li usa come fattore di ranking dal giugno 2021. E a partire dal marzo 2024, INP ha sostituito FID (First Input Delay) come metrica ufficiale. Nel 2026 le soglie restano le stesse, ma l'algoritmo le applica con sempre più precisione. Se la tua pagina supera le soglie "poor" su una di queste, rischi di perdere posizioni in mobile e desktop.
LCP — Largest Contentful Paint: la velocità percepita
LCP misura il tempo impiegato dall'elemento più grande visibile nella finestra (immagine, blocco di testo, video) per essere renderizzato. In pratica: quanto tempo passa prima che l'utente veda qualcosa di sostanziale.
Soglie LCP (2026)
- Buono: < 2,5 secondi
- Migliorabile: 2,5 – 4 secondi
- Scarso: > 4 secondi
Il 90% delle visite deve rientrare nella soglia "buona" per superare l'esame di Google.
Cause comuni di LCP alto
Server lento (TTFB elevato), immagini non ottimizzate, risorse critiche non precaricate, CSS o JavaScript che bloccano il rendering. Noi abbiamo risolto recentemente un caso: un e-commerce con immagini da 3 MB ciascuna. Ottimizzandole e aggiungendo preload per la hero image, LCP è passato da 5,2s a 1,8s. Il cliente ha visto un incremento del 12% nel tasso di conversione.
Come ottimizzare LCP — esempio pratico
Precarica l'immagine più grande con <link rel="preload">:
<link rel="preload" href="/hero.webp" as="image" type="image/webp" fetchpriority="high">Imposta fetchpriority="high" sull'immagine stessa:
<img src="/hero.webp" alt="Prodotti in primo piano" width="1200" height="600" fetchpriority="high">Usa formati moderni (WebP, AVIF) e un CDN per ridurre la latenza geografica.
INP — Interaction to Next Paint: la reattività
INP misura la latenza di tutte le interazioni dell'utente (click, tocchi, pressioni di tasti) durante l'intera visita. Il punteggio finale è il peggior singolo ritardo osservato (o un percentile, in base alle implementazioni). Sostituisce FID perché non si limita alla prima interazione, ma valuta l'intera esperienza.
Soglie INP (2026)
- Buono: < 200 millisecondi
- Migliorabile: 200 – 500 ms
- Scarso: > 500 ms
Cause comuni di INP alto
JavaScript pesante eseguito sul thread principale (long task), listener di eventi costosi, terze parti (chatbot, analytics) che bloccano il rendering. Un nostro cliente aveva integrato uno slider con librerie non ottimizzate: ogni click sul carrello generava un ritardo di 600 ms. Abbiamo sostituito la libreria e aggiunto code-splitting: INP sceso a 120 ms.
Come ottimizzare INP
Dividi il codice in chunk caricati su richiesta. Usa defer o async per script non critici:
<script src="/analytics.js" defer></script>Spezza i long task con requestIdleCallback o scheduler.yield() (se supportato). Per esempio, se devi eseguire più operazioni, distribuisci il lavoro:
function processItems(items) {
if (items.length === 0) return;
const chunk = items.splice(0, 10);
chunk.forEach(doHeavyWork);
requestIdleCallback(() => processItems(items));
}
processItems(largeArray);CLS — Cumulative Layout Shift: la stabilità visiva
CLS misura quanto i contenuti si spostano inaspettatamente durante il caricamento. Un layout stabile significa che l'utente non si ritrova a cliccare su un link sbagliato perché un banner è apparso all'improvviso.
Soglie CLS (2026)
- Buono: < 0,1
- Migliorabile: 0,1 – 0,25
- Scarso: > 0,25
Il CLS si calcola come prodotto della frazione di viewport spostata per la distanza dello spostamento. Un valore 0,1 significa che il 10% della viewport ha subito uno spostamento.
Cause comuni di CLS alto
Immagini senza dimensioni esplicite, annunci pubblicitari con dimensioni variabili, web fonts che causano FOIT/FOUT, contenuti injettati via JavaScript senza spazio riservato.
Come ottimizzare CLS
Dai sempre width e height a immagini e video:
<img src="/foto.jpg" alt="Descrizione" width="800" height="600">Riserva spazio per annunci e widget dinamici con un contenitore di dimensioni fisse:
.ad-container {
width: 100%;
height: 250px; /* altezza tipica */
}Per i web font, usa font-display: optional per evitare layout shift se il font non viene caricato:
@font-face {
font-family: 'MyFont';
src: url('/font.woff2');
font-display: optional;
}Impatto SEO — come i Core Web Vitals influenzano il ranking
I Core Web Vitals sono un fattore di ranking ufficialmente riconosciuto da Google dal 2021. Non sono l'unico segnale — l'autorevolezza dei contenuti e i backlink restano fondamentali — ma possono fare la differenza in una SERP competitiva.
Google valuta il CWV a livello di singola pagina, non di intero dominio. Quindi puoi avere pagine con performance eccellenti e altre scarse. Il segnale si attiva quando una pagina non supera la soglia "buona" per almeno il 75% delle visite secondo i dati di Chrome UX Report (CrUX).
Nel concreto: se il tuo competitor ha lo stesso contenuto ma un LCP di 1,8 secondi e tu di 4,1 secondi, è probabile che Google lo premi. Abbiamo visto un caso reale: un blog tecnico ha portato LCP da 3,9s a 1,9s e CLS da 0,3 a 0,08. In tre mesi, il traffico organico è cresciuto del 22%. Non è magia, è fisica del web.
Strumenti per misurare e monitorare
Non puoi migliorare quello che non misuri. Ecco gli strumenti essenziali:
- Google Search Console: report Core Web Vitals nel menu “Esperienza”. Mostra le pagine classificate come “Scarse”, “Migliorabili” o “Buone” sulla base dei dati CrUX.
- PageSpeed Insights (PSI): dati di laboratorio (Lighthouse) + dati di campo (CrUX). È il punto di partenza.
- Chrome DevTools: scheda “Performance” e “Lighthouse” per debugging locale.
- GA4: puoi creare report personalizzati con il tracciamento delle metriche web. Se vuoi una guida su come configurare GA4, abbiamo scritto una guida pratica su Firebase e GA4.
Per un monitoraggio continuo, ti consigliamo di impostare alert su Search Console o strumenti di RUM come SpeedCurve o Datadog. Noi utilizziamo una combinazione di Lighthouse CI e dati CrUX per i nostri clienti.
In sintesi — cosa fare adesso
- Controlla il report Core Web Vitals in Search Console. Identifica le pagine con problemi.
- Esegui PageSpeed Insights su quelle pagine e leggi i suggerimenti specifici.
- Intervieni sulle cause prioritarie: per LCP = server e immagini, per INP = JavaScript, per CLS = dimensioni esplicite e spazio riservato.
- Ripeti il test dopo ogni modifica. Il feedback è rapido: una volta pubblicata la correzione, i dati CrUX si aggiornano in circa 28 giorni.
- Monitora nel tempo. Le metriche fluttuano con nuovi contenuti, plugin, aggiornamenti. Non abbassare la guardia.
Noi di Meteora Web lavoriamo quotidianamente su questi aspetti per i nostri clienti, dal dominio al fatturato. Se la tua azienda ha bisogno di un'analisi approfondita delle performance del sito, parliamone. Un sito che performa male è un costo, non una vetrina.
Sponsored Protocol
