BRAND, WEB.
E SPAZI 3D.

· 5 min di lettura · Vetro

Core Web Vitals: cosa misurano e come superarle

LCP, INP e CLS: cosa misura ciascuna, le soglie di Google, dove vedere i dati dei tuoi visitatori reali e gli interventi che contano di più.

Macrofotografia di una goccia che cade nell’acqua azzurra e solleva una corona di goccioline, con cerchi concentrici intorno
Immagine generata con l’IA

Le Core Web Vitals sono le tre metriche con cui Google misura come si vive una pagina: quanto tempo serve perché compaia il contenuto principale (LCP), quanto ci mette la pagina a reagire quando la tocchi (INP) e quanto si sposta mentre carica (CLS). Una pagina le supera quando, nel 75% delle visite reali (separatamente su smartphone e computer), tutte e tre le metriche restano nella colonna «Buona» (web.dev):

Metrica Buona Da migliorare Scarsa
LCP (caricamento) fino a 2,5 s da 2,5 a 4 s oltre 4 s
INP (reattività) fino a 200 ms da 200 a 500 ms oltre 500 ms
CLS (stabilità) fino a 0,1 da 0,1 a 0,25 oltre 0,25

Le sigle vengono dall’inglese: Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift. L’INP ha sostituito il vecchio FID il 12 marzo 2024 (web.dev). Se una guida parla ancora del FID, non è aggiornata.

Contano per il posizionamento su Google?

Sì, ma non decidono tutto. Google conferma che i suoi sistemi di ranking usano le Core Web Vitals e, allo stesso tempo, che cerca sempre di mostrare il contenuto più pertinente, anche quando l’esperienza sulla pagina non è ottimale (Google Search Central). Un sito veloce non compensa un contenuto che non risponde a ciò che si cerca; tra due pagine ugualmente utili, aiuta.

Dove la velocità si nota di più è nel business. In uno studio commissionato da Google a Deloitte e 55 su 37 marchi europei e americani, rendere il sito mobile più veloce di 0,1 s ha aumentato le conversioni dell’8,4% per i negozi online e del 10,1% per i siti di viaggi; sui siti di acquisizione contatti, il 21,6% di utenti in più è arrivato alla pagina di invio del modulo (web.dev). Sono dati del 2019, misurati con metriche precedenti a quelle attuali, ma per negozi e viaggi la direzione è chiara.

Dove vedere i dati del tuo sito

  • Dati sul campo, quelli che usa Google: vengono da visite reali con Chrome (il report CrUX). Li trovi nel report Core Web Vitals di Search Console, che riassume gli ultimi 28 giorni e raggruppa le pagine simili (Guida di Search Console), e nella parte alta di PageSpeed Insights. Se il tuo sito riceve poche visite, potrebbero non esserci ancora dati.
  • Dati di laboratorio: un test simulato, come quello di Lighthouse nella parte bassa di PageSpeed Insights. Servono a trovare il problema, ma non sono ciò che misura Google. Il test di Lighthouse in PageSpeed Insights non può misurare l’INP, perché durante il test nessuno usa la pagina, e al suo posto usa il Total Blocking Time (TBT) (web.dev).

Quando correggi qualcosa, in Search Console puoi fare clic su «Avvia monitoraggio»: Google controlla quelle pagine per 28 giorni prima di considerare risolto il problema.

Come migliorare ciascuna

LCP: prima di tutto l’essenziale

  • Non ritardare l’immagine principale. Mai con il caricamento differito (loading="lazy"), e meglio con fetchpriority="high", così il browser la richiede prima (web.dev).
  • Immagini leggere: in WebP o AVIF e non più grandi della dimensione in cui vengono mostrate.
  • Un server che risponde in fretta e una rete di distribuzione dei contenuti (CDN) vicina ai tuoi visitatori.
  • L’immagine principale nell’HTML: se la aggiunge JavaScript dopo, il browser non la scopre in tempo.

INP: una pagina che risponde subito

  • Meno JavaScript, e quello che resta diviso in attività brevi: mentre il browser esegue un’attività lunga, non può rispondere a un tocco (web.dev).
  • Rivedi gli script di terze parti, come chat, pixel pubblicitari o widget: si contendono tutti lo stesso thread.
  • Rispondi subito con qualcosa di visibile, anche solo un «caricamento», e lascia il lavoro pesante per dopo.
  • Una pagina non troppo grande: più elementi ha, più fatica fa il browser a disegnare ogni cambiamento.

CLS: niente si sposta

  • Larghezza e altezza su ogni immagine e video (width e height, oppure aspect-ratio in CSS), così il browser ne riserva lo spazio (web.dev).
  • Riserva lo spazio a ciò che arriva tardi: annunci, video incorporati o un avviso che compare in alto. Meglio farli galleggiare sopra la pagina che spingere giù il contenuto.
  • Font web con un font di riserva adattato alle loro misure (size-adjust), così il testo non salta quando cambia il font.
  • Anima con transform, non spostando top o left.

Come lo facciamo in Vetro

Il nostro sito è un’esperienza 3D, e la velocità fa parte del design fin dall’inizio:

  • il testo arriva nell’HTML;
  • il logo della schermata di caricamento ha priorità alta e il suo spazio riservato;
  • i font hanno font di riserva adattati alle loro misure;
  • la scena 3D si carica solo se il browser disegna con la scheda grafica e chi visita non ha chiesto di ridurre il movimento. Altrimenti riceve una versione leggera con lo stesso contenuto.

In PageSpeed Insights, che nei nostri test misura senza accelerazione grafica e quindi riceve quella versione leggera, la home ottiene 100 nelle prestazioni su smartphone (misurato il 5 ottobre 2026). È quello che applichiamo a ogni sito che progettiamo.

Domande frequenti

Se il mio sito ha un buon punteggio in PageSpeed Insights, supera le Core Web Vitals? Non per forza. Il punteggio è un test di laboratorio; per Google contano i dati delle tue visite reali degli ultimi 28 giorni.

Perché il punteggio cambia ogni volta che ripeto il test? Perché cambiano le condizioni: la rete, il server o il dispositivo di test (Chrome for Developers). Ripetilo più volte e guarda la tendenza, non un numero isolato.

Cosa faccio se il mio sito ha poche visite e nessun dato sul campo? Segui i dati di laboratorio e correggi ciò che segnalano. Quando le visite saranno sufficienti, Search Console inizierà a mostrare i dati reali.

Fonti

Altro dal blog

hi@wearevetro.comInstagramPrivacyNote legali