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

Il percorso più veloce per superare i Core Web Vitals

Sai che i tuoi Core Web Vitals hanno bisogno di lavoro. Google Search Console mostra rosso o arancione, un cliente sta facendo domande, o PageSpeed Insights ha appena dato brutte notizie. Questa pagina è il flusso di lavoro che uso per portare i siti da bocciati a promossi il più velocemente possibile.

Ho usato questo flusso di lavoro per aiutare siti a superare i Core Web Vitals su centinaia di migliaia di pagine. Funziona su WordPress, Shopify, build personalizzate e ogni piattaforma nel mezzo. 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 superano 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 li supera.

Scomposto per metrica (percentuale di origini valutate "buone" su mobile):

Fonte: Web Almanac 2025 (HTTP Archive, dati CrUX luglio 2025). I dati RUM di CoreDash sui siti monitorati mostrano distribuzioni simili.

LCP è il collo di bottiglia. Il 77% supera INP e l'81% supera CLS, ma solo il 62% supera LCP. Questo è ciò che abbassa il tasso di superamento complessivo al 48%. Ecco perché il flusso di lavoro qui sotto dà 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 da "bocciato" a "tutte e tre le metriche superate" 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 riflettesse i miglioramenti. I siti che sono passati direttamente all'ottimizzazione del JavaScript senza correggere prima 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, scopri esattamente quali metriche stanno fallendo e su quali pagine. Se salti questo passaggio e tiri a indovinare, perderai tempo a correggere le cose sbagliate.

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 Buono, Da migliorare o Scadente
• Quale metrica specifica sta fallendo (LCP, INP o CLS)
• Gruppi di URL che condividono lo stesso problema (ad es. tutte le pagine prodotto che falliscono su INP)

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

Esegui PageSpeed Insights sulle pagine chiave

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

Guarda prima la sezione dei dati di campo (etichettata "Scopri cosa stanno vivendo i tuoi utenti reali"). Se mostra verde per tutte e tre le metriche, quella pagina supera. Se i dati di campo non sono disponibili, la pagina non ha abbastanza traffico per i dati CrUX. Google potrebbe utilizzare 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 impiegano settimane per apparire. 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 stanno fallendo, correggile in questo ordine:

Il TTFB non è un Core Web Vital di per sé, ma ogni millisecondo di TTFB è un millisecondo aggiunto direttamente al tuo LCP e FCP. Una pagina con 800ms di TTFB ha già utilizzato un terzo del budget di 2,5 secondi per LCP prima ancora che il browser inizi a renderizzare. La soglia "buona" di CrUX per il TTFB è 800ms, ma più veloce è sempre meglio perché ogni miglioramento del TTFB si trasferisce direttamente alle metriche di rendering. 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. I problemi abituali:

• Hosting lento: passa a un hosting di qualità con caching a livello server. Gli hosting gestiti per WordPress (Kinsta, SiteGround, Cloudways) o l'infrastruttura integrata di Shopify gestiscono questo aspetto.
• Nessun page caching: assicurati che il tuo CMS memorizzi nella cache l'HTML completamente renderizzato in modo che il server non lo rigeneri 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 del 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 tua pagina con problemi in PageSpeed Insights e trova l'"Elemento Largest Contentful Paint" nella sezione Diagnostica. Di solito è un'immagine hero, un'immagine in evidenza o un grande blocco di testo.

Se LCP è un'immagine

1. Assicurati che il browser possa trovarla nell'HTML. L'URL dell'immagine deve essere in un tag <img src=""> regolare, non nascosto dietro un attributo data-src o caricato tramite JavaScript. Se il parser HTML del browser non riesce a vedere l'URL dell'immagine, non può iniziare a caricarla presto. Secondo il Web Almanac 2025, il 7% dei siti web nasconde ancora la propria immagine LCP in questo modo.
2. Aggiungi fetchpriority="high" al tag <img>. Questo dice al browser di dare priorità a questa immagine rispetto ad altre risorse che competono per la banda. Senza di esso, il browser potrebbe scaricare prima fogli di stile, script e altre immagini. In un test di Google su Google Flights, questa singola modifica ha migliorato LCP da 2,6s a 1,9s.
3. Rimuovi loading="lazy". Il lazy loading ritarda la richiesta finché l'immagine non è vicina al viewport. Su un'immagine LCP, quel ritardo si aggiunge direttamente al tuo punteggio LCP.
4. Ottimizza la dimensione del file. Converti in WebP o AVIF. Servi le dimensioni corrette per il viewport usando srcset e sizes.
5. Se l'immagine non è nell'HTML (immagine di sfondo CSS, caricata tramite JavaScript, o su una pagina dove non puoi modificare il tag <img>): aggiungi un preload. Usa <link rel="preload" as="image" href="..." fetchpriority="high"> nell'<head>. Il preload costringe il browser a scoprire l'immagine presto anche quando non è visibile nel sorgente HTML. Per le immagini che sono già in un tag <img> normale, il preload di solito non è necessario perché il parser le trova già.

