Pubblicato il - Aggiornato il
Core Web Vitals: cosa sono e come migliorarli
SEO
Se una pagina ci mette troppo a caricare, scatta subito la sensazione che “qualcosa non vada”: è un problema di velocità, ma soprattutto di fiducia. I Core Web Vitals sono le metriche di Google che misurano quanto un sito è piacevole da usare nella vita reale, non solo “tecnicamente online”.
In pratica guardano tre aspetti chiave: quanto rapidamente compare il contenuto principale (LCP), quanto il sito risponde ai clic senza ritardi (INP) e quanto la pagina resta stabile senza spostare bottoni e testi (CLS). Capire questi indicatori ti aiuta a individuare cosa rallenta l’esperienza e a fare miglioramenti concreti che possono incidere su usabilità, conversioni e anche SEO.
Indice dei contenuti
Cosa sono i Core Web Vitals
I Core Web Vitals sono un set di metriche standard, fattori di ranking SEO, che Google usa per valutare la qualità dell’esperienza su una pagina, soprattutto da mobile. L’idea è semplice: non basta che il sito sia bello o ricco di contenuti, deve anche essere rapido, reattivo e stabile mentre l’utente lo usa. Queste misure nascono per essere confrontabili nel tempo e tra siti, quindi aiutano anche a ragionare per priorità.
Il punto dei Core Web Vitals è misurare ciò che l’utente percepisce: non “quando la pagina è tecnicamente caricata”, ma quando è davvero utilizzabile. Per questo le metriche si concentrano su tre momenti critici dell’esperienza: il contenuto principale che appare, l’interazione che risponde, e l’impaginazione che non si muove.
LCP (Largest Contentful Paint)
LCP (Largest Contentful Paint) indica quando viene renderizzato l’elemento più grande e significativo nella parte visibile (spesso un’immagine hero, un titolo, un blocco prodotto). Se il tuo LCP è alto, l’utente vede “vuoto” o uno scheletro per troppo tempo: è un problema di percezione di velocità, prima ancora che di tecnologia.
Consiglio: puoi precaricare l’immagine Largest Contentful Paint indicata su PageSpeed Insights in questo modo:
<link rel="preload" href="https://www.mirkociesco.it/wp-content/uploads/2020/10/core-web-vitals-mirko-ciesco.jpg.webp" as="image">INP (Interaction to Next Paint)
INP (Interaction to Next Paint) misura quanto il sito risponde bene alle azioni reali (tap, click, input). Qui la keyword è reattività: se clicchi “Aggiungi al carrello” e per qualche istante non succede nulla, quell’attrito si traduce facilmente in frustrazione e abbandono.
Consiglio: puoi ottimizzare l’Interaction to Next Paint aggiungendo defer o async nel seguente modo:
<script src="https://www.mirkociesco.it/wp-content/themes/webperformer/js/uikit-3.3.0/uikit-core.min.js" defer></script>CLS (Cumulative Layout Shift)
CLS (Cumulative Layout Shift) misura il livello di stabilità visiva di una pagina durante il caricamento: più un layout si sposta mentre l’utente lo osserva, più alto sarà il valore di CLS. Questo fenomeno può risultare frustrante, soprattutto quando i contenuti si spostano improvvisamente, rendendo difficile cliccare su pulsanti o leggere testi.
Consiglio: puoi evitare il Cumulative Layout Shift aggiungendo altezza e larghezza alle immagini e ai video, oltre all’attributo loading nel seguente modo:
<img loading="lazy" width="750" height="818" src="https://www.mirkociesco.it/wp-content/uploads/2020/10/core-web-vitals-pagespeed-insights.png.webp" alt="core web vitals pagespeed insights">Valori di riferimento per LCP, INP e CLS (e cosa significa 75° percentile)
Le soglie dei Core Web Vitals servono per tradurre un numero in una decisione: “va bene così” oppure “qui c’è un problema”. Google le definisce in tre fasce (buono / da migliorare / scarso) e le applica in modo coerente tra strumenti. La parte importante è saperle leggere senza farsi ingannare da medie, picchi o test isolati.
Le soglie più usate sono queste (valide come riferimento generale, soprattutto in ottica Google):
| Metrica | Buono | Da migliorare | Scarso |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Un dettaglio che fa la differenza: Google tende a guardare il 75° percentile. Vuol dire che non basta avere una buona media; l’obiettivo è che “almeno 3 utenti su 4” abbiano un’esperienza buona. È un approccio pragmatico: se una parte consistente del traffico sta male, vale la pena intervenire.
Altro punto pratico: spesso la realtà è mobile-first. Anche se da desktop i valori sono ottimi, basta che su smartphone (device più lenti, reti peggiori) i CWV siano in fascia “da migliorare” per avere un problema reale sia di UX sia di sostenibilità delle performance.
Perché i Core Web Vitals sono importanti per UX e SEO
Quando si parla di Core Web Vitals, la domanda pratica è: “mi serve davvero?” Se il sito ha obiettivi (lead, vendite, prenotazioni), la risposta è quasi sempre sì, perché queste metriche intercettano punti di frizione che impattano usabilità e conversioni. Importante sapere che SEO e UX non sono una bacchetta magica, ma aiutano a competere meglio quando la differenza di contenuti tra due risultati è minima.
Impatto sull’esperienza: fiducia, navigazione e conversioni
Un LCP lento comunica immediatamente che il sito “è pesante” o poco curato, anche se non è vero. In particolare sulle landing e sulle pagine prodotto, i primi secondi determinano la fiducia: se l’utente non vede subito ciò che cercava, torna indietro e prova un altro risultato.
Un INP alto crea invece micro-ritardi durante la navigazione: filtri che scattano tardi, menu che non rispondono, form che “laggano”. Non serve un blocco totale per perdere conversioni: basta quella sensazione di scarsa reattività che rende l’esperienza meno fluida, soprattutto da smartphone.
Il CLS è il più subdolo perché spesso “non si nota” in test interni, ma nel traffico reale provoca misclick e interazioni sbagliate. Il classico caso è il bottone che si sposta mentre l’utente sta per cliccare: l’effetto è un aumento di frizione che si vede poi nei KPI (drop nel funnel, minor completamento form, più rimbalzi).
Page Experience come segnale per Google
Google usa i Core Web Vitals dentro il concetto di Page Experience: non sostituiscono la qualità dei contenuti, ma contribuiscono a distinguere risultati simili quando la pertinenza è comparabile. In altre parole: se due pagine rispondono bene alla stessa query, quella con esperienza migliore ha un vantaggio potenziale.
È importante anche l’approccio mentale: i CWV non sono un “progetto una tantum”, ma un pezzo di performance management. Ogni nuova funzionalità, script di marketing, chat, widget, può spostare gli equilibri—e non sempre in meglio.
Infine, anche se l’obiettivo è la SEO, i benefici non restano confinati lì: migliorare reattività e stabilità aiuta pure su traffico da campagne e traffico diretto. La pagina diventa più “facile” da usare, e questo si riflette lungo tutto il funnel.
Come misurare i Core Web Vitals (field data vs lab data)
Misurare bene è metà del lavoro, perché ti evita di ottimizzare ciò che non conta. La regola pratica è: usa i field data per decidere dove intervenire (template, device, gruppi URL) e i lab test per capire come intervenire (risorsa, codice, layout). Tenere separati questi due piani ti dà metodo e riduce i falsi positivi.
Dati reali vs test di laboratorio: perché potresti vedere numeri diversi
Una delle prime cose che confonde è vedere valori diversi tra strumenti: è normale. Alcuni report si basano su dati di campo (utenti reali, con device e reti reali), altri su test “controllati” in un ambiente simulato. Entrambi sono utili, ma ris Considerali per ciò che sono: KPI vs diagnostica.
I dati reali arrivano dal Chrome User Experience Report (CrUX) e vengono aggregati su finestre temporali (tipicamente 28 giorni) e su tanti utenti diversi. Questo significa che riflettono davvero la qualità percepita, ma si muovono più lentamente: oggi sistemi un problema, e potresti vedere il miglioramento “stabilizzarsi” nelle settimane successive.
I test di laboratorio (per esempio su Pagespeed Insight) sono invece perfetti per fare debug: ripeti la prova, cambi una cosa, e vedi subito se il numero cambia. Il limite è che un test non può riprodurre tutta la varietà del mondo reale: device vecchi, 4G instabile, pagine visitate dalla cache, script di terze parti che entrano in gioco solo in certe condizioni.
CrUX e RUM
CrUX (Chrome UX Report) è la fonte principale dei field data usati da molti strumenti Google: ottimo per capire come va il sito “nel mondo reale”, ma è aggregato e aggiornato su finestre temporali. Per un lavoro continuo serve spesso affiancare un approccio RUM (Real User Monitoring): raccogliere dati dal tuo sito (ad esempio con la libreria web-vitals) e inviarli al tuo stack analytics per creare una dashboard e degli alert.
Con RUM puoi segmentare: device, connessione, pagine/templatе, funnel step, utenti nuovi vs di ritorno. È qui che i CWV diventano davvero un progetto “sostenibile”: definisci un performance budget (es. LCP p75 sotto 2,5s sulle pagine di ingresso principali, INP p75 sotto 200ms su PLP/PDP) e lo usi come guardrail per rilasci e nuove integrazioni.
Se lavori con GA4 e Data Studio, ha molto senso portare dentro anche queste metriche: non per “fare vanity reporting”, ma per collegare performance a conversioni e punti di drop del funnel.
Google Search Console: report “Segnali web principali”
In Search Console trovi il report Segnali web principali (Core Web Vitals) separato per mobile e desktop. Qui Google non ti parla della singola URL “isolata”, ma raggruppa pagine simili per pattern: è un indizio forte che il problema è legato a un template o a componenti condivisi.
Il report è uno strumento strategico per comprendere le priorità secondo Google: offre una visione chiara del numero di URL classificate come “scarse” o “da migliorare” e indica su quale metrica specifica (Largest Contentful Paint – LCP, Interaction to Next Paint – INP, Cumulative Layout Shift – CLS) è necessario intervenire. Il flusso di lavoro ottimale prevede di aprire un gruppo, selezionare 2–3 URL rappresentative e riprodurre i problemi in ambiente di test (lab).
Successivamente, si procede con l’ottimizzazione del template e l’applicazione delle modifiche, monitorando l’impatto delle correzioni sui Core Web Vitals per garantire un miglioramento sostenibile e misurabile nel tempo.
Screaming Frog
Puoi connettere le API di Google PageSpeed Insights con Screaming Frog e ottenere i punteggi di Lighthouse direttamente all’interno del software.
Per farlo è necessario configurare una chiave API nel proprio account di Google, inserirla nel tool, scegliere il dispositivo e le metriche che vuoi ottenere il report ed infine far partire la scansione del dominio da analizzare.
Data Studio
Puoi visualizzare il valore dei Core Web Vitals in Data Studio utilizzando i big data di Chrome UX Report (CrUX) partendo da un template già costruito. Qui puoi trovare un esempio.
Io utilizzo un metodo alternativo altamente customizzato su ogni singolo progetto. Se ti incuriosice e vuoi avere maggiori informazioni contattatami.
Altri strumenti per fare analisi ed eseguire test sui Core Web Vitals
Esistono realtà differenti per ottenere dati utili all’ottimizzazione del sito web? Puoi usare il Chrome UX Report per avere un focus sui dati raccolti sul campo o l’estensione di Chrome per misurare le metriche Web Vitals in tempo reale.
Si può anche utilizzare una libreria JavaScript, servendoti delle API di Google, per misurare le metriche reali durante la navigazione degli utenti. Integrando questo codice attraverso Google Tag Manager puoi inviare i dati di CLS, FID e LCP (per singola pagina) direttamente alla tua proprietà di Google Analytics.
Oppure puoi approfondire il singolo indirizzo URL con il Pagespeed Insight e Lighthouse che fornisce ulteriori approfondimenti su SEO, accessibilità e UX.
Errori comuni quando si leggono i report
L’errore più frequente è inseguire il punteggio perfetto su un singolo test, dimenticando che ciò che conta sono i dati reali e la ripetibilità. Se fai un test, poi lo rifai e il numero cambia molto, non significa che “gli strumenti mentono”: significa che stai misurando condizioni diverse (cache, rete, CPU, estensioni del browser, script caricati in modo variabile).
Un altro equivoco è lavorare sulla pagina sbagliata. Molti siti hanno problemi legati ai template (categoria, prodotto, articolo, landing), non alla singola URL. Se sistemi un’unica pagina ma il template resta pesante, l’impatto complessivo sul sito e sui KPI sarà limitato.
Infine, attenzione ai tempi: se guardi Search Console e ti aspetti un cambiamento immediato, rischi di prendere decisioni affrettate. Serve metodo: intervento mirato, rilascio controllato, e poi una fase di validazione con dati sufficienti.
La strada è tracciata: fai parlare i Core Web Vitals con i tuoi KPI
I Core Web Vitals ti aiutano a trasformare un’impressione (“il sito è lento”) in dati utili per decidere cosa sistemare davvero: non per inseguire un punteggio, ma per migliorare l’esperienza percepita e ridurre l’attrito nei punti che contano. La chiave è leggere insieme segnali diversi (dati reali e test di laboratorio), capire dove nasce il problema e tradurlo in interventi concreti che abbiano impatto su usabilità, SEO tecnico e conversioni.
Se vuoi renderla una cosa “da roadmap” e non un progetto infinito, parti da una baseline chiara, scegli le pagine più importanti del funnel, implementa, poi valida con misurazioni continue. Cominciamo dai dati: se ti serve un audit SEO mirato e una dashboard in Data Studio per collegare performance e risultati di business, scrivimi e impostiamo un percorso sostenibile, fatto di iterazioni e KPI verificabili.
Mirko Ciesco
Data-Driven Growth Specialist
Aiuto aziende e startup a prendere decisioni migliori per crescere in modo misurabile. Sono specializzato in Web Analytics e performance digitale e lavoro all’intersezione tra dati, strategia e crescita.