Core Web Vitals: cosa misurano davvero (e cosa Google ne fa)

In sintesi: i Core Web Vitals sono le tre metriche con cui Google misura l’esperienza degli utenti sul tuo sito. Spieghiamo cosa sono davvero LCP, CLS e INP, perché il punteggio di Lighthouse del tuo developer non coincide con quello che Google vede, e dove l’ottimizzazione delle performance si intreccia con accessibilità e sostenibilità.

Cinque anni fa abbiamo realizzato la prima versione del sito di Alex Bellini, esploratore e divulgatore impegnato sui temi della sostenibilità ambientale. Cinque anni dopo siamo tornati per un intervento che doveva valorizzare i contenuti del blog. È diventato qualcosa di più: la riscoperta che performance, accessibilità e sostenibilità sono lo stesso problema visto da tre angolazioni diverse. I numeri di quel lavoro li raccontiamo più avanti. Prima vale la pena fare ordine sulla cosa che spesso si dà per scontata: cosa sono i Core Web Vitals, e cosa Google ne fa davvero.

Cosa sono i Core Web Vitals e perché Google ci insiste

I Core Web Vitals sono tre metriche introdotte da Google nel 2020 per misurare in modo oggettivo l’esperienza degli utenti su una pagina web. Non valutano i contenuti, non valutano il design, non valutano la SEO tradizionale: valutano la qualità della relazione tra il sito e chi lo usa. Quanto velocemente la pagina diventa utile, quanto è stabile mentre carica, come risponde quando ci interagisci.

Dal 2021 sono ufficialmente parte dei segnali che Google considera per il posizionamento nei risultati di ricerca, insieme ad altri “Page Experience signals” come HTTPS e l’assenza di interstitial intrusivi. Da allora la lista è evoluta: nel marzo 2024 l’INP (Interaction to Next Paint) ha sostituito il FID come terza metrica fondamentale. Le altre due — LCP per la velocità di caricamento e CLS per la stabilità visiva — sono rimaste, ma con qualche aggiustamento sulle soglie e sul calcolo.

Le tre metriche, una per una

LCP — Largest Contentful Paint: quanto ci mette la pagina ad apparire

L’LCP misura il tempo che intercorre tra l’inizio del caricamento della pagina e il momento in cui l’elemento principale visibile sullo schermo finisce di renderizzarsi. Tipicamente è l’immagine di copertina di un articolo, l’eroe di una landing page, o il primo blocco di testo di una pagina editoriale.

Le soglie di Google sono chiare: sotto i 2,5 secondi è considerato “buono”, tra 2,5 e 4 secondi “da migliorare”, oltre i 4 secondi “scarso”. A influenzarlo concorrono molte cose: il tempo di risposta del server (TTFB), il peso e il formato delle immagini, i web font che bloccano il rendering, gli script JavaScript che il browser deve elaborare prima di disegnare la pagina.

Un esempio concreto dal nostro lavoro: sul sito di Alex Bellini il caricamento veniva rallentato da una libreria JavaScript usata per il lazy-loading delle immagini. La libreria funzionava bene, ma a distanza di qualche anno tutti i principali browser supportano nativamente il lazy-loading con l’attributo loading="lazy" senza bisogno di codice aggiuntivo. L’abbiamo rimossa e abbiamo aggiunto rel="preload" sulle immagini di apertura per anticiparne il caricamento. Risultato: pagine mediamente più veloci di un secondo.

CLS — Cumulative Layout Shift: quanto la pagina “salta” mentre carica

Il CLS misura quanto il layout della pagina si sposta in modo inatteso durante il caricamento. Quante volte ti è capitato di stare per cliccare un link e ritrovarti a cliccarne un altro perché un’immagine si è caricata in ritardo e ha spinto tutto in basso di duecento pixel? Quello è layout shift, e a Google interessa misurarlo perché è una delle frustrazioni più concrete dell’esperienza web.

Le soglie: sotto 0,1 buono, sopra 0,25 scarso. I valori sono adimensionali, calcolati come prodotto tra l’area dello schermo che si sposta e la distanza dello spostamento.

Le cause più comuni sono note: immagini caricate senza dimensioni dichiarate, web font che cambiano il rendering del testo a metà strada, banner o widget di terze parti che vengono iniettati dopo il rendering iniziale. Sul nostro lavoro per VolumeBK, un e-commerce con oltre dodicimila prodotti tra libri, dischi e corsi, abbiamo azzerato il CLS: nessun salto inatteso tra le copertine, nessun bottone che si sposta mentre lo stai cliccando.

INP — Interaction to Next Paint: quanto il sito risponde quando lo tocchi

