Core Web Vitals spiegati: LCP, INP e CLS in parole semplici

I Core Web Vitals non sono un test di personalità per il tuo sito web

I Core Web Vitals vengono spesso trattati come una misteriosa scheda di valutazione. Una pagina riceve un numero rosso, qualcuno pubblica uno screenshot su Slack e il team inizia a discutere di framework JavaScript.

Non è particolarmente utile.

Il modo migliore di pensare ai Core Web Vitals è più semplice: sono tre misurazioni che indicano se una pagina sembra utilizzabile a una persona reale su un dispositivo reale. Non catturano ogni aspetto di performance, accessibilità o qualità. Ma individuano tre fonti comuni di frustrazione:

• Il contenuto principale impiega troppo tempo a comparire.
• La pagina reagisce lentamente quando l’utente prova a fare qualcosa.
• Il layout si sposta mentre l’utente legge o tocca lo schermo.

Questi sono i tre Core Web Vitals: LCP, INP e CLS.

Google li usa come parte dei suoi segnali di page experience, ma l’aspetto SEO non è la ragione migliore per interessarsene. La ragione migliore è che pagine lente, instabili e poco reattive fanno perdere tempo agli utenti. Tendono anche a convertire peggio, a generare più richieste di supporto e a invecchiare male.

Le tre metriche in una frase ciascuna

Prima di entrare nei dettagli, ecco la versione in parole semplici:

• LCP, o Largest Contentful Paint, misura quanto tempo serve perché il contenuto visibile principale venga caricato.
• INP, o Interaction to Next Paint, misura quanto rapidamente la pagina risponde alle interazioni dell’utente durante la visita.
• CLS, o Cumulative Layout Shift, misura quanto la pagina si muove in modo inatteso.

Le soglie abituali sono:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s o più veloce | 2.5s–4.0s | Oltre 4.0s | | INP | 200ms o più veloce | 200ms–500ms | Oltre 500ms | | CLS | 0.1 o inferiore | 0.1–0.25 | Oltre 0.25 |

Questi numeri vengono normalmente valutati al 75° percentile delle visite di utenti reali. È importante. Non stai cercando di ottenere un singolo test di laboratorio perfetto. Stai cercando di rendere buona l’esperienza per la maggior parte degli utenti, incluse le persone con telefoni più lenti e reti più instabili.

Se stai fissando un report automatizzato e non sai da dove iniziare, è utile separare la diagnosi dal panico. Abbiamo una guida separata su come leggere un report Lighthouse senza andare nel panico, che copre quel flusso di lavoro in modo più dettagliato.

LCP: quando la pagina sembra caricata?

Largest Contentful Paint misura il tempo di rendering dell’elemento di contenuto visibile più grande nel viewport. In pratica, spesso si tratta di:

• un’immagine hero,
• un titolo grande,
• l’immagine di un articolo in evidenza,
• un’immagine di prodotto,
• un grande blocco di testo.

LCP non chiede quando ogni script, tracking pixel e immagine below-the-fold ha finito di caricarsi. Chiede: quando è diventata visibile la cosa principale che l’utente era venuto a vedere?

Questo rende LCP una metrica più umana rispetto al vecchio “tempo di caricamento della pagina”. Una pagina può tecnicamente finire di caricarsi tardi ma sembrare comunque veloce se il contenuto principale appare rapidamente. È vero anche il contrario: una pagina può attivare l’evento load mentre l’area hero è ancora vuota, sfocata o bloccata da un ritardo di rendering.

Cause comuni di un LCP scarso

La maggior parte dei problemi di LCP scadente deriva da pochi punti prevedibili:

1. Risposta del server lenta

Se il documento HTML arriva tardi, tutto il resto parte tardi.

1. CSS o JavaScript che bloccano il rendering

Il browser ha il contenuto, ma non può ancora disegnarlo.

1. Immagini hero non ottimizzate

L’elemento più grande è troppo pesante, nel formato sbagliato, non prioritizzato o caricato in lazy loading per errore.

1. Web font che ritardano il rendering del testo

Un titolo grande potrebbe essere l’elemento LCP, e il caricamento dei font può ritardarlo o modificarlo visivamente.

1. Ritardi dovuti al rendering client-side

Se la pagina ha bisogno di un grande bundle JavaScript prima di poter mostrare contenuto significativo, LCP ne risente.

Come migliorare LCP

Parti dall’elemento LCP effettivo. Non ottimizzare asset casuali finché non sai cosa sta misurando il browser.

Le soluzioni pratiche includono:

