Come superare i Core Web Vitals: passo dopo passo (2026)

Il percorso più rapido per superare i Core Web Vitals

Sai che i tuoi Core Web Vitals hanno bisogno di miglioramenti. Forse Google Search Console mostra rosso o arancione. Forse un cliente chiede perché il suo sito non supera i test. Forse hai appena eseguito PageSpeed Insights e i numeri sono pessimi. Non hai bisogno di un altro articolo che spieghi cosa sono le metriche. Hai bisogno di un flusso di lavoro che ti porti dal fallimento al superamento nel modo più efficiente possibile.

Questa guida è quel flusso di lavoro. L'ho utilizzato per aiutare i siti a superare i Core Web Vitals su centinaia di migliaia di pagine. Funziona su WordPress, Shopify, build personalizzate e ogni piattaforma intermedia. L'intuizione chiave: l'ordine in cui correggi le cose è importante. Correggi prima le fondamenta, poi lavora verso l'esterno. Altrimenti perdi tempo a ottimizzare cose che un problema più profondo sovrascriverà.

Dove si trova il web in questo momento

Secondo il Web Almanac 2025 (basato sui dati CrUX di luglio 2025), il 48% dei siti web mobile e il 56% dei siti web desktop supera tutti e tre i Core Web Vitals. Si tratta di un miglioramento rispetto al 44% mobile del 2024, ma significa comunque che più della metà del web mobile non supera i test.

Analisi per singola metrica (percentuale di origini valutate "good" su mobile):

Fonti: Web Almanac 2025 (HTTP Archive, luglio 2025), analisi CrUX di DebugBear (ott 2025), analisi CrUX di NitroPack.

La matematica è chiara: LCP è il collo di bottiglia. Se l'87% supera INP e l'80% supera CLS ma solo il 66% supera LCP, allora è LCP a trascinare il tasso di superamento complessivo al 48%. Ecco perché il flusso di lavoro qui sotto dà la priorità a TTFB e LCP.

I dati aggregati di CoreDash raccontano la stessa storia. Tra i siti che hanno implementato esattamente questo flusso di lavoro (TTFB → LCP → INP → CLS in ordine), il tempo medio dal "fallimento" al "superamento di tutte e tre le metriche" in CrUX è stato di 4-6 settimane: 1-2 settimane per l'implementazione, più 2-4 settimane affinché la finestra mobile di 28 giorni di CrUX rifletta i miglioramenti. I siti che sono passati direttamente all'ottimizzazione JavaScript senza prima correggere il TTFB hanno impiegato 2-3 volte più tempo per raggiungere il superamento perché le fondamenta erano instabili.

Passaggio 1: valuta la tua situazione attuale

Prima di modificare qualsiasi cosa, devi sapere esattamente quali metriche non superano la soglia e su quali pagine. Non saltare questo passaggio. Procedere per ipotesi porta a sprechi di tempo.

Controlla Google Search Console

Vai alla tua proprietà in Search Console e apri il report Core Web Vitals sotto "Esperienza". Questo ti mostra:

• Quanti URL sono valutati Good, Needs Improvement o Poor
• Quale metrica specifica non supera la soglia (LCP, INP o CLS)
• Gruppi di URL che condividono lo stesso problema (es. tutte le pagine prodotto con INP insufficiente)

Search Console utilizza dati di campo reali dagli utenti Chrome su una finestra mobile di 28 giorni. Questi sono i dati che Google usa per il ranking. Se Search Console mostra che stai superando i test, stai superando i test, indipendentemente da ciò che dice Lighthouse.

Esegui PageSpeed Insights sulle pagine chiave

Testa almeno un URL per ogni tipo di pagina: la tua homepage, un articolo del blog, una pagina prodotto, una pagina categoria/collezione. PageSpeed Insights fornisce sia dati di campo (se disponibili) che dati di laboratorio con diagnostiche specifiche.

Guarda prima la sezione dati di campo (etichettata "Scopri cosa stanno vivendo i tuoi utenti reali"). Se mostra verde per tutte e tre le metriche, quella pagina supera i test. Se i dati di campo non sono disponibili, la pagina non ha abbastanza traffico per i dati CrUX. Google potrebbe usare i dati a livello di origine o di gruppo di URL.

Configura il Real User Monitoring

Search Console e CrUX hanno una finestra mobile di 28 giorni, il che significa che i miglioramenti richiedono settimane per essere visibili. Per vedere l'impatto immediato delle tue modifiche, configura una soluzione di Real User Monitoring (RUM) come CoreDash. Il RUM ti fornisce dati di campo in tempo reale per ogni pagina, ogni dispositivo e ogni paese, così puoi verificare che ogni correzione funzioni prima di passare alla successiva.