L’INP è la metrica più giovane delle tre. Ha sostituito il FID (First Input Delay) a marzo 2024, e misura la latenza tra un’interazione dell’utente (un clic, un tocco, una pressione di tasto) e il momento in cui il browser ne mostra l’effetto visivo. A differenza del FID, che valutava solo la prima interazione, l’INP considera tutte le interazioni della sessione e riporta quella peggiore — un parametro più realistico per capire come il sito si comporta davvero nell’uso quotidiano.

Soglie: sotto 200 millisecondi buono, oltre 500 scarso. A penalizzarlo sono soprattutto i carichi JavaScript pesanti che occupano il main thread del browser e i plugin WordPress mal scritti che eseguono lavoro inutile a ogni interazione.

Su VolumeBK l’INP è stato un obiettivo esplicito: aggiungere un libro al carrello, filtrare per genere, aprire la scheda di un disco — sono tutte azioni che dovevano rispondere istantaneamente, indipendentemente dal fatto che il catalogo contenga dodicimila referenze. Per arrivarci abbiamo dovuto ripensare l’architettura della ricerca: invece di interrogare il database WordPress a ogni query, abbiamo costruito un indice statico in formato JSON, compresso, aggiornato in batch quando il catalogo cambia. È un esempio di come a volte ottimizzare significa rifare, non solo accelerare.

Cosa Google fa davvero con questi numeri

Qui sta la parte che molte guide ai Core Web Vitals saltano. I numeri che vedi quando apri Lighthouse o PageSpeed Insights e analizzi una pagina dal tuo computer sono lab data: misure prese in condizioni controllate, su un device simulato, in un singolo istante. Sono utili per sviluppare, debuggare, capire dove intervenire. Ma non sono i numeri che Google usa per posizionarti.

I numeri che contano per il ranking sono i field data: misurazioni reali raccolte attraverso il Chrome User Experience Report (CrUX), aggregando l’esperienza dei visitatori che navigano davvero il sito con Chrome. Connessioni vere, dispositivi veri, condizioni vere. Per questo due siti possono avere lo stesso punteggio Lighthouse e posizionarsi diversamente: uno ha utenti su fibra italiana, l’altro ha un pubblico in mobilità su 4G instabile, e i numeri reali raccontano due storie molto diverse.

Grafico dei Core Web Vitals da Search Console per volumebk.it.

L’altra cosa che vale la pena chiarire: i Core Web Vitals non sono il primo fattore di ranking. Sono un tie-breaker. A parità di rilevanza dei contenuti, una pagina con buoni Core Web Vitals batte una con metriche scarse. Ma una pagina performante con contenuti deboli non scavalcherà mai una pagina lenta con contenuti molto più rilevanti per la query. Inseguire 100/100 su Lighthouse a scapito del lavoro editoriale è uno degli errori più comuni che vediamo fare.

L’ottimizzazione non parte dal codice

La maggior parte degli articoli sui Core Web Vitals si concentra su micro-ottimizzazioni: comprimere le immagini, minificare il CSS, eliminare il JavaScript inutilizzato. Cose giuste, ma che vengono dopo. La performance di un sito WordPress si gioca prima di tutto su scelte architetturali fatte all’inizio del progetto.

L’hosting è il primo fattore. Un server lento o sovraccaricato darà un TTFB (Time to First Byte) alto, e nessuna ottimizzazione del front-end recupererà quel ritardo. Su VolumeBK, dove servono dodicimila prodotti con picchi di traffico legati a eventi e lanci editoriali, abbiamo scelto Kinsta come hosting partner, sfruttando l’integrazione di Edge Caching e CDN per servire contenuti statici con latenza minima.

Il tema WordPress è il secondo. Un tema “tuttofare” pieno di funzionalità che non userai mai porta con sé centinaia di KB di CSS e JavaScript che il browser deve comunque elaborare. La nostra infrastruttura tecnologica proprietaria, Flying, nasce per ridurre quel peso a monte: tema leggero, plugin scelti chirurgicamente, nessuna inerzia tecnologica accumulata.

I plugin sono il terzo. Ogni plugin attivo è codice che gira, query che si fanno, hook che si chiamano. Un sito WordPress con trentacinque plugin sarà quasi sempre più lento di uno con dodici, indipendentemente da cosa fanno. La domanda da farsi prima di installare un plugin non è “mi serve?”, ma “vale il costo permanente di averlo nello stack?”.

Una scorciatoia molto popolare per l’LCP (e perché la usiamo con cautela)

Un esempio concreto di ottimizzazione che sembra giusta ma può rivelarsi miope: per migliorare l’LCP molte guide consigliano di inserire direttamente nell’<head> della pagina il CSS necessario al contenuto above-the-fold, il cosiddetto critical CSS. In questo modo il browser non deve attendere una richiesta separata per il foglio di stile e può iniziare a renderizzare subito la parte di pagina visibile.

Funziona, sul primo paint. Funziona meno bene su tutto il resto.

