Core Web Vitals spiegati: LCP, INP e CLS senza gergo

I Core Web Vitals sono tre metriche con cui Google descrive l'esperienza di caricamento, reattività e stabilità visiva di una pagina. Sono diventati un riferimento comune perché traducono sensazioni vaghe ("il sito è lento", "la pagina salta") in numeri misurabili. Conoscerle bene ti permette di intervenire dove serve, invece di inseguire il punteggio di un singolo strumento.

Le tre metriche

LCP – Largest Contentful Paint

Misura il tempo necessario perché il contenuto più grande visibile nella finestra venga disegnato: tipicamente l'immagine principale, un video di copertina o un grande blocco di testo. È un indicatore di quanto velocemente l'utente percepisce che la pagina "è arrivata". La soglia considerata buona è entro 2,5 secondi.

INP – Interaction to Next Paint

Misura la reattività: per le interazioni dell'utente (clic, tocchi, tasti premuti) calcola il tempo tra l'azione e il momento in cui il browser riesce a mostrare un aggiornamento visivo. Il valore riportato rappresenta, in sostanza, le interazioni più lente osservate durante la visita. INP ha sostituito la precedente metrica FID, che misurava solo il ritardo della prima interazione. È considerato buono un valore entro 200 millisecondi.

CLS – Cumulative Layout Shift

Misura la stabilità visiva: quanto gli elementi si spostano inaspettatamente durante la vita della pagina. Il classico esempio è il testo che scende mentre stai per toccare un link, perché sopra si è caricato un banner. È un punteggio senza unità; è considerato buono un valore entro 0,1.

Per valutare un sito si guarda il 75° percentile delle visite reali: almeno tre visite su quattro devono rientrare nella soglia.

Dati di laboratorio e dati di campo

È una distinzione fondamentale e spesso fraintesa.

• Dati di laboratorio: misurazioni simulate su un dispositivo e una rete predefiniti, come quelle di Lighthouse negli strumenti per sviluppatori. Sono ripetibili e ottime per il debug, ma non rappresentano i tuoi utenti.
• Dati di campo: misurazioni raccolte dai browser di utenti reali. Il Chrome User Experience Report e la sezione corrispondente di PageSpeed Insights mostrano questi dati, quando il sito ha abbastanza traffico.

INP, in particolare, dipende da interazioni reali e non si misura bene in laboratorio, dove nessuno clicca. Se i due tipi di dati non coincidono, quelli di campo descrivono l'esperienza vera.

Puoi raccogliere i dati di campo anche in autonomia con la libreria open source web-vitals:

import { onLCP, onINP, onCLS } from 'web-vitals';

function invia(metrica) {
  navigator.sendBeacon('/analytics', JSON.stringify({
    nome: metrica.name,
    valore: metrica.value
  }));
}

onLCP(invia);
onINP(invia);
onCLS(invia);

Come migliorare LCP

L'LCP è spesso un'immagine, quindi gli interventi più efficaci riguardano proprio lei:

1. Scoprila presto: l'immagine principale deve essere nell'HTML iniziale, non inserita da JavaScript o caricata come sfondo CSS che il browser scopre tardi.
2. Non caricarla in modo pigro: loading="lazy" sull'immagine sopra la piega ritarda l'LCP. Usa invece fetchpriority="high".
3. Riduci il peso: formati moderni come WebP o AVIF e dimensioni adeguate allo schermo.
4. Accorcia il tempo di risposta del server: una pagina servita da cache o da CDN parte prima.
5. Elimina le risorse che bloccano il rendering: CSS enorme e script sincroni nell'head ritardano tutto.

<img src="/hero.avif" width="1200" height="600"
     fetchpriority="high" alt="Descrizione dell'immagine">

Come migliorare INP

Un INP alto significa quasi sempre che il thread principale del browser è occupato da JavaScript quando l'utente interagisce.

• Spezza i compiti lunghi: un ciclo che dura centinaia di millisecondi blocca ogni risposta. Dividilo in parti e cedi il controllo al browser tra una parte e l'altra.
• Fai prima l'aggiornamento visivo: nel gestore di un clic, mostra subito il feedback (per esempio uno stato "in caricamento") e rimanda il lavoro pesante.
• Riduci il JavaScript di terze parti: widget, tracciamenti e chat incorporate competono per lo stesso thread.
• Evita aggiornamenti del DOM enormi: ridisegnare migliaia di nodi a ogni tasto premuto costa caro.

bottone.addEventListener('click', async () => {
  bottone.textContent = 'Elaborazione…';
  await new Promise(r => setTimeout(r, 0)); // lascia disegnare il browser
  elaboraDati();
});

Come migliorare CLS

Gli spostamenti di layout nascono quasi sempre da spazio non riservato:

• indica width e height (o aspect-ratio) su immagini, video e iframe, così il browser riserva lo spazio prima del download;
• riserva un'area con altezza minima per banner, annunci e contenuti incorporati;
• non inserire contenuti sopra quelli già visibili, salvo in risposta a un'azione dell'utente;
• gestisci i web font in modo che la sostituzione del carattere non cambi troppo le dimensioni del testo;
• per le animazioni usa transform e non proprietà come top o height, che spostano gli altri elementi.

Una prospettiva sana

Le metriche sono un mezzo, non il fine. Un punteggio perfetto in laboratorio con dati di campo mediocri non serve a nulla, e un piccolo peggioramento di una metrica può essere accettabile se porta una funzione davvero utile. Concentrati sulle pagine con più traffico e sui problemi che i dati reali mostrano con maggiore frequenza.

In sintesi

• LCP misura il caricamento del contenuto principale, INP la reattività, CLS la stabilità visiva.
• Le soglie buone sono 2,5 secondi, 200 millisecondi e 0,1, valutate sul 75° percentile.
• I dati di campo descrivono gli utenti reali; quelli di laboratorio servono al debug.
• Per l'LCP conta soprattutto l'immagine principale; per l'INP il JavaScript sul thread principale.
• Il CLS si risolve riservando lo spazio agli elementi che arrivano dopo.