• Servire HTML rapidamente: usa la cache dove appropriato, riduci il lavoro del backend, evita redirect lenti.
• Ottimizzare l’immagine LCP: usa dimensioni, compressione e formato corretti.
• Non caricare in lazy loading l’immagine hero above-the-fold.
• Usa fetchpriority="high" con cautela per l’immagine principale quando è davvero la priorità.
• Inserisci inline il CSS critico solo quando riduce in modo significativo il ritardo di rendering.
• Riduci il JavaScript necessario prima del primo rendering significativo.
• Usa font-display: swap o un’altra strategia intenzionale per i font.

Immagini e font sono colpevoli frequenti. Per le immagini, il compromesso non è solo “file piccolo uguale buono”. La scelta del formato, lo sforzo di codifica e il supporto dei browser contano tutti, motivo per cui manteniamo un albero decisionale pratico per quando AVIF batte WebP e quando no. Per le pagine molto basate sul testo, i web font sono ancora una delle vittorie di performance più facili, perché molti siti distribuiscono più file di font di quanti ne usino.

INP: la pagina risponde quando viene toccata?

Interaction to Next Paint misura la reattività. Più precisamente, osserva il ritardo tra un’interazione dell’utente e il successivo aggiornamento visivo dopo che il browser ha elaborato quell’interazione.

Le interazioni includono cose come:

• cliccare un pulsante,
• toccare un menu,
• selezionare una checkbox,
• digitare in un campo di form,
• aprire un accordion.

INP ha sostituito First Input Delay come Core Web Vital nel 2024. È stato un buon cambiamento. First Input Delay guardava solo alla prima interazione. INP è più ampio: considera le interazioni durante l’intera visita alla pagina e riporta un’interazione ad alta latenza come punteggio di reattività della pagina.

In parole semplici: INP intercetta le pagine che sembrano caricate ma danno la sensazione di essere bloccate.

Probabilmente hai già usato una pagina così. Sembra pronta. Tocchi il menu. Non succede nulla per mezzo secondo. Tocchi di nuovo. Poi accadono due cose insieme. Questo è un problema di INP.

Cause comuni di un INP scarso

INP è di solito un problema del main thread. Il browser vuole rispondere, ma JavaScript, lavoro di rendering o calcoli di layout sono d’intralcio.

Le cause tipiche includono:

• bundle JavaScript grandi,
• event handler costosi,
• lavoro di hydration nelle app renderizzate lato client,
• script di terze parti che competono per il main thread,
• task di lunga durata dopo il caricamento della pagina,
• aggiornamenti complessi del DOM attivati da piccole interazioni,
• layout thrashing, quando il codice legge e scrive ripetutamente valori di layout.

Tag di marketing, analytics, widget di chat e banner di consenso possono contribuire tutti. Questo non significa “rimuovere tutto”. Significa che ogni script sulla pagina ha un costo, e la latenza di interazione è spesso il punto in cui quel costo diventa visibile.

Come migliorare INP

Migliorare INP riguarda meno un attributo magico e più la riduzione della contesa sul main thread.

Approcci utili includono:

• Suddividere i task JavaScript lunghi in parti più piccole.
• Rinviare il lavoro non essenziale finché la pagina non è utilizzabile.
• Rimuovere il JavaScript inutilizzato invece di limitarsi a minificarlo.
• Mantenere gli event handler piccoli e prevedibili.
• Evitare di ri-renderizzare grandi parti dell’interfaccia per piccoli cambiamenti di stato.
• Usare CSS per stati visivi semplici quando possibile.
• Verificare gli script di terze parti e caricarli solo dove servono.

Osserva anche il design dell’interazione. Un pulsante che offre feedback visivo immediato può sembrare più reattivo, anche se il lavoro successivo richiede più tempo. Non è un sostituto della performance, ma fa parte di una buona ingegneria dell’interfaccia. La nostra checklist per pulsanti web accessibili si sovrappone a questo: stati chiari, semantica corretta e comportamento prevedibile aiutano sia gli utenti sia i browser.

CLS: la pagina resta dove l’utente si aspetta?

Cumulative Layout Shift misura il movimento inatteso degli elementi visibili. Se un utente inizia a leggere un paragrafo e un annuncio, un’immagine o un banner si carica sopra di esso, spingendo il testo verso il basso, questo contribuisce al CLS.

CLS non si misura in secondi. È un punteggio basato su quanto contenuto si è spostato e su quanto lontano si è spostato. Più basso è meglio.

La parola chiave è inatteso. I cambiamenti di layout causati da un’azione dell’utente di solito non vengono conteggiati nello stesso modo. Se qualcuno tocca “mostra altro” e il contenuto si espande, è previsto. Se un banner newsletter appare in alto dopo tre secondi e spinge tutto verso il basso, non lo è.