Passaggio 2: identifica quale metrica correggere per prima

Se più metriche non superano la soglia, correggile in questo ordine:

Il TTFB non è un Core Web Vital in sé, ma è la base. Se il tuo TTFB è superiore a 800ms, nessuna ottimizzazione di immagini o differimento di JavaScript salverà il tuo LCP. Scopri di più nella nostra guida al Time to First Byte.

Passaggio 3: correggi le fondamenta (TTFB)

Se il tuo Time to First Byte è costantemente superiore a 400ms, inizia da qui. Cause comuni e soluzioni:

• Hosting lento: passa a un hosting di qualità con caching a livello server. Host gestiti per WordPress (Kinsta, SiteGround, Cloudways) o l'infrastruttura integrata di Shopify gestiscono questo aspetto.
• Nessun caching delle pagine: assicurati che il tuo CMS memorizzi nella cache l'HTML completamente renderizzato in modo che il server non debba rigenerarlo ad ogni richiesta.
• Nessun CDN: configura un CDN (Cloudflare è gratuito) per servire le pagine da posizioni edge vicine ai visitatori. Vedi la guida alla configurazione di Cloudflare.
• Redirect: ogni redirect aggiunge un round trip completo. Elimina le catene di redirect non necessarie.
• Backend lento: query di database non ottimizzate, plugin WordPress eccessivi o elaborazione lato server pesante. Usa strumenti di monitoraggio delle query per identificare i colli di bottiglia.

Obiettivo: portare il TTFB sotto i 200ms per la maggior parte dei visitatori. Come minimo, sotto i 400ms.

Passaggio 4: correggi LCP

Una volta che il TTFB è solido, correggi il Largest Contentful Paint. Il processo:

Identifica il tuo elemento LCP

Esegui la pagina che non supera il test in PageSpeed Insights e trova l'"Elemento Largest Contentful Paint" nella sezione Diagnostica. Di solito è un'immagine hero, un'immagine in evidenza o un blocco di testo grande.

Se LCP è un'immagine

1. Precaricala. Aggiungi <link rel="preload" as="image" href="..." fetchpriority="high"> nell'<head>.
2. NON caricarla in lazy loading. Rimuovi loading="lazy" dall'immagine LCP. Aggiungi invece fetchpriority="high" al tag <img>.
3. Ottimizza la dimensione del file. Converti in WebP o AVIF. Servi le dimensioni corrette per il viewport (usa srcset e sizes).
4. Rendi l'URL individuabile nell'HTML. L'URL dell'immagine deve essere nel sorgente HTML (tramite <img src="">), non caricato dinamicamente da JavaScript. Il 7% dei siti web nasconde la propria immagine LCP dietro attributi data-src che richiedono JavaScript per il rendering.

Se LCP è testo

1. Elimina il CSS che blocca il rendering. Genera e inserisci inline il CSS critico in modo che il browser possa renderizzare il testo senza attendere fogli di stile esterni.
2. Ottimizza il caricamento dei font. Ospita i font in locale e precarica il file del font principale per ridurre il tempo prima che il testo venga visualizzato.
3. Minimizza il JavaScript che blocca il rendering. Differisci il JavaScript non critico in modo che non blocchi il parser HTML.

Passaggio 5: correggi INP

Una volta che LCP supera la soglia, affronta Interaction to Next Paint. INP non supera il test quando JavaScript blocca il thread principale durante le interazioni dell'utente.

Trova il collo di bottiglia

Apri Chrome DevTools, vai al pannello Performance e registra mentre interagisci con la pagina. Cerca i long task (task superiori a 50ms, mostrati come barre rosse). Questi sono ciò che impedisce al browser di rispondere ai tuoi clic.

Cause comuni sulla maggior parte dei siti:

• Script di terze parti (analytics, ads, widget chat, tag di marketing) che competono per il tempo del thread principale
• Bundle JavaScript di grandi dimensioni da framework, page builder o plugin che si eseguono durante il caricamento della pagina
• Event handler non ottimizzati che eseguono troppo lavoro in risposta a un clic o una pressione di tasto

La priorità delle correzioni

