Perché il tuo sito è lento: i tre numeri da guardare prima di spendere

“Il sito è lento” è una sensazione, non un dato. E finché resta una sensazione, chi te lo deve
sistemare non sa da dove cominciare: interviene a caso, ti vende un plugin di cache e il mese dopo
sei al punto di prima.

Prima di spendere un euro servono tre numeri. Sono gli stessi tre che guarda Google, si chiamano
Core Web Vitals e misurano tre cose diverse che l’utente percepisce tutte come “lentezza”.

I tre numeri

LCP — Largest Contentful Paint. Quanto ci mette a comparire l’elemento più grande della pagina:
di solito la foto in cima, il banner, o il blocco di testo principale. È il momento in cui il
visitatore smette di guardare una pagina bianca. La documentazione di Google è netta sulla soglia:
“Good LCP values are 2.5 seconds or less, poor values are greater than 4.0 seconds, and anything in
between needs improvement”. Gli elementi che contano per l’LCP sono pochi e precisi: <img>, le
<image> dentro un <svg>, i <video>, gli elementi con un’immagine di sfondo caricata con
url() e i blocchi che contengono testo.

INP — Interaction to Next Paint. Quanto ci mette la pagina a reagire quando qualcuno clicca,
tocca o scrive. Non il caricamento: la reattività. Misura “the latency of all click, tap, and
keyboard interactions that occur throughout the lifespan of a user’s visit”. Sotto i 200
millisecondi la pagina è reattiva, tra 200 e 500 va migliorata, sopra i 500 millisecondi è
lenta. È il numero che spiega perché un cliente clicca due volte su “Invia” e ti arrivano due
richieste di preventivo identiche.

CLS — Cumulative Layout Shift. Quanto ballano i contenuti mentre la pagina si carica. Un layout
shift “occurs any time a visible element changes its position from one rendered frame to the
next”: hai iniziato a leggere, si carica un’immagine sopra il testo, il testo scende, e il tuo
pollice ha appena premuto il pulsante sbagliato. Qui si va sotto 0,1; sopra 0,25 è
considerato scadente. Le cause sono quasi sempre le stesse tre: “images or videos with unknown
dimensions”, “fonts that render larger or smaller than its initial fallback” e “third-party ads
or widgets that dynamically resize themselves”.

Un dettaglio che cambia la lettura: il numero da guardare non è la media, è il 75° percentile
delle visite, separato tra mobile e desktop. Serve a dire “tre visitatori su quattro stanno sotto
questa soglia”. La media nasconde esattamente le persone che poi non ti scrivono.

Il punteggio di PageSpeed non è quel numero

Qui casca quasi tutto il mercato. Apri PageSpeed Insights, vedi un cerchio verde con 92 e concludi
che il sito va bene. Oppure vedi 46 in rosso e ti prendi uno spavento. Sono due errori diversi dello
stesso tipo.

Quel cerchio è il punteggio Lighthouse, che è un test simulato: la stessa pagina caricata da un
server di Google su un dispositivo finto. La documentazione lo dice in una riga:
“CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled
test in the lab”. Il punteggio pesa cinque metriche — Total Blocking Time 30%, LCP 25%, CLS 25%,
First Contentful Paint 10%, Speed Index 10% — e le fasce di colore sono 0-49 rosso, 50-89 arancione,
90-100 verde. È utile per capire cosa sistemare, non per sapere come sta andando il sito.

I dati veri sono l’altra sezione, quella dei visitatori reali: “PSI aggregates new data every day
encompassing the previous 28 days”. Ventotto giorni di persone vere, con il loro telefono e la loro
linea. Se quella sezione dice No Data, non è un errore: significa che il sito non ha abbastanza
traffico perché il campione sia significativo. In quel caso hai solo il laboratorio, e va bene
saperlo.

Cosa si sistema davvero in un giorno

L’LCP è il punto dove il lavoro breve rende di più, perché è scomponibile. Google indica anche come
dovrebbe distribuirsi: “Time to first byte ~40%, Resource load delay <10%, Resource load duration
~40%, Element render delay <10%”. Tradotto: metà del problema è il server che risponde, metà è
l’immagine grande che si scarica. Tutto il resto dovrebbe essere rumore — e se non lo è, hai trovato
il bug.

Tre interventi concreti, nell’ordine in cui li farei:

1. Il tempo di risposta del server (TTFB): è il tempo “between starting navigating to a page and
   when the first byte of a response begins to arrive”. Si sta bene sotto 0,8 secondi, male
   sopra 1,8. Su WordPress qui dentro ci finiscono l’hosting condiviso sovraffollato, i plugin
   che interrogano il database a ogni richiesta e l’assenza di una cache di pagina. Non è un
   Core Web Vital, ma un TTFB alto “can make achieving a 2.5 second LCP challenging, or even
   impossible”: nessuna ottimizzazione delle immagini lo recupera.
2. L’immagine principale. Due errori che vedo praticamente su ogni sito arrivato da un tema
   comprato. Il primo: l’immagine in cima caricata in loading="lazy", perché il plugin l’ha messo
   su tutte. La documentazione è categorica: “Never lazy-load your LCP image, as that will always
   lead to unnecessary resource load delay, and will have a negative impact on LCP”. Il secondo: la
   foto da 3.000 pixel di larghezza caricata così com’è dal telefono e rimpicciolita dal browser.
   Sull’immagine giusta vale invece il contrario — “It’s a good idea to set fetchpriority="high"
   on an <img> element if you think it’s likely to be your page’s LCP element”.
3. Le dimensioni delle immagini nell’HTML. Larghezza e altezza dichiarate: il browser tiene lo
   spazio prima ancora di avere il file, e il CLS scende senza toccare altro. È mezz’ora di lavoro e
   di solito è l’intervento con il rapporto migliore tra fatica e risultato.

Cosa chiedere a chi ci mette le mani

Se affidi il lavoro a qualcuno, la richiesta giusta non è “rendi il sito più veloce”. È: dammi i
tre numeri di adesso, dimmi quale dei tre è fuori soglia e su quale intervieni. E poi gli stessi
tre numeri dopo. Se la risposta parla solo del punteggio di PageSpeed passato da 46 a 88, hai
comprato un cerchio verde, non un sito più veloce — e sono due cose che nella pratica coincidono
molto meno di quanto sembri.

Vale anche il contrario, ed è la parte che nessuno dice volentieri: se i tre numeri sono già dentro
le soglie, il sito non è lento. Il problema è altrove — nei contenuti, nel percorso che porta al
modulo di contatto, in chi arriva sulla pagina. Continuare a ottimizzare millisecondi lì è tempo
speso male.

Se vuoi che guardiamo insieme i numeri del tuo sito prima di decidere cosa cambiare,
scrivici: la misura iniziale è una mezz’ora di lavoro, e serve comunque, anche se poi
non facciamo nient’altro.

Fonti: Web Vitals ·
LCP · INP ·
CLS · TTFB ·
Optimize LCP ·
Lighthouse performance scoring ·
CrUX su PageSpeed Insights