Core Web Vitals: rendere un sito davvero veloce
La velocità non è un lusso: è un fattore di posizionamento su Google e di conversione. Analisi dei Core Web Vitals — LCP, INP, CLS — e delle leve concrete che uso per tenerli nel verde.
«Da me funziona bene» non basta
La trappola classica: lo sviluppatore testa su fibra, un MacBook recente, con la cache calda. L'utente reale, invece, arriva da un cellulare di fascia media, su un 4G capriccioso, con la cache vuota. Tra i due, l'esperienza non ha nulla a che vedere.
I Core Web Vitals esistono per misurare ciò che l'utente vive davvero. Google li ha resi un fattore di posizionamento — e soprattutto prevedono la conversione: ogni secondo di caricamento in più fa scappare visitatori.
Le tre metriche che contano
- LCP (Largest Contentful Paint) — il tempo prima che l'elemento principale (spesso l'immagine o il titolo dell'hero) compaia. Obiettivo: sotto i 2,5 s.
- INP (Interaction to Next Paint) — la reattività: il ritardo tra un clic e la risposta visibile. Obiettivo: sotto i 200 ms. È il nervo della guerra sui siti ricchi di JavaScript.
- CLS (Cumulative Layout Shift) — la stabilità: quei salti di layout che fanno cliccare nel punto sbagliato quando si carica un'immagine o una pubblicità. Obiettivo: sotto 0,1.
Un bel sito lento è un sito fallito. Le prestazioni non sono nemiche del design — sono un vincolo che impone scelte nette.
Le leve che uso
Rendere un sito veloce non ha nulla di magico, è una somma di decisioni:
- Immagini — formato moderno (AVIF/WebP), dimensioni corrette,
lazy loadingsotto la linea di galleggiamento e una riserva di spazio per evitare i salti (CLS). - Font —
font-display: swap, precaricamento dei pesi realmente usati e soprattutto: caricare solo quelli. - JavaScript — inviarne il meno possibile. Il codice più veloce è quello che non si spedisce al browser. Componenti server, caricamento differito del non critico.
- Rendering — privilegiare lo statico (pre-generato in fase di build) quando il contenuto lo permette: niente batte un file già pronto.
- Misurazione continua — un budget di prestazioni e un monitoraggio (Lighthouse, Speed Insights) perché una regressione si veda prima della messa in produzione, non dopo.
Misurare sul campo, non in laboratorio
Ci sono due modi di misurare: i dati di laboratorio (Lighthouse, ambiente controllato) e i dati sul campo (gli utenti reali, tramite il Chrome UX Report). Entrambi sono utili, ma solo il secondo riflette la realtà. Un sito può segnare 100 in laboratorio e deludere sul campo per via di una connessione lenta o di un dispositivo modesto.
La mia disciplina: ottimizzare in laboratorio per andare veloci, ma validare sul campo prima di cantare vittoria.
Perché conta per un cliente
Un sito veloce non è solo una civetteria tecnica. È più visitatori che restano, migliore posizionamento su Google e più conversioni. La velocità è uno dei rari miglioramenti che serve al tempo stesso l'utente, il posizionamento e il fatturato. Per questo la tratto come un'esigenza, non come un bonus.