Il CSS caricato come file esterno tramite <link rel="stylesheet"> viene scaricato una volta sola: dalla seconda pagina in poi il browser usa la copia in cache. Il CSS inline nell’<head>, invece, fa parte dell’HTML stesso: viene trasmesso a ogni richiesta di pagina, anche se è identico tra una pagina e l’altra. Su un utente che naviga dieci pagine del sito sono dieci download dello stesso payload. Moltiplicato per migliaia di visitatori, diventa una quantità di banda — e quindi di energia — che pesa più del millisecondo guadagnato sull’LCP iniziale.

In PaperPlane usiamo il critical CSS inline solo dove ha davvero senso: pagine ad altissimo traffico in cui il guadagno sul primo rendering giustifica il costo cumulativo. Per il resto preferiamo file CSS esterni ben strutturati, cachati dal browser, serviti da una CDN. Costa qualche millisecondo in più sull’LCP della prima visita, ma sull’intero ciclo di vita del sito è una scelta che pesa meno sui server, sulla rete e sul pianeta.

È esattamente il tipo di ragionamento che si perde quando ci si concentra sul punteggio Lighthouse di una singola pagina invece che sull’esperienza reale dei visitatori sull’intero sito.

Performance, accessibilità e sostenibilità sono lo stesso problema

Torniamo ad Alex Bellini. Quando siamo intervenuti sul suo sito, l’obiettivo iniziale era valorizzare il blog. Misurando lo stato di partenza con Lighthouse e axe DevTools abbiamo trovato un punteggio Performance del 68%, un punteggio SEO del 92% e 87 problemi di accessibilità. Dopo l’intervento: 97% di Performance, 100% di SEO, zero problemi di accessibilità. Le tre dimensioni sono migliorate insieme perché in molti casi si curano insieme.

Un sito veloce è un sito che chi ha una connessione lenta riesce comunque a usare. Heading semantici e alt text scritti bene servono allo screen reader e a Google in egual misura. Caricare meno risorse significa consumare meno energia: websitecarbon.com ci dice che il sito di PaperPlane consuma tra il 50% e il 90% in meno della media dei siti web — non per virtuosismo ambientale astratto, ma perché ogni KB risparmiato è un KB che non viene servito, scaricato, decodificato.

Le aziende che hanno preso sul serio l’accessibilità web hanno scoperto questa cosa per prime: i lavori fatti per chi usa tecnologie assistive migliorano la SEO, riducono i tempi di caricamento, alleggeriscono il footprint ambientale. Non è una coincidenza. Sono lo stesso lavoro chiamato in tre modi diversi.

Da dove iniziare se hai un sito WordPress da migliorare

Quattro passi concreti, in ordine.

Primo: guarda i dati reali, non quelli di laboratorio. Apri Google Search Console e vai alla sezione “Esperienza” → “Core Web Vitals”. Quelli sono i numeri che Google vede sui tuoi utenti, raccolti via CrUX. Da lì capisci se hai un problema vero o se Lighthouse ti sta solo facendo paura.

Secondo: identifica le pagine giuste. Non l’home, quasi mai. Le pagine da ottimizzare per prime sono quelle con più traffico organico, perché l’impatto sul ranking si vede dove gli utenti effettivamente atterrano da Google. Per i siti e-commerce sono spesso le pagine prodotto o le categorie più ricercate; per i siti editoriali, gli articoli evergreen più letti.

Terzo: fai un audit serio, non solo automatizzato. Lighthouse e axe DevTools sono punti di partenza, non punti di arrivo. Gli strumenti automatici trovano problemi evidenti ma perdono le sfumature: una libreria JS rimossa, un font caricato in modo diverso, un’immagine ripensata possono valere più di mille suggerimenti automatizzati.

Quarto: prioritizza per impatto, non per facilità. La tentazione è iniziare dai fix veloci. Ma se il problema vero è l’hosting, comprimere altre venti immagini non sposterà l’ago della bilancia. Misura prima dove sta il collo di bottiglia, poi intervieni.

Quando vale la pena chiedere aiuto

Ottimizzare i Core Web Vitals di un sito WordPress senza riprogettarlo è un lavoro che si può fare in fasi: audit, interventi mirati, misurazione dei risultati. Su molti progetti dei nostri clienti il guadagno arriva dai primi due o tre interventi giusti, non da centinaia di micro-fix accumulati.

Se vuoi capire da che parte iniziare, in PaperPlane offriamo una call gratuita di trenta minuti dedicata a web performance e sostenibilità digitale. Ti diciamo cosa vediamo guardando i tuoi dati reali e quale margine di miglioramento ci sembra concretamente raggiungibile. Senza promessa di 100/100 su Lighthouse: ci interessano i numeri che spostano davvero qualcosa per i tuoi utenti.