Cause comuni di un CLS scarso

I problemi di CLS sono spesso banali:

• immagini senza attributi width e height,
• annunci o embed senza spazio riservato,
• cookie banner inseriti sopra il contenuto,
• web font che vengono sostituiti con metriche diverse,
• barre promozionali caricate in ritardo,
• contenuto inserito dinamicamente vicino alla parte alta della pagina.

La soluzione di solito è riservare spazio prima che il contenuto arrivi. Il browser dovrebbe conoscere la forma della pagina il prima possibile.

Come migliorare CLS

Parti dagli spostamenti visibili. Guarda una registrazione o usa gli strumenti del browser per identificare quali elementi si muovono.

Poi applica le soluzioni noiose:

• Aggiungi attributi espliciti width e height alle immagini.
• Usa CSS aspect-ratio per i contenitori media responsive.
• Riserva uno spazio fisso o minimo per annunci, embed e iframes.
• Evita di inserire banner sopra contenuti esistenti dopo il caricamento.
• Scegli font fallback con metriche simili al font finale.
• Evita animazioni che cambiano proprietà di layout come top, left, width o height; preferisci le transform.

CLS è una delle poche metriche di performance in cui la disciplina batte l’ingegno. Se la pagina ha riquadri stabili, tende ad avere un buon punteggio.

Field data e lab data sono entrambi utili, ma rispondono a domande diverse

Una fonte comune di confusione è che strumenti diversi mostrano numeri diversi. È normale.

Field data provengono da utenti reali. Riflettono dispositivi, reti, posizioni geografiche e condizioni del browser reali. Il Chrome User Experience Report di Google è un esempio di field data.

Lab data provengono da un ambiente di test controllato. Lighthouse è l’esempio più familiare. È ripetibile e utile per il debug, ma non è la stessa cosa dell’esperienza vissuta dai tuoi utenti.

Usa i field data per capire se gli utenti hanno un problema reale. Usa i lab data per riprodurre e analizzare quel problema.

Ricorda anche che i Core Web Vitals vengono di solito valutati per URL o gruppo di URL, non come una proprietà astratta unica del tuo brand. La home page, un articolo del blog, la pagina prezzi e il checkout possono avere colli di bottiglia molto diversi.

Un ordine di lavoro sensato

Se tutte e tre le metriche sono scarse, la tentazione è iniziare ovunque. Resistila.

Un ordine pratico è:

1. Correggi prima i problemi CLS evidenti

Dimensioni mancanti delle immagini e banner instabili sono spesso vittorie rapide.

1. Migliora LCP per i template importanti

Concentrati sulle pagine che contano: pagine prodotto, landing page, articoli, flussi di iscrizione.

1. Indaga INP con interazioni reali

Clicca ciò che gli utenti cliccano davvero. Menu, filtri, form e controlli del checkout spesso rivelano più della traccia di caricamento iniziale.

1. Verifica gli script di terze parti

Mantieni quelli che giustificano il loro costo. Rimuovi o ritarda quelli che non lo fanno.

1. Imposta un performance budget

Senza un budget, i miglioramenti di performance si deteriorano. Nuovi script, immagini e componenti di design annulleranno silenziosamente il lavoro.

Il punto importante: non ottimizzare per un badge. Ottimizza per il percorso dell’utente. Un miglioramento marginale del punteggio su una pagina a basso traffico può contare meno di un’interazione di checkout leggermente imperfetta ma molto più veloce.

<!-- tool-cta:start -->

💡 Prova questo: Poiché l'LCP è di solito un problema legato alle immagini, riduci le dimensioni della tua risorsa hero con Image Compressor come prima vittoria facile.

<!-- tool-cta:end -->

Cosa non ti dicono i Core Web Vitals

I Core Web Vitals sono utili, ma incompleti.

Non ti dicono se il tuo contenuto è buono. Non ti dicono se la tua navigazione ha senso. Non garantiscono l’accessibilità. Non misurano privacy, sicurezza, fiducia, leggibilità o se la pagina risponde alla domanda dell’utente.

Inoltre non sostituiscono il giudizio. Una pagina può superare i Core Web Vitals ed essere comunque sgradevole. Un’applicazione complessa può non raggiungere una soglia pur essendo progettata in modo responsabile rispetto ai suoi vincoli.

Tratta LCP, INP e CLS come rilevatori di fumo. Quando suonano, indaga. Quando sono silenziosi, continua a mantenere l’edificio.