1. Ritarda gli script di terze parti. Chat, analytics, social e script di marketing dovrebbero caricarsi dopo la prima interazione dell'utente, non durante il caricamento della pagina.
2. Differisci il JavaScript first-party non critico. Usa defer o async sugli script che non devono essere eseguiti prima che la pagina sia interattiva.
3. Suddividi i long task. Se il tuo codice ha funzioni che richiedono più di 50ms, cedi il controllo al thread principale usando scheduler.yield() o setTimeout per consentire al browser di elaborare l'input dell'utente tra i blocchi di lavoro.
4. Rimuovi il JavaScript inutilizzato. Usa la scheda Coverage di Chrome DevTools per identificare il JavaScript che viene caricato ma mai eseguito. Rimuovilo o caricalo condizionalmente.

Per la strategia completa di ottimizzazione INP, consulta la nostra guida all'ottimizzazione INP.

Passaggio 6: correggi CLS

CLS è generalmente la metrica più facile da correggere. Le cause più comuni e le soluzioni:

Immagini senza dimensioni

Ogni tag <img> necessita di attributi espliciti width e height. Senza di essi, il browser non sa quanto spazio riservare e il contenuto si sposta quando l'immagine viene caricata. Questa è la causa #1 di CLS a livello globale. Consulta la nostra guida al CLS.

Sostituzione dei web font

Quando un web font viene caricato e sostituisce il fallback, il testo può rifluire e spostare gli elementi circostanti. Soluzione: ospita i font in locale, usa font-display: optional o utilizza la proprietà CSS size-adjust per far corrispondere le metriche del font di fallback a quelle del web font.

Contenuto iniettato dinamicamente

Cookie banner, barre di notifica, spazi pubblicitari e popup che spostano il contenuto verso il basso dopo il caricamento. Soluzione: riserva spazio per questi elementi con CSS min-height o caricali in modo che non influenzino il layout circostante (es. overlay invece di iniezione inline).

Passaggio 7: verifica con i dati di campo

Dopo aver implementato le correzioni, devi verificare che funzionino nel mondo reale, non solo in Lighthouse.

• Verifica immediata: usa CoreDash o un altro strumento RUM per vedere i dati di campo in tempo reale. Le modifiche dovrebbero essere visibili entro poche ore.
• Verifica CrUX: il Chrome User Experience Report utilizza una finestra mobile di 28 giorni. Aspettati 2-4 settimane prima che i miglioramenti si riflettano completamente nei dati CrUX.
• Verifica Search Console: il report Core Web Vitals in Search Console si aggiorna in base a CrUX. Una volta che CrUX mostra miglioramenti, Search Console seguirà.

Questo ritardo è il motivo per cui il RUM è essenziale. Senza di esso, navighi alla cieca per settimane dopo aver apportato le modifiche.

Passaggio 8: monitora e mantieni

Superare i Core Web Vitals non è un risultato una tantum. Le prestazioni regrediscono man mano che aggiungi contenuti, installi plugin, aggiorni temi e aggiungi script di terze parti. Configura un monitoraggio continuo:

• Controlla il report Core Web Vitals di Search Console settimanalmente
• Usa CoreDash per un monitoraggio continuo in tempo reale con avvisi
• Riesegui il test su PageSpeed Insights dopo ogni modifica significativa (nuovo plugin, aggiornamento del tema, nuovo script di terze parti)
• Effettua un audit degli script di terze parti trimestralmente. Rimuovi quelli non più necessari.

Per un riferimento completo di tutto ciò che dovresti controllare, usa la nostra Checklist definitiva dei Core Web Vitals.

Vittorie rapide: le correzioni con il maggiore impatto

Se hai tempo solo per cinque cose, queste sono le correzioni con il maggiore impatto su tutte le piattaforme:

Questi intervalli di impatto non sono stime. Provengono dai dati di Real User Monitoring di CoreDash raccolti durante progetti di ottimizzazione. Il miglioramento effettivo sul tuo sito dipenderà dal punto di partenza, dal tuo hosting e dal profilo del tuo traffico. I siti che partono da punteggi molto scarsi (LCP superiore a 5 secondi) spesso vedono miglioramenti ancora maggiori. I siti già vicini alla soglia possono vedere guadagni assoluti minori ma la differenza tra non superare e superare il test.

I dati del Web Almanac 2025 confermano queste priorità. Le homepage superano i Core Web Vitals al 45% su mobile, mentre le pagine secondarie superano al 56%. Il divario è dovuto al fatto che le homepage tendono ad avere più contenuti dinamici, immagini hero più grandi e più script di terze parti. Se la tua homepage non supera il test ma le pagine interne sì, concentra lo sforzo di ottimizzazione LCP e INP specificamente sul template della homepage.