Se LCP è testo

1. Elimina il CSS che blocca il rendering. Genera e inserisci inline il CSS critico così il browser può renderizzare il testo senza attendere i fogli di stile esterni.
2. Ottimizza il caricamento dei font. Ospita i tuoi font in self-hosting e precarica il file del font principale per ridurre il tempo prima che il testo venga renderizzato.
3. Minimizza il JavaScript che blocca il rendering. Differisci il JavaScript non critico così non blocca il parser HTML.

Passaggio 5: Correggi INP

Una volta che LCP è superato, affronta l'Interaction to Next Paint. INP fallisce quando il JavaScript blocca il thread principale durante le interazioni dell'utente.

Trova il collo di bottiglia

Apri Chrome DevTools, vai al pannello Performance e registra te stesso 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.

Cosa di solito blocca il thread principale:

• Script di terze parti (analytics, annunci, 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 fanno troppo lavoro in risposta a un clic o 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. Spezza i long task. Se il tuo codice ha funzioni che impiegano più di 50ms, cedi il controllo al thread principale per permettere al browser di elaborare l'input dell'utente tra i blocchi di lavoro. Il modo moderno è scheduler.yield() (supportato in Chrome 129+ e Edge). Per un supporto browser più ampio, usa come fallback il wrapping del lavoro in setTimeout(resolve, 0) dentro una Promise:

   async function yieldToMain() {
     if ('scheduler' in window && 'yield' in scheduler) {
       return scheduler.yield();
     }
     return new Promise(resolve => setTimeout(resolve, 0));
   }

4. Rimuovi il JavaScript inutilizzato. Usa la scheda Coverage di Chrome DevTools per identificare il JavaScript che si carica ma non viene mai eseguito. Rimuovilo o caricalo condizionalmente.

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

Passaggio 6: Correggi CLS

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

Immagini senza dimensioni

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

Scambio dei font web

Quando un font web si carica e sostituisce il fallback, il testo può riformattarsi e spostare gli elementi circostanti. Soluzione: ospita i font in self-hosting, usa font-display: optional o usa la proprietà CSS size-adjust per far corrispondere le metriche del font fallback a quelle del font web.

Contenuto iniettato dinamicamente

Banner per i cookie, barre di notifica, spazi pubblicitari e popup che spingono il contenuto verso il basso dopo il caricamento. Soluzione: riserva spazio per questi elementi con min-height CSS o caricali in un modo che non influenzi il layout circostante (ad es. overlay anziché 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 il miglioramento, Search Console seguirà.

Questo ritardo è il motivo per cui il RUM è essenziale. Senza di esso, non hai visibilità sul fatto che le tue modifiche abbiano effettivamente funzionato fino a settimane dopo.

Passaggio 8: Monitora e mantieni

Le prestazioni regrediscono. Ogni nuovo plugin, aggiornamento del tema o script di terze parti può annullare il tuo lavoro. 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
• Ritesta in PageSpeed Insights dopo ogni modifica significativa (nuovo plugin, aggiornamento tema, nuovo script di terze parti)
• Effettua un audit degli script di terze parti trimestralmente. Rimuovi quelli che non sono 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 range di impatto provengono dai dati di Real User Monitoring di CoreDash attraverso progetti di ottimizzazione. Il tuo miglioramento effettivo dipende 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 bocciare e superare.

I dati del Web Almanac 2025 supportano 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 fallisce ma le pagine interne superano, concentra il tuo sforzo di ottimizzazione LCP e INP specificamente sul template della homepage.