I Core Web Vitals sono tre metriche sviluppate da Google per misurare aspetti concreti dell’esperienza che una persona vive quando apre e utilizza una pagina web: quanto rapidamente compare il contenuto principale, quanto velocemente l’interfaccia risponde e quanto rimane stabile il layout.
Le metriche attuali sono Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Non sono quattro e First Contentful Paint (FCP) non è un Core Web Vital, anche se rimane una metrica utile nella diagnosi delle performance. Google indica come valori “buoni” LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS non superiore a 0,1. (Google Search Central)
C’è però una distinzione ancora più importante dei singoli numeri: superare i Core Web Vitals non significa ottenere 100 su PageSpeed Insights, e ottenere 100 in un test di laboratorio non significa necessariamente che gli utenti reali stiano vivendo una buona esperienza.
Per ottimizzare correttamente queste metriche bisogna quindi seguire un processo:
dati reali → metrica problematica → causa tecnica → intervento → verifica
Saltare direttamente all’ultima fase, installando un plugin o comprimendo qualche immagine perché PageSpeed lo suggerisce, spesso significa intervenire senza aver capito il problema.
Cosa sono i Core Web Vitals e cosa misurano davvero
I Core Web Vitals appartengono al più ampio insieme dei Web Vitals, metriche pensate per descrivere la qualità dell’esperienza attraverso segnali misurabili.
I tre Core Web Vitals si concentrano su aspetti differenti:
| Metrica | Cosa misura | Valore buono | Core Web Vital? | Utilità principale |
|---|---|---|---|---|
| LCP | Velocità con cui appare il contenuto principale | ≤ 2,5 s | Sì | Caricamento |
| INP | Reattività della pagina alle interazioni | ≤ 200 ms | Sì | Interattività |
| CLS | Stabilità visiva del layout | ≤ 0,1 | Sì | Stabilità |
| FCP | Quando compare il primo contenuto | ≤ 1,8 s | No | Diagnosi del caricamento |
| TTFB | Tempo prima della ricezione del primo byte | — | No | Diagnosi server/rete |
| TBT | Tempo durante il quale il main thread resta bloccato | — | No | Diagnosi della reattività in laboratorio |
La tabella chiarisce un punto che genera ancora molta confusione: non tutte le metriche mostrate da PageSpeed Insights o Lighthouse sono Core Web Vitals.
FCP, TTFB e TBT possono essere estremamente utili. Semplicemente rispondono a domande diverse.
LCP, INP e CLS: i tre Core Web Vitals
Largest Contentful Paint misura quanto tempo passa prima che il più grande elemento di contenuto visibile nell’area iniziale della pagina venga renderizzato. Può trattarsi, per esempio, dell’immagine hero, di un grande blocco di testo o di un altro elemento rilevante.
Se vuoi approfondire questa metrica separatamente, nella guida al Largest Contentful Paint trovi il funzionamento di LCP e le principali strategie di diagnosi.
Interaction to Next Paint osserva invece la reattività della pagina alle interazioni dell’utente. Clic, tap e input da tastiera possono richiedere del lavoro al browser; INP cerca di rappresentare quanto rapidamente l’interfaccia riesce a produrre la risposta visiva successiva.
INP ha sostituito il precedente FID perché permette di osservare la reattività lungo l’esperienza della pagina, invece di limitarsi al primo input. (web.dev)
Cumulative Layout Shift, infine, misura la stabilità visiva. Un layout shift si verifica quando un elemento visibile cambia posizione inaspettatamente fra due frame. Immagini senza spazio riservato, banner caricati in ritardo, font ed elementi inseriti dinamicamente sono fra le cause tipiche.
Per un’analisi specifica puoi approfondire come correggere il Cumulative Layout Shift.
Queste metriche non sono intercambiabili. Un sito può avere un ottimo LCP e un pessimo INP; può caricare rapidamente il contenuto principale ma diventare lento appena l’utente apre un menu. Oppure può essere veloce e reattivo ma spostare continuamente pulsanti, immagini e blocchi di testo durante il caricamento.
È proprio questa separazione a rendere utile il modello Core Web Vitals: “sito veloce” non è più una singola proprietà.
Quali valori sono buoni e perché conta il 75° percentile
Le soglie consigliate da Google sono:
- LCP: 2,5 secondi o meno;
- INP: 200 millisecondi o meno;
- CLS: 0,1 o meno.
La parte meno intuitiva è che il giudizio non viene formulato prendendo la media delle visite.
Per valutare se un’esperienza rientra nella fascia “buona”, gli strumenti che utilizzano dati reali considerano il 75° percentile delle visite, separando mobile e desktop. In termini pratici, la metrica deve rimanere nella fascia buona per almeno circa tre esperienze su quattro. (web.dev)
Questo cambia il modo in cui devi leggere il dato.
Immagina che la maggior parte dei visitatori abbia un LCP molto rapido, ma una quota significativa utilizzi dispositivi meno potenti, connessioni più lente o raggiunga la pagina in condizioni differenti. La media potrebbe apparire ancora rassicurante, mentre il 75° percentile può far emergere quella parte dell’esperienza che non è sufficientemente stabile.
Lo scopo non è quindi rendere perfetto il test eseguito dal tuo computer. È fare in modo che una quota sufficientemente ampia degli utenti reali riceva una buona esperienza.
FCP, TTFB e TBT: metriche utili, ma non Core Web Vitals
Un errore frequente consiste nel vedere FCP, TTFB o TBT accanto a LCP e concludere che facciano tutti parte dello stesso set.
Non è così.
First Contentful Paint (FCP) indica quando il browser visualizza il primo contenuto significativo, ma non quando appare necessariamente il contenuto principale. Un sito può quindi avere un FCP rapido e un LCP lento.
Time to First Byte (TTFB) osserva una fase ancora precedente: il tempo trascorso prima che il browser inizi a ricevere la risposta HTML. Un TTFB elevato consuma parte del tempo disponibile prima ancora che il browser possa iniziare seriamente a costruire la pagina. Per questo diventa particolarmente importante nella diagnosi di un LCP problematico. (web.dev)
Total Blocking Time (TBT) è invece una metrica di laboratorio utile per individuare periodi nei quali il main thread è impegnato in attività sufficientemente lunghe da ostacolare la reattività. Lighthouse non può misurare il vero INP durante un normale page-load test perché manca una reale sequenza di interazioni dell’utente; TBT può quindi funzionare come indicatore diagnostico, ma non sostituisce INP.
La relazione corretta è:
Core Web Vital problematico → metriche diagnostiche → causa
non:
ogni metrica di performance = Core Web Vital.
Core Web Vitals e SEO: quanto contano davvero per Google
I Core Web Vitals hanno una relazione reale con Google Search, ma questa relazione viene spesso semplificata fino a diventare fuorviante.
Google dichiara che i Core Web Vitals vengono utilizzati dai propri sistemi di ranking e raccomanda di raggiungere valori buoni sia per Search sia, soprattutto, per fornire una buona esperienza agli utenti. (documentazione Google sulla page experience)
Questo non significa però:
miglioro LCP → salgo automaticamente di cinque posizioni.
Il ranking dipende da numerosi sistemi e segnali. Rilevanza del contenuto, soddisfazione dell’intento, qualità, affidabilità, contesto della ricerca e molti altri elementi continuano a partecipare alla selezione dei risultati.
Cosa Google conferma sui sistemi di ranking
La formulazione più utile è questa:
GOOGLE_CONFIRMED: i Core Web Vitals vengono utilizzati dai sistemi di ranking.
NON CONFERMATO: esiste una quantità universale di posizioni che una pagina guadagna migliorando LCP, INP o CLS.
NON CONFERMATO: fallire una metrica equivale automaticamente a una penalizzazione.
NON CONFERMATO: ottenere un punteggio PageSpeed perfetto garantisce un ranking migliore.
Questa distinzione è importante perché impedisce di trasformare una metrica tecnica in una promessa SEO.
Un contenuto scarsamente pertinente non diventa competitivo perché il suo LCP è di 1,5 secondi. Allo stesso modo, una pagina estremamente utile non dovrebbe ignorare problemi di esperienza gravi soltanto perché possiede un buon contenuto.
Le due dimensioni convivono.
Perché buoni Core Web Vitals non garantiscono le prime posizioni
Google specifica espressamente che ottenere buoni risultati nel report Core Web Vitals di Search Console o in strumenti di terze parti non garantisce che una pagina raggiunga le prime posizioni.
Il motivo è semplice: i Core Web Vitals rispondono a una domanda circoscritta.
Che esperienza di caricamento, reattività e stabilità stanno vivendo gli utenti?
Non rispondono invece a domande come:
- il contenuto soddisfa la query?
- la pagina affronta realmente il problema cercato?
- le informazioni sono affidabili?
- esistono risultati molto più pertinenti?
- la pagina corrisponde al tipo di contenuto che l’utente vuole trovare?
Per questo conviene considerare i Core Web Vitals una componente della SEO tecnica e della qualità dell’esperienza, non un sistema di scoring con cui acquistare posizioni.
Se vuoi inquadrare queste metriche all’interno del processo più ampio, la guida su cos’è la SEO e come funziona distingue performance, contenuto, indicizzazione e ranking senza ridurli a una checklist.
Page experience: perché non esiste un unico “punteggio SEO”
Un altro equivoco nasce dalla parola score.
Lighthouse può generare un Performance Score da 0 a 100. I Core Web Vitals, invece, vengono valutati attraverso le rispettive metriche.
Sono due livelli differenti.
Puoi quindi incontrare scenari come:
- buon punteggio Lighthouse ma dati CrUX problematici;
- punteggio Lighthouse mediocre ma Core Web Vitals reali buoni;
- ottimo LCP ma INP fuori soglia;
- test locale perfetto ma parte degli utenti reali ancora in difficoltà.
Non c’è contraddizione. Stai semplicemente osservando fenomeni differenti attraverso metodi differenti.
Field data e lab data: come leggere i Core Web Vitals senza confondersi
Questa è probabilmente la distinzione più importante per lavorare seriamente sui Core Web Vitals.
Field data significa dati raccolti durante esperienze reali.
Lab data significa misurazioni ottenute in condizioni controllate e ripetibili.
I primi ti dicono che cosa stanno vivendo gli utenti.
I secondi ti aiutano soprattutto a capire perché sta succedendo.
PageSpeed Insights mette entrambi nello stesso report, ed è proprio questo che può creare confusione quando si guarda soltanto il numero più evidente.
CrUX: cosa raccontano gli utenti reali nei 28 giorni
Il Chrome User Experience Report, normalmente abbreviato in CrUX, raccoglie dati di esperienza provenienti da utenti reali di Chrome idonei al dataset.
PageSpeed Insights utilizza questi dati nella sezione dedicata all’esperienza degli utenti reali. I valori mostrati rappresentano una finestra mobile di 28 giorni, non il risultato di un test appena eseguito. (documentazione PageSpeed Insights)
Qui nasce una conseguenza pratica importante.
Se questa mattina modifichi:
- caching;
- immagine hero;
- JavaScript;
- font;
- server;
- layout;
non devi aspettarti che il dato CrUX storico cambi immediatamente.
Il test di laboratorio può reagire subito perché sta misurando la versione corrente della pagina. Il field data deve invece incorporare nuove visite e far uscire progressivamente dalla finestra quelle precedenti.
Per questo una correzione può essere tecnicamente riuscita prima che il report dei dati reali mostri completamente il miglioramento.
Lighthouse: perché un test di laboratorio serve soprattutto a diagnosticare
Un test di laboratorio ha un vantaggio enorme: puoi ripeterlo.
Puoi modificare una risorsa, eseguire nuovamente il test e osservare cosa cambia. Puoi analizzare il waterfall, le long task, il rendering e le risorse che bloccano o rallentano il browser.
È esattamente il tipo di lavoro per cui Google Lighthouse è utile.
Il limite è che una simulazione non rappresenta automaticamente la distribuzione completa degli utenti reali.
Un visitatore può avere:
- uno smartphone differente;
- una CPU più lenta;
- cache fredda;
- rete più debole;
- cookie o personalizzazioni differenti;
- script di terze parti che si comportano diversamente;
- una sequenza di interazioni che il test standard non riproduce.
Google stessa consiglia quindi, quando i dati reali sono disponibili, di concentrarsi prima su quelli e utilizzare gli strumenti di laboratorio per spiegare e risolvere il problema.
URL e origin: perché PageSpeed Insights può mostrarti dati differenti
C’è poi un’altra distinzione facile da perdere.
CrUX può avere dati sufficienti per una specifica URL, oppure soltanto per l’origin, cioè in termini semplificati per il sito nel suo complesso.
PageSpeed Insights può quindi mostrarti:
- dati mobile della URL;
- dati desktop della URL;
- dati mobile dell’origin;
- dati desktop dell’origin.
Se la pagina analizzata non possiede traffico sufficiente per un dato URL-level, PSI può ricorrere ai dati disponibili sull’origin.
Questo dettaglio cambia molto l’interpretazione.
Una pagina prodotto estremamente pesante può comportarsi diversamente da una pagina articolo. Una homepage può usare una hero complessa che non esiste nelle pagine interne. Un template ecommerce può avere molto più JavaScript del blog.
Prima di concludere che “questa pagina ha un LCP di X”, controlla quindi quale insieme di dati stai realmente leggendo.
Un punteggio PageSpeed 100 non significa aver superato i Core Web Vitals
La guida dedicata a PageSpeed Insights entra nel dettaglio dello strumento, ma qui basta conservare un modello mentale molto semplice:
Performance Score Lighthouse ≠ Core Web Vitals assessment CrUX
Il primo nasce da una misurazione di laboratorio.
Il secondo, quando disponibile, descrive l’esperienza reale sulla base di LCP, INP e CLS al 75° percentile.
Ottimizzare un sito soltanto per spostare il numero da 93 a 100 può quindi diventare una distrazione se gli utenti reali hanno già metriche buone e il lavoro necessario non risolve un problema concreto.
Il contrario è ancora più importante: un buon numero nel test non dovrebbe farti ignorare un problema evidente nei dati reali.
Come misurare i Core Web Vitals: dalla segnalazione alla causa
Il metodo migliore non consiste nell’aprire sette strumenti e confrontare i loro punteggi.
Conviene assegnare a ogni strumento una funzione.
Search Console → individua il problema su scala sito.
PageSpeed Insights → confronta field e lab sulla pagina.
Chrome DevTools / Lighthouse / WebPageTest → individua la causa tecnica.
Questa sequenza trasforma una raccolta di numeri in un processo diagnostico.
Search Console: individua metriche e gruppi di URL in difficoltà
Il report Core Web Vitals di Google Search Console utilizza dati reali CrUX e permette di individuare problemi relativi a LCP, INP e CLS su mobile e desktop.
È un buon punto di partenza quando la domanda è:
Quali parti del sito stanno offrendo un’esperienza problematica?
Non è invece lo strumento ideale per rispondere da solo alla domanda successiva:
Quale risorsa o quale funzione JavaScript sta causando il problema?
Per quello devi passare dalla classificazione alla diagnosi.
Se utilizzi regolarmente lo strumento, puoi approfondire l’intero flusso nella guida a Google Search Console.
PageSpeed Insights: analizza la singola pagina e confronta field e lab
Aprendo una URL in PageSpeed Insights, il primo controllo non dovrebbe essere il numero colorato da 0 a 100.
Controlla invece:
- se sono disponibili dati reali;
- se riguardano la URL oppure l’origin;
- se il report è mobile o desktop;
- quale fra LCP, INP e CLS non rientra nella fascia buona;
- quali metriche complementari aiutano a spiegare il problema;
- cosa mostra il test Lighthouse sottostante.
Questo evita il classico errore di trattare contemporaneamente tutte le raccomandazioni del report come se avessero la stessa priorità.
Se il problema reale è CLS, per esempio, ridurre di qualche kilobyte un’immagine che non causa spostamenti potrebbe essere un buon intervento generale di performance, ma non sta necessariamente risolvendo il Core Web Vital che ha fatto partire l’analisi.
Chrome DevTools, Lighthouse e WebPageTest: trova il collo di bottiglia
Quando conosci la metrica problematica, devi scendere di livello.
Con Chrome DevTools puoi analizzare:
- main thread;
- long task;
- richieste di rete;
- priorità delle risorse;
- rendering;
- layout shift;
- interazioni.
Lighthouse aggiunge una diagnosi ripetibile in laboratorio.
WebPageTest diventa particolarmente utile quando vuoi osservare waterfall dettagliati, condizioni di rete e sequenze di caricamento.
Lo scopo non è stabilire quale tool “ha ragione”.
Lo scopo è utilizzare ciascun dato nel contesto per cui è stato prodotto.
Come migliorare LCP, INP e CLS partendo dalla causa
Dire “ottimizza immagini, CSS, JavaScript e cache” è corretto ma poco utile.
Lo stesso intervento può essere decisivo su una pagina e quasi irrilevante su un’altra.
Conviene invece partire dal meccanismo della metrica.
| Se fallisce | Controlla prima | Problemi frequenti | Classe di intervento |
|---|---|---|---|
| LCP | Elemento LCP e waterfall | TTFB, scoperta tardiva, priorità, risorsa pesante, rendering | Server, rete, HTML, CSS, immagini |
| INP | Interazione lenta e main thread | Long task, JS, callback, rendering complesso | JavaScript, DOM, rendering |
| CLS | Elementi che cambiano posizione | Immagini senza spazio, embed, ads, font, contenuto dinamico | Layout, CSS, media, font |
LCP alto: server, scoperta della risorsa e ritardo di rendering
Un LCP lento non significa automaticamente “immagine troppo pesante”.
Google suddivide il percorso che porta a LCP in componenti come:
- Time to First Byte;
- ritardo prima che la risorsa LCP inizi a caricarsi;
- tempo necessario a trasferire la risorsa;
- ritardo fra la fine del caricamento e il rendering dell’elemento.
(guida ufficiale all’ottimizzazione LCP)
Questa scomposizione evita diversi interventi sbagliati.
Scenario 1: TTFB elevato.
Il browser riceve tardi l’HTML. Anche un’immagine hero perfettamente ottimizzata parte già svantaggiata. Qui devi guardare hosting, elaborazione server, caching, redirect e distanza di rete.
Scenario 2: l’immagine LCP viene scoperta troppo tardi.
Può essere nascosta dietro JavaScript, dichiarata come background CSS o trattata con lazy loading. In questo caso comprimere ulteriormente il file riduce soltanto una parte del problema.
In particolare, l’immagine che rappresenta il contenuto LCP iniziale non dovrebbe essere lazy-loaded. Google raccomanda di renderla facilmente scopribile e, quando appropriato, di darle una priorità elevata.
Scenario 3: la risorsa ha finito di caricarsi, ma non compare.
Il problema diventa render delay. CSS bloccante, JavaScript, A/B testing o long task possono impedire al browser di mostrarla immediatamente.
La domanda quindi non è “come riduco LCP?”, ma:
Quale componente del mio LCP sta consumando tempo?
Da quella risposta deriva l’intervento.
INP alto: input delay, JavaScript, elaborazione e presentazione
INP richiede un ragionamento differente perché entra in gioco ciò che accade quando l’utente interagisce.
La latenza di un’interazione può essere scomposta in tre parti:
- input delay: l’interazione è avvenuta, ma il browser non può ancora iniziare a gestirla;
- processing duration: vengono eseguiti gli event handler e il lavoro associato;
- presentation delay: il browser deve completare rendering e paint della risposta.
(guida all’ottimizzazione INP)
Immagina un menu mobile.
L’utente tocca l’icona, ma in quel momento il main thread è impegnato da uno script di tracciamento. Passano decine o centinaia di millisecondi prima che il callback possa iniziare: input delay.
Il callback del menu esegue poi una quantità eccessiva di JavaScript: processing duration.
Infine l’apertura modifica un DOM molto complesso e il browser deve ricalcolare stili e layout: presentation delay.
Il risultato visibile è uno solo — il menu sembra lento — ma le cause richiedono interventi diversi.
Per questo “minifica JavaScript” non è una diagnosi.
Devi capire:
- quale interazione è lenta;
- cosa occupa il main thread;
- quali script di prima o terza parte intervengono;
- se esistono long task;
- quanto lavoro viene eseguito dall’handler;
- quanto è costoso aggiornare il DOM.
Nel test di laboratorio TBT può aiutare a individuare un main thread eccessivamente bloccato, ma ricorda che resta un proxy: il vero INP richiede esperienza e interazioni reali.
CLS alto: dimensioni mancanti, font, embed e contenuti dinamici
CLS riguarda invece il movimento inatteso degli elementi visibili.
Fra le cause più comuni trovi:
- immagini prive di dimensioni o aspect ratio riservato;
- iframe ed embed che acquisiscono spazio soltanto dopo il caricamento;
- pubblicità con slot variabili;
- banner o componenti aggiunti sopra contenuti già visibili;
- font che modificano dimensioni e disposizione del testo;
- elementi inseriti dinamicamente.
(guida ufficiale all’ottimizzazione CLS)
Il meccanismo da capire è semplice: se il browser non sa quanto spazio occupare, potrebbe dover spostare ciò che aveva già disegnato.
Impostare width e height sulle immagini, o comunque riservarne correttamente l’aspect ratio via CSS, permette al browser di costruire il layout prima ancora che il file sia disponibile.
Per embed, annunci e componenti caricati successivamente vale lo stesso principio: se conosci lo spazio necessario, riservalo.
I font meritano un’attenzione particolare perché una variazione nelle metriche tipografiche può cambiare la lunghezza delle righe, l’altezza dei blocchi di testo e quindi la disposizione di tutto ciò che segue.
CLS non si risolve quindi “rendendo il sito più veloce” in senso generico.
Si risolve rendendo il layout prevedibile.
Core Web Vitals su WordPress: cosa controllare prima di installare un altro plugin
Su WordPress la tentazione è immediata: PageSpeed segnala un problema, si installa un plugin di performance.
A volte funziona. Molte altre volte aggiunge un nuovo livello di configurazione senza eliminare la causa.
Il comportamento dei Core Web Vitals dipende dall’intero sistema:
hosting → WordPress/PHP → tema → page builder → plugin → contenuto → script esterni → browser
Un plugin di caching può intervenire efficacemente su una parte della catena, ma non può correggere qualsiasi problema.
Tema, page builder e JavaScript di terze parti
Per INP, uno dei primi punti da controllare è la quantità di lavoro eseguita dal browser.
Theme framework, page builder, slider, popup, analytics, advertising, chat, cookie manager e componenti marketing possono aggiungere JavaScript e lavoro sul main thread.
La domanda utile non è:
Quale plugin devo installare per migliorare INP?
È:
Quale codice sta impedendo al browser di rispondere rapidamente all’interazione?
Aprire una registrazione nel Performance panel di Chrome e osservare una vera interazione lenta può essere molto più utile dell’installazione casuale di un altro ottimizzatore.
Se un componente non produce un valore sufficiente rispetto al costo che introduce, la soluzione migliore può anche essere rimuoverlo, non ottimizzarlo.
Immagine LCP, font, cache e TTFB
Su molti siti WordPress l’elemento LCP è un’immagine hero o un contenuto visuale presente sopra la piega.
Qui controlla prima:
- dimensioni reali del file;
- formato;
- dimensioni dell’immagine servita;
- attributi responsive;
- eventuale lazy loading errato;
- posizione della risorsa nel documento;
- priorità di caricamento.
Se invece il problema nasce prima che l’immagine possa essere richiesta, spostati verso server e WordPress.
Un TTFB elevato può dipendere, fra le altre cose, da elaborazione backend, query, assenza di caching efficace o infrastruttura non adeguata.
La guida al caching in WordPress spiega i diversi livelli di cache e perché non vanno confusi con una semplice opzione “on/off” di un plugin.
Plugin di performance: quando aiutano e quando non risolvono la causa
Plugin e servizi di performance possono essere molto utili quando automatizzano interventi coerenti con il problema, per esempio:
- page caching;
- browser caching;
- compressione;
- ottimizzazione delle immagini;
- caricamento differito di risorse non critiche;
- gestione del CSS;
- controllo di alcuni script;
- preload o priorità di specifiche risorse.
Ma il plugin deve essere la conseguenza della diagnosi, non il sostituto.
Se il CLS nasce da un banner inserito dinamicamente senza spazio riservato, una cache più aggressiva potrebbe non cambiare nulla.
Se INP è alto perché un widget esterno occupa il main thread, comprimere le immagini non risolve il problema.
Se LCP è causato da un’immagine hero lazy-loaded, installare un secondo plugin di lazy loading può addirittura peggiorare la situazione.
La regola operativa è quindi:
prima identifica la causa, poi scegli lo strumento che può intervenire proprio su quella causa.
Come verificare se l’ottimizzazione ha funzionato
Una modifica non è completata quando il plugin mostra “cache svuotata” o quando il Performance Score aumenta.
Serve una verifica su due tempi differenti.
Subito: laboratorio.
Nel tempo: dati reali.
Questa distinzione evita sia falsi successi sia falsi fallimenti.
Cosa puoi verificare subito con un test di laboratorio
Dopo una modifica puoi rieseguire PageSpeed Insights, Lighthouse, DevTools o WebPageTest mantenendo il più possibile le stesse condizioni.
Se stavi lavorando su LCP, verifica:
- se l’elemento LCP è ancora lo stesso;
- quando viene scoperta la risorsa;
- con quale priorità viene richiesta;
- quanto dura il trasferimento;
- quanto passa prima del rendering.
Se lavoravi su INP, riproduci l’interazione problematica e controlla main thread, long task ed event handler.
Se lavoravi su CLS, identifica se gli elementi instabili continuano a spostarsi.
Il test di laboratorio ti permette quindi di rispondere a una domanda precisa:
La modifica ha corretto il meccanismo che avevo identificato?
Perché i dati CrUX non cambiano immediatamente dopo il fix
Il dato reale non è una fotografia istantanea.
CrUX considera una finestra mobile di esperienza reale. Dopo l’intervento, le nuove visite devono entrare progressivamente nel dataset mentre quelle precedenti escono.
Questo significa che puoi avere una situazione del tutto normale:
test tecnico migliorato oggi → field data ancora problematico → miglioramento progressivo nei giorni successivi
Non interpretare questo ritardo come prova che la modifica non abbia funzionato.
Allo stesso tempo, non considerare il test di laboratorio come prova definitiva che il problema degli utenti sia già risolto.
Le due verifiche rispondono a domande differenti.
Quando considerare risolto il problema nei dati reali
Un buon processo di validazione è:
- confermare la causa tecnica;
- applicare una modifica controllata;
- verificare in laboratorio che il meccanismo sia cambiato;
- controllare eventuali regressioni su altre metriche;
- monitorare i nuovi dati reali;
- verificare che il 75° percentile raggiunga la fascia desiderata.
Questo ultimo passaggio è importante perché un’ottimizzazione può produrre trade-off.
Ritardare troppo JavaScript, per esempio, può migliorare il caricamento iniziale ma rompere una funzione. Forzare preload indiscriminati può aumentare la competizione di rete. Modificare il comportamento dei font può ridurre CLS ma peggiorare altri aspetti della resa.
La performance non è un gioco in cui vince chi applica più tecniche.
È un lavoro di diagnosi, intervento e verifica.
Se il sito presenta problemi strutturali che coinvolgono più livelli — server, template, immagini, CSS, JavaScript, plugin o configurazione — una ottimizzazione del sito web deve partire proprio da questa analisi delle cause, invece che dall’obiettivo astratto di ottenere un determinato punteggio.
Conclusione
I Core Web Vitals diventano molto più semplici da gestire quando smetti di considerarli tre numeri da “portare nel verde” e inizi a leggerli come segnali di tre esperienze differenti.
LCP ti dice se il contenuto principale arriva abbastanza rapidamente. INP ti dice se l’interfaccia riesce a reagire quando l’utente la usa. CLS ti dice se ciò che hai già mostrato rimane stabile.
Il passaggio decisivo viene subito dopo: i Core Web Vitals descrivono il problema, ma non sempre ne spiegano la causa.
Per questo il workflow corretto non parte dall’installazione di un plugin e non termina con il punteggio PageSpeed:
misura i dati reali → identifica la metrica fallita → riproduci il problema in laboratorio → individua la causa → intervieni sul meccanismo → verifica di nuovo sul campo.
Se mantieni questa sequenza, PageSpeed Insights, Search Console, Lighthouse e DevTools smettono di sembrare strumenti che forniscono numeri contraddittori. Diventano parti differenti dello stesso processo diagnostico.