Core Web Vitals spiegati: LCP, INP e CLS

I Core Web Vitals sono tre metriche con cui Google descrive l'esperienza degli utenti reali: Largest Contentful Paint (LCP) per il caricamento, Interaction to Next Paint (INP) per la reattività e Cumulative Layout Shift (CLS) per la stabilità visiva. Una pagina supera la valutazione quando almeno il 75% delle visite raggiunge un LCP di 2,5 secondi o meno, un INP di 200 millisecondi o meno e un CLS di 0,1 o meno. Questa guida spiega cosa misura ogni metrica, come leggere i tuoi punteggi e quali interventi di solito li migliorano.

Le tre metriche in breve

Google pubblica soglie fisse per ogni metrica e raggruppa i risultati in tre fasce. I valori qui sotto vengono dalla panoramica di web.dev sui Core Web Vitals.

Due dettagli contano più di quanto la maggior parte delle persone immagini:

• Decide il 75° percentile. Google non guarda la tua visita più veloce né quella media. Prende il valore che il 75% dei caricamenti di pagina raggiunge o migliora, separatamente per mobile e desktop. Bastano quindi alcuni telefoni lenti su connessioni deboli per far scivolare una pagina in "da migliorare".
• INP ha sostituito FID a marzo 2024. Il First Input Delay misurava solo il ritardo prima che venisse gestita la prima interazione. INP considera la latenza delle interazioni durante tutta la visita, un test molto più severo per le pagine ricche di JavaScript.

Dati sul campo e dati di laboratorio

Quando analizzi una pagina su corewebvitals.page, vedi due tipi di risultati, e spesso non coincidono.

• I dati sul campo ("Discover what your real users are experiencing") provengono dal Chrome User Experience Report. Riguardano utenti reali di Chrome in una finestra mobile di 28 giorni. Sono questi a contare per la valutazione dei Core Web Vitals in Search Console.
• I dati di laboratorio (il punteggio Lighthouse) sono un singolo caricamento simulato su un dispositivo rallentato. Sono ottimi per il debug perché ripetibili, ma non possono misurare l'INP, dato che durante il test nessuno clicca. Lighthouse usa il Total Blocking Time come sostituto approssimativo.

Poiché i dati sul campo arrivano con un ritardo fino a 28 giorni, un intervento che pubblichi oggi si vedrà gradualmente. Usa i test di laboratorio per confermare che la modifica funziona, poi osserva come si assestano i numeri sul campo. La nostra guida su come misurare correttamente la velocità di un sito ti accompagna in un test prima e dopo affidabile.

Come migliorare l'LCP

L'LCP è spesso la più difficile delle tre da superare, ma di solito è la più facile da diagnosticare. Google lo divide in quattro parti, descritte nell'articolo di web.dev sull'LCP:

1. Time to First Byte: quanto tempo impiega il server a iniziare a inviare l'HTML.
2. Ritardo di caricamento della risorsa: l'intervallo tra il primo byte e il momento in cui il browser inizia a caricare l'immagine LCP.
3. Durata del caricamento della risorsa: quanto impiega l'immagine LCP stessa a essere scaricata.
4. Ritardo di rendering dell'elemento: il tempo tra l'arrivo dell'immagine e il momento in cui viene effettivamente disegnata.

Guarda quale parte domina prima di cambiare qualcosa. Il pannello Performance di Chrome DevTools mostra l'elemento LCP e come si suddivide il suo tempo.

Risposta lenta del server

Se il solo TTFB si mangia un secondo o più, nessuna ottimizzazione delle immagini ti porterà sotto i 2,5 secondi. Le cause più comuni sono pagine non in cache generate da PHP e database a ogni richiesta, un server lontano dalla maggior parte dei visitatori e plugin o estensioni lenti. La soluzione abituale è la cache di pagina, sul server o sull'edge. Trovi l'elenco completo nella guida su come ridurre il TTFB.

L'immagine LCP viene scoperta tardi

I browser trovano le immagini mentre analizzano l'HTML. Se la tua immagine hero è impostata come sfondo CSS, inserita da JavaScript o caricata in lazy loading, il browser la scopre tardi. Le soluzioni:

• Usa un normale elemento <img> per l'immagine hero.
• Non aggiungere mai loading="lazy" all'immagine LCP.
• Aggiungi fetchpriority="high" o un preload, così il browser la scarica presto:

<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">

L'immagine LCP è troppo pesante

Un JPEG largo 3000 pixel mostrato a 1200 pixel spreca banda a ogni visita. Servi formati moderni come WebP o AVIF, dimensiona l'immagine in base al layout e usa srcset per i diversi schermi. La nostra guida su come ottimizzare le immagini per il web lo spiega nel dettaglio.

CSS e font che bloccano il rendering

Fogli di stile grandi e script sincroni nell'<head> ritardano la visualizzazione anche quando l'immagine è già pronta. Inserisci inline il CSS critico, rimanda gli script non essenziali e mantieni leggeri i web font.

Come migliorare l'INP

L'INP misura il tempo che passa da un'interazione dell'utente al frame successivo disegnato dal browser. È quasi sempre un problema di JavaScript, non di rete. L'articolo di web.dev sull'INP lo scompone in ritardo di input, tempo di elaborazione e ritardo di presentazione.

Cause tipiche e soluzioni:

• Task lunghi sul main thread. Qualsiasi script che gira per più di 50 ms impedisce alla pagina di rispondere. Spezza i lavori lunghi in blocchi più piccoli e restituisci il controllo al browser tra un blocco e l'altro.
• Troppo JavaScript di terze parti. Widget di chat, tag manager, strumenti di A/B testing e script pubblicitari competono tutti per il main thread. Controlla cosa viene caricato e togli quello che non usa nessuno.
• Gestori di eventi pesanti. Un clic che scatena un grande aggiornamento del DOM, il nuovo rendering di un intero elenco prodotti o letture sincrone del layout risulterà lento. Aggiorna solo ciò che è cambiato e mostra subito un riscontro visivo prima di fare il lavoro costoso.
• DOM enorme. Le pagine con molte migliaia di elementi impiegano più tempo a ricalcolare stili e layout dopo ogni interazione. I page builder ne sono una fonte frequente.

Un CDN o una cache aiutano l'INP solo indirettamente: meno tempo speso a scaricare significa script pronti prima, ma il codice deve comunque girare sul dispositivo del visitatore.

Come migliorare il CLS

Il CLS assegna un punteggio al gruppo più grande di spostamenti inattesi del layout mentre la pagina è aperta. Gli spostamenti che avvengono entro 500 ms da un'interazione dell'utente non contano, quindi una fisarmonica che si apre dopo un clic va bene. L'articolo di web.dev sul CLS spiega come si calcola il punteggio.

I soliti sospettati:

• Immagini e video senza dimensioni. Senza gli attributi width e height (o un aspect-ratio in CSS), il browser non riserva spazio e spinge in basso il contenuto quando arriva il file.
• Pubblicità, embed e banner inseriti sopra i contenuti. Riserva loro uno spazio fisso, oppure mettili sotto la piega.
• Banner dei cookie che spostano la pagina. Mostrali in sovrimpressione invece di inserirli in cima al documento.
• Web font che subentrano. Quando il font di riserva viene sostituito dal web font, il testo può riorganizzarsi. font-display: swap mantiene il testo visibile fin da subito; allineare le metriche del font di riserva (per esempio con size-adjust) evita che lo scambio sposti gli elementi.

I Core Web Vitals influiscono sul posizionamento?

I Core Web Vitals fanno parte dei segnali di esperienza sulla pagina di Google. Google afferma che i suoi sistemi di ranking premiano una buona esperienza sulla pagina, ma anche che pertinenza e qualità dei contenuti vengono prima. In pratica, superare i Core Web Vitals non porterà in cima una pagina debole, e non superarli non affonderà una pagina che è chiaramente la risposta migliore.

Il motivo migliore per occupartene sono i tuoi visitatori. Caricamenti lenti, pulsanti che rispondono in ritardo e layout che saltano ti costano richieste di contatto e vendite, qualunque cosa faccia l'algoritmo. Considera le soglie un livello di qualità per gli utenti, non un trucco SEO.

Come ti aiuta fast.site

fast.site si mette davanti al tuo hosting attuale, quindi mantieni il tuo provider e il tuo CMS. Punti i nameserver del dominio su fast.site e il traffico passa poi da una rete edge con regioni in Nord America, Europa, Asia-Pacifico e Sud America, a seconda del tuo piano.

Per l'LCP, Fast Edge Cache™ serve pagine e risorse in cache dall'edge più vicino al visitatore, così un cache HIT non aspetta il tuo server di origine. Questo agisce sulle parti TTFB e download dell'LCP. L'ottimizzazione delle immagini converte al volo JPEG e PNG in WebP per i browser che lo supportano, con AVIF disponibile a seconda del tuo piano.

L'opzione facoltativa di ottimizzazione HTML interviene direttamente su problemi comuni di LCP e CLS: precarica l'immagine hero rilevata, aggiunge larghezza e altezza alle immagini per ridurre gli spostamenti del layout e aggiunge font-display: swap ai web font. I dettagli sono nella documentazione sull'ottimizzazione HTML.

fast.site non può correggere JavaScript lento, quindi il lavoro sull'INP resta nel tuo codice. Misura prima e dopo sul tuo sito: l'header fs-cache mostra HIT, MISS o BYPASS, e le statistiche riportano TTFB e cache hit ratio. Puoi provare tutto questo con una prova gratuita di 7 giorni, senza carta di credito. Trovi i dettagli nella pagina dei piani.

Domande frequenti

Qual è un buon punteggio dei Core Web Vitals?

Una pagina supera la valutazione quando, al 75° percentile delle visite, l'LCP è di 2,5 secondi o meno, l'INP di 200 millisecondi o meno e il CLS di 0,1 o meno. Tutte e tre devono essere "buone" perché la valutazione sia superata. Mobile e desktop vengono valutati separatamente.

Perché il punteggio PageSpeed è buono ma Search Console dice che non supero la valutazione?

Il punteggio Lighthouse è un singolo test di laboratorio su un dispositivo simulato, mentre Search Console usa 28 giorni di dati di utenti reali di Chrome. I visitatori reali usano telefoni e reti più lenti del test, e i test di laboratorio non possono misurare l'INP. Per la valutazione fidati dei dati sul campo e usa il test di laboratorio per il debug.

Quanto tempo ci vuole per vedere i miglioramenti dei Core Web Vitals?

I dati sul campo coprono una finestra mobile di 28 giorni, quindi i miglioramenti compaiono gradualmente nell'arco di circa quattro settimane. Search Console può metterci un po' di più ad aggiornare i report. I test di laboratorio mostrano subito la modifica.

Un CDN migliora i Core Web Vitals?

Un CDN aiuta soprattutto l'LCP, riducendo il tempo di risposta del server e il tempo di download per i visitatori lontani dalla tua origine. Può ridurre indirettamente il CLS se offre ottimizzazioni HTML come l'aggiunta delle dimensioni delle immagini. L'INP dipende soprattutto dal JavaScript eseguito nel browser, quindi lì un CDN ha poco effetto diretto.

Cosa ha sostituito il First Input Delay (FID)?

Interaction to Next Paint (INP) ha sostituito FID come Core Web Vital a marzo 2024. L'INP considera le interazioni durante tutta la visita invece che solo la prima, e include il tempo necessario a disegnare il risultato.