Core Web Vitals: rendere un sito davvero veloce

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.

• 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.

Rendere un sito veloce non ha nulla di magico, è una somma di decisioni:

• Immagini — formato moderno (AVIF/WebP), dimensioni corrette, lazy loading sotto 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.

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.

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.