I core web vitals sono metriche con cui Google valuta caricamento percepito, reattività dell’interfaccia e stabilità visiva di una pagina nelle visite reali. Servono a capire se un sito offre una page experience solida, a individuare colli di bottiglia tecnici e a verificare l’effetto di interventi su immagini, JavaScript, cache, CDN e layout. La misurazione entra in gioco durante audit tecnici, redesign, migrazioni, cambi di tema o plugin e controlli periodici in Search Console o PageSpeed Insights.
Core Web Vitals: definizione, ambito e metriche incluse
Google considera i core web vitals un sottoinsieme dei Web Vitals. Il set attuale copre tre aspetti dell’esperienza utente, caricamento, interattività e stabilità visiva. La valutazione viene letta sul 75° percentile dei caricamenti, separando mobile e desktop, così il giudizio non dipende da un singolo test isolato ma dal comportamento ricorrente della pagina.
Cosa misurano i Core Web Vitals
I Core Web Vitals misurano il tempo con cui compare il contenuto principale, il ritardo con cui la pagina restituisce un feedback visivo dopo un’azione e la quantità di spostamenti inattesi del layout. Queste metriche descrivono una visita reale: il visitatore deve vedere presto l’elemento dominante, interagire senza attese marcate e leggere o cliccare senza salti della pagina.
Differenza tra Web Vitals e Core Web Vitals
Web Vitals è una famiglia più ampia di metriche. Core Web Vitals indica invece il gruppo di indicatori che Google considera stabili e da monitorare con continuità. Secondo la metodologia con cui Google ha definito metriche e soglie dei Core Web Vitals, il gruppo attuale comprende LCP, INP e CLS, mentre segnali come FCP, TTFB o TBT restano metriche di supporto alla diagnosi e non rientrano nel set principale.
LCP, INP e CLS nella documentazione Google attuale
Nella documentazione Google aggiornata, LCP misura la velocità di caricamento percepita, INP misura la reattività dell’interfaccia e CLS misura la stabilità visiva. La combinazione di queste tre metriche permette di osservare i momenti che il visitatore percepisce con più chiarezza durante la visita, cioè la comparsa del contenuto dominante, la risposta ai click o tocchi e l’assenza di spostamenti del layout.
Largest Contentful Paint
Il Largest Contentful Paint, abbreviato in LCP, registra il momento in cui viene renderizzato l’elemento più grande visibile nell’area iniziale della pagina. I candidati possono essere immagini, poster video o blocchi di testo di grandi dimensioni. In una home page, l’elemento LCP coincide spesso con hero image, titolo principale o sezione di apertura sopra la piega.
Interaction to Next Paint
L’Interaction to Next Paint, abbreviato in INP, osserva la latenza delle interazioni compiute durante la visita e restituisce un valore rappresentativo dell’interazione più lenta, escludendo in alcuni casi gli outlier. Il dato descrive il tempo che intercorre tra input dell’utente e aggiornamento visivo successivo, quindi riflette con precisione la reattività percepita della pagina.
Cumulative Layout Shift
Il Cumulative Layout Shift, abbreviato in CLS, quantifica gli spostamenti imprevisti degli elementi visibili. Il valore cresce quando testo, immagini, banner, annunci o iframe cambiano posizione dopo il primo rendering. L’effetto è noto a chi legge un contenuto e perde il punto, oppure a chi prova a cliccare un pulsante che si sposta un attimo prima dell’azione.
Da FID a INP: evoluzione della metrica di interattività
First Input Delay misurava solo il ritardo del primo input. Questa logica lasciava fuori molte interazioni successive, spesso più lente della prima in siti con JavaScript pesante. Con il passaggio ufficiale da FID a INP avvenuto il 12 marzo 2024, Google ha adottato una metrica che osserva l’intero ciclo delle interazioni e descrive meglio il comportamento reale dell’interfaccia.
Core Web Vitals, Page Experience e segnali SEO
I Core Web Vitals rientrano nella valutazione della Page Experience, ma la Page Experience non si esaurisce in queste tre metriche. Google collega il tema a ranking, HTTPS, leggibilità su mobile e assenza di overlay invasivi. In ambito SEO, l’incidenza dei vitals si nota soprattutto quando più pagine offrono una risposta simile e una di queste garantisce una visita più fluida.
Relazione tra esperienza pagina e ranking
In base a come Google descrive il rapporto tra Page Experience e ranking, i Core Web Vitals concorrono alla valutazione dell’esperienza sulle pagine insieme ad altri segnali. Lo stesso contenuto precisa che buoni risultati nei report non garantiscono le prime posizioni, perché la pertinenza resta il criterio prevalente.
Quanto incidono i Core Web Vitals nella SERP
I Google Core Web Vitals incidono come segnale aggiuntivo. Un contenuto molto pertinente può mantenere una buona visibilità anche con margini tecnici da correggere, mentre pagine simili sul piano informativo possono differenziarsi anche per qualità della visita. Nei progetti SEO maturi, i vitals hanno spesso un impatto concreto su bounce rate, profondità di navigazione e stabilità delle performance organiche.
Segnali collegati: mobile, HTTPS, interstitial
Google collega l’esperienza sulle pagine anche a sicurezza e accessibilità del contenuto. Il report HTTPS di Search Console sul numero di URL indicizzati in HTTP e in HTTPS aiuta a verificare la copertura della versione sicura del sito, mentre le indicazioni di Google su come evitare interstitial e finestre di dialogo che ostacolano il contenuto principale invitano a preferire banner che non coprano la parte iniziale della pagina.
- Una pagina mobile friendly deve offrire contenuti accessibili e leggibili anche su schermi piccoli.
- Una configurazione HTTPS corretta riduce problemi di indicizzazione della versione sicura.
- Popup, sticky bar e interstitial a schermo pieno possono peggiorare esperienza pagina e stabilità visiva.
Come funzionano LCP, INP e CLS
Le tre metriche osservano momenti diversi della visita. LCP fotografa la comparsa del contenuto dominante, INP misura il ritardo con cui il browser aggiorna l’interfaccia dopo un input, CLS somma gli spostamenti di layout inattesi. Le soglie ufficiali sono stabili e permettono di tradurre un problema tecnico in una valutazione misurabile, utile nei controlli periodici e nelle priorità di sviluppo.
| Metrica | Aspetto osservato | Buono | Richiede miglioramenti | Scadente |
|---|---|---|---|---|
| LCP | Caricamento percepito | ≤ 2,5 s | > 2,5 s e ≤ 4 s | > 4 s |
| INP | Reattività dell’interfaccia | ≤ 200 ms | > 200 ms e ≤ 500 ms | > 500 ms |
| CLS | Stabilità visiva | ≤ 0,1 | > 0,1 e ≤ 0,25 | > 0,25 |
LCP e velocità di caricamento percepita
LCP descrive il momento in cui il visitatore vede l’elemento che domina il primo viewport. Una pagina può mostrare presto un frammento di testo e avere comunque un LCP alto se l’immagine hero, il titolo o il blocco principale arrivano tardi. Per questo il valore LCP è più vicino alla percezione del caricamento rispetto a metriche che segnalano solo il primo contenuto comparso.
Elemento principale in viewport
L’elemento principale in viewport è il candidato LCP più grande che il browser considera visibile nella schermata iniziale. In una scheda prodotto, il ruolo può spettare all’immagine del prodotto. In una landing page può coincidere con H1 e sottotitolo. In un articolo può essere l’immagine iniziale o il titolo, secondo dimensioni e posizione effettive del contenuto renderizzato.
Soglie di valutazione LCP
Le soglie ufficiali, riportate nel Report Core Web Vitals di Search Console, classificano LCP come buono fino a 2,5 secondi, da migliorare oltre 2,5 e fino a 4 secondi, scadente oltre 4 secondi. Il criterio viene calcolato sul 75° percentile delle visite reali, quindi riflette il comportamento ricorrente e non il test di un singolo caricamento.
INP e reattività dell’interfaccia
INP misura il tempo che separa un’azione dell’utente dalla visualizzazione del frame successivo che conferma la risposta dell’interfaccia. Il valore cresce quando click, tap o pressioni da tastiera entrano in coda dietro task lunghi del thread principale, ricalcoli di layout, script di terze parti o aggiornamenti grafici pesanti. Il risultato è una pagina che appare pronta ma reagisce con lentezza.
Interazione utente e aggiornamento visivo
Secondo la descrizione tecnica di ottimizzazione dell’INP, l’interazione comprende ritardo di input, tempo di elaborazione e ritardo di presentazione del frame. Se il browser riceve il click ma resta occupato in JavaScript, la risposta visiva arriva tardi. Lo stesso accade quando l’evento è gestito in fretta ma il rendering successivo richiede troppo lavoro.
Soglie di valutazione INP
Le soglie ufficiali indicano un INP buono fino a 200 millisecondi, da migliorare oltre 200 e fino a 500 millisecondi, scadente oltre 500 millisecondi. La panoramica del riquadro Rendimento di Chrome DevTools con le metriche osservabili durante l’analisi della pagina mostra inoltre che INP può essere rilevato in tempo reale durante l’interazione, insieme a LCP e CLS locali.
CLS e stabilità visiva
CLS misura quanto la pagina resta stabile durante caricamento e interazione. Il problema si manifesta quando il contenuto salta verso il basso, un pulsante cambia posizione appena prima del click o un iframe apre spazio in ritardo. L’effetto non dipende da una sensazione generica di lentezza, ma da un comportamento preciso del layout che altera la posizione di elementi già visibili.
Spostamenti di layout
Uno spostamento di layout si verifica quando un elemento visibile cambia posizione tra due frame. Se il testo viene spinto più in basso da un banner comparso in ritardo, oppure da un’immagine priva di dimensioni dichiarate, la pagina accumula punteggio CLS. I casi più frequenti riguardano immagini senza misure, embed, annunci, popup e componenti caricati in ritardo rispetto al flusso del documento.
Formula di calcolo del CLS
La formula ufficiale del CLS è riportata nella documentazione tecnica come layout shift score = impact fraction * distance fraction. La prima componente misura quanta area visibile è coinvolta, la seconda quanto lontano si sposta l’elemento rispetto alla dimensione maggiore del viewport. In questo modo un piccolo movimento di un blocco molto grande può pesare quanto un ampio movimento di un elemento più piccolo.
Soglie di valutazione CLS
Un CLS è buono fino a 0,1, richiede miglioramenti oltre 0,1 e fino a 0,25, diventa scadente oltre 0,25. L’approfondimento di web.dev sulle differenze tra dati di laboratorio e dati di campo nella misurazione dei Web Vitals ricorda anche che i report sul campo leggono queste soglie sul 75° percentile, quindi la distribuzione delle visite incide più del singolo test locale.
Come misurare i Core Web Vitals
La misurazione affidabile combina dati di campo e dati di laboratorio. I dati di campo descrivono l’esperienza reale di utenti e dispositivi diversi. I dati di laboratorio riproducono il caricamento in un ambiente controllato, quindi aiutano a localizzare risorse lente, task lunghi e regressioni. Il metodo più solido usa Search Console per il monitoraggio, PageSpeed Insights per il confronto e DevTools o Lighthouse per la diagnosi tecnica.
Dati di campo e dati di laboratorio
Il confronto tra dati CrUX e test Lighthouse in PageSpeed Insights chiarisce la differenza: CrUX raccoglie esperienze utente reali sul campo, Lighthouse esegue un test controllato in laboratorio. I primi descrivono reti, dispositivi e geografie effettive, i secondi permettono di riprodurre il problema e individuare il punto del codice su cui intervenire.
Search Console e report per URL o gruppi di URL
Search Console non mostra solo singoli URL, ma raggruppa le pagine simili per stato, metrica e gruppo di URL. Nel report Core Web Vitals, le prestazioni vengono classificate come Buone, Richiedono miglioramenti o Scadenti e il campione riguarda solo URL indicizzati. Questa lettura aiuta a capire se il problema appartiene a un template e non a una sola pagina isolata.
PageSpeed Insights e Lighthouse
PageSpeed Insights unisce dati sul campo e dati di laboratorio nello stesso report, mentre Lighthouse resta uno strumento di audit sintetico pensato per controllare prestazioni, accessibilità, SEO e altri aspetti tecnici. Questa combinazione permette di leggere da un lato il comportamento reale della pagina, dall’altro le cause che possono spiegare un LCP alto, un INP lento o un CLS instabile.
Chrome UX Report e strumenti Chrome
Il Chrome UX Report e gli strumenti inclusi in Chrome permettono di scendere dal dato aggregato alla causa tecnica. Il dataset mostra l’esperienza degli utenti reali di Chrome, mentre DevTools consente di analizzare rendering, interazioni, rete e spostamenti del layout. Questa doppia lettura è preziosa quando il sito presenta discrepanze tra punteggi locali e comportamento osservato sul campo.
CrUX
Il dataset CrUX basato su dati reali di navigazione raccoglie informazioni provenienti da utenti Chrome e restituisce una lettura sul campo delle prestazioni delle pagine web. Questo insieme di dati alimenta anche una parte delle misurazioni usate per i Web Vitals. Le informazioni possono essere disponibili a livello di origine e, quando il volume è sufficiente, anche a livello di singola pagina.
Chrome DevTools
Il monitoraggio di LCP, INP e CLS nel pannello Prestazioni di Chrome DevTools include anche cronologia delle interazioni, cluster di layout shift e confronto con i dati di campo di CrUX quando disponibili. Per analizzare un problema riproducibile, DevTools consente di individuare con precisione la causa tecnica che rallenta o destabilizza la pagina.
Come migliorare LCP, INP e CLS
Ogni metrica richiede interventi diversi. Un LCP alto richiama immagine hero, tempo di risposta del server, cache, CDN e risorse render blocking. Un INP alto richiama JavaScript, thread principale e script di terze parti. Un CLS alto richiama dimensioni mancanti, contenuti embedded, advertising e popup. Correggere la causa giusta è molto più produttivo di un’ottimizzazione generica del front end.
Interventi su LCP
La scomposizione del Largest Contentful Paint nelle sue principali cause tecniche distingue tra TTFB, ritardo nel caricamento della risorsa, durata del download e ritardo di rendering. Questa lettura aiuta a capire se il problema dipende dal server, dalla scoperta tardiva della risorsa LCP, dalla sua priorità di caricamento oppure da un rendering che arriva troppo tardi anche quando il file è già disponibile.
Ottimizzazione immagini e video
Se l’elemento LCP è un’immagine o un poster video, il file deve avere peso coerente, dimensioni adeguate al viewport e priorità alta nel caricamento. Una hero image caricata in ritardo dietro a script secondari produce quasi sempre un LCP alto. Anche l’uso del lazy loading sull’elemento principale tende a peggiorare la metrica, perché ritarda la richiesta della risorsa che il visitatore deve vedere subito.
Riduzione delle risorse above the fold
Nella diagnosi del LCP, un segnale ricorrente è la presenza di fogli di stile o script sincroni che bloccano il rendering del contenuto iniziale. La documentazione sulle azioni più efficaci per migliorare i Core Web Vitals richiama proprio la necessità di rendere rilevabile e prioritaria la risorsa LCP e di ridurre il lavoro che ritarda il primo viewport.
CDN, cache e tempi di risposta del server
Un TTFB elevato rende difficile raggiungere un LCP entro 2,5 secondi. Cache HTML, server più vicini al visitatore tramite CDN, meno redirect e meno dipendenza da query dinamiche sul primo documento riducono il ritardo iniziale. Quando il server consegna tardi il primo byte, anche una pagina con front end ordinato parte già in svantaggio.
Interventi su INP
INP migliora quando il browser resta libero di gestire input, callback e rendering in tempi brevi. L’obiettivo non è solo ridurre un singolo file JavaScript, ma abbassare il carico complessivo del thread principale nei momenti in cui l’utente prova a interagire. Menu, filtri, modali, autocomplete e widget esterni sono spesso i punti in cui la reattività degrada in modo più evidente.
Riduzione JavaScript e script di terze parti
La raccolta di indicazioni su come migliorare INP evidenzia che le attività superiori a 50 millisecondi bloccano il thread principale e ritardano la risposta alle interazioni. Bundle voluminosi, tag manager sovraccarichi, chat, widget di recensioni, script di tracciamento e personalizzazioni in eccesso sono tra i responsabili più frequenti di click che reagiscono tardi.
Priorità di rendering e pagine statiche
Le pagine con molto rendering lato client tendono a soffrire di più sulla reattività, soprattutto su dispositivi medi o connessioni deboli. Per landing page, pagine istituzionali e contenuti editoriali, markup più lineare, output statico e idratazione limitata delle sole aree interattive riducono il carico del thread principale e migliorano la risposta del browser ai gesti dell’utente.
Interventi su CLS
CLS migliora quando ogni elemento riceve uno spazio prevedibile prima del caricamento definitivo. Il problema nasce spesso da contenuti introdotti dopo il layout iniziale, da componenti pubblicitari che aprono spazio in ritardo o da media senza misure esplicite. Il browser deve poter calcolare il layout prima possibile, così il documento rimane stabile durante caricamento e interazione.
Attributi width e height
Le indicazioni per evitare immagini prive di dimensioni dichiarate consigliano di inserire sempre gli attributi width e height su immagini e video. In questo modo il browser può riservare subito lo spazio corretto nel layout. L’effetto si nota soprattutto in homepage, articoli e schede prodotto con immagini grandi visibili nel primo viewport.
Aspect ratio, iframe e contenuti embedded
L’aspect ratio aiuta a riservare spazio anche quando il contenuto è responsivo. Lo stesso principio vale per iframe video, mappe, moduli esterni e widget che arrivano dopo il primo markup. Se il contenitore non ha una dimensione prevista, il browser ricalcola la posizione degli elementi vicini e il punteggio CLS cresce. L’assegnazione preventiva dello spazio riduce in modo netto questo comportamento.
Popup, banner e advertising
Popup promozionali, cookie banner, sticky bar e slot advertising generano instabilità quando compaiono sopra il contenuto e spingono verso il basso ciò che era già visibile. La soluzione più pulita è riservare spazio nel layout oppure usare overlay che non alterino il flusso del documento. Anche la posizione di comparsa conta: un banner introdotto a pagina già letta crea più frizione di uno previsto dall’inizio.
Metriche correlate da usare in diagnosi tecnica
Le metriche correlate non sostituiscono i Core Web Vitals, ma aiutano a capire da dove nasce il problema. FCP descrive il primo contenuto mostrato, TBT il tempo di blocco del thread principale, TTI il momento in cui la pagina diventa interattiva in laboratorio, TTFB il tempo che intercorre prima della risposta iniziale del server. Letti insieme, questi segnali rendono la diagnosi più precisa.
FCP, TBT, TTI e TTFB
Il First Contentful Paint misura il primo contenuto visibile. Il Total Blocking Time somma la parte di blocco delle attività lunghe tra FCP e interattività. Il Time to Interactive segnala quando la pagina diventa completamente interattiva in laboratorio. Il Time to First Byte misura il tempo fino ai primi byte del documento HTML.
Quando queste metriche segnalano un problema sui Core Web Vitals
Un FCP rapido con LCP alto indica che la pagina mostra presto qualcosa, ma non il contenuto dominante. Un TBT alto anticipa spesso un INP lento, perché il thread principale resta occupato da task lunghi. Un TTI molto tardivo segnala una pagina che appare pronta prima di poter rispondere bene. Un TTFB alto, infine, rallenta l’intera catena di caricamento e rende più arduo portare LCP in area buona.
- FCP basso e LCP alto, il primo contenuto compare presto ma l’elemento principale arriva tardi.
- TBT alto e INP alto, il thread principale è troppo occupato durante le interazioni.
- TTFB alto e LCP alto, il ritardo parte dal server prima ancora del rendering.
Core Web Vitals su WordPress
Su WordPress, i problemi di Core Web Vitals derivano spesso dalla combinazione tra tema, page builder, plugin, media e infrastruttura server. La piattaforma permette risultati molto buoni, ma i margini si riducono quando il primo viewport viene riempito di slider, video, feed esterni, script marketing e componenti caricati globalmente su tutte le pagine.
Temi, plugin e aggiornamenti che influenzano le metriche
Tema, builder e plugin determinano quantità di DOM, CSS, JavaScript e richieste di rete. Un aggiornamento può cambiare il caricamento del menu, introdurre librerie nuove, spostare risorse nel head o alterare i comportamenti del lazy loading. Per questo le verifiche sui vitals vanno ripetute dopo aggiornamenti di tema, plugin, moduli di consenso, strumenti di tracking e integrazioni commerciali.
Cache, CDN e ottimizzazione media
Su WordPress, page cache, object cache, CDN per asset statici e immagini correttamente ridimensionate incidono soprattutto su TTFB e LCP. L’ottimizzazione media richiede formati moderni, peso coerente e una distinzione chiara tra contenuti above the fold e contenuti secondari. Se il primo viewport dipende da immagini troppo grandi o richieste dinamiche non cacheabili, le soglie di LCP si allontanano rapidamente.
Errori frequenti su homepage, slider, video e popup
Le criticità più comuni riguardano homepage costruite con componenti scenografici ma pesanti. Slider multipli, video hero autoplay, popup di lead generation, widget di recensioni, banner sticky e script di terze parti caricati all’avvio rallentano il contenuto iniziale o spostano il layout. La misurazione va eseguita sul template reale pubblicato, perché le versioni di staging leggere raramente riflettono la complessità della produzione.
