LCP: l’immagine sbagliata
Hero da due megabyte, non dimensionata, servita senza formato moderno. Spesso bastano AVIF o WebP, dimensioni corrette e priorità alta.
Guide · Performance
Velocità
percepita, non dichiarata.
Un sito può essere “ottimizzato” e risultare lento a chi lo usa. I Core Web Vitals misurano l’esperienza reale: quanto ci mette a comparire il contenuto, quanto risponde al tocco, quanto si sposta la pagina.
01
Tre misure, un’idea semplice
LCP (Largest Contentful Paint) misura quando compare l’elemento principale della pagina. INP (Interaction to Next Paint) misura quanto ci mette l’interfaccia a rispondere a un clic o a un tocco. CLS (Cumulative Layout Shift) misura quanto il contenuto si sposta mentre la pagina si carica.
Sono tre cose diverse e vanno corrette in modo diverso. Un sito può avere un LCP eccellente e un INP pessimo: capita quando l’HTML arriva subito ma il JavaScript principale pesa e blocca le interazioni.
02
Le soglie di riferimento
Sono le soglie ufficiali, valutate sul 75° percentile degli utenti reali in una finestra di 28 giorni.
| Metrica | Buono | Da migliorare | Scarso |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5 - 4 s | > 4 s |
| INP | ≤ 200 ms | 200 - 500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1 - 0,25 | > 0,25 |
03
Le cause che vediamo più spesso
LCP: server e font
Un TTFB alto o un font che blocca il testo per centinaia di millisecondi. La prima misura è quasi sempre lato infrastruttura.
INP: JavaScript che lavora male
Task lunghi, listener pesanti, librerie caricate per una funzione sola. Meno codice significa interazioni più rapide.
CLS: spazio non riservato
Immagini senza width e height, banner inseriti dopo, font con metriche diverse. Lo spazio si riserva prima, non si rincorre dopo.
04
Come si misurano
davvero.
I dati che contano sono quelli di campo: utenti reali, 75° percentile, finestra mobile di 28 giorni. Search Console li mostra senza installare nulla; per il dettaglio si usa un sistema di monitoraggio con beacons leggeri.
Lighthouse e PageSpeed Insights servono per capire, non per certificare. Un punteggio di 100 in laboratorio, con rete simulata, non garantisce che il sito sia veloce su un telefono vero in mezzo al traffico.
- Dati di campo prima, laboratorio dopo
- 75° percentile, non media
- Misure separate per mobile e desktop
- Confronto prima e dopo ogni rilascio
- Soglie condivise con chi sviluppa
05
Da dove si parte
Prima il server: tempo di risposta, cache, compressione. Poi le risorse che bloccano il rendering: CSS critico, font, script. Poi le immagini. Infine le rifiniture, che spesso valgono meno del previsto.
Una regola che usiamo: ogni intervento deve avere una misura prima e una dopo. Se non cambia nulla, si torna indietro. Ottimizzare senza misurare è decorazione.
La promessa che non facciamo
Non promettiamo un punteggio. Promettiamo che il sito risponda meglio, misurato sugli utenti che lo usano. Il punteggio è un mezzo, non il risultato.
FAQ Domande frequenti
Le risposte
che servono.
I Core Web Vitals sono un fattore di posizionamento?
Sì, come esperienza di pagina. Non sono l’unico e raramente battono un contenuto che risponde meglio. Contano di più quando due pagine sono simili per rilevanza.
Che differenza c’è tra INP e FID?
FID misurava solo il ritardo della prima interazione. INP misura tutte le interazioni e considera anche il tempo di disegno: è più severo e più realistico. Ha sostituito FID nel 2024.
Devo rifare il sito per migliorarli?
No. Nella maggior parte dei casi si interviene su immagini, font, JavaScript e cache. Il rifacimento si valuta quando tema o page builder producono più problemi di quanti se ne possano correggere.
Quanto tempo serve per vedere il miglioramento?
I dati di campo si aggiornano con una finestra di 28 giorni: un intervento si vede gradualmente, non il giorno dopo.