Ottenere il verde sui Core Web Vitals è utile. Mantenerlo nel tempo è il vero lavoro. Ogni nuova immagine, font, tag marketing o componente interattivo può spostare le metriche. Per questo la performance non può essere un'attività finale: deve entrare nel workflow di design e sviluppo.
Le metriche centrali sono LCP, INP e CLS. Misurano caricamento percepito, reattività e stabilità visiva. Sono segnali tecnici, ma raccontano una cosa concreta: quanto il sito risulta rapido e affidabile per chi lo usa.
Aggiornamento luglio 2026
Il set stabile dei Core Web Vitals resta LCP, INP e CLS. Le soglie operative sono ancora: LCP entro 2,5 secondi, INP entro 200 ms e CLS massimo 0,1, misurati al 75esimo percentile e separando mobile e desktop. La parte spesso ignorata è proprio questa: Lighthouse da solo non basta, perché INP e regressioni reali richiedono dati di campo.
La best practice 2026 è combinare tre livelli: budget in fase di sviluppo, test lab in CI e RUM in produzione. In lab puoi usare Lighthouse e TBT come proxy per problemi di interattività; in produzione devi misurare web-vitals, CrUX, Search Console o un sistema RUM. Ogni nuova terza parte, banner cookie, font, hero media o script analytics deve avere un costo dichiarato.
Per WordPress e Grav, la disciplina è la stessa: cache server, immagini dimensionate, CSS critico ragionato, JavaScript minimo e nessun plugin solo per un effetto marginale.
LCP: il contenuto principale deve arrivare presto
Largest Contentful Paint misura quando l'elemento principale della pagina diventa visibile. Spesso è un'immagine hero, un titolo grande o un blocco above the fold.
Le azioni più efficaci sono:
- ridurre il Time To First Byte con hosting, cache e CDN;
- comprimere e dimensionare l'immagine hero;
- usare AVIF o WebP dove possibile;
- impostare
fetchpriority="high"sull'immagine critica; - evitare CSS e JavaScript bloccanti;
- precaricare font essenziali senza esagerare.
Un errore comune è ottimizzare immagini secondarie e ignorare quella che decide l'LCP. La prima schermata ha priorità.
INP: meno long task, più reattività
Interaction to Next Paint misura la qualità delle interazioni. Se l'utente clicca, digita o apre un menu, il browser deve rispondere rapidamente.
I problemi INP nascono spesso da JavaScript troppo pesante: bundle grandi, librerie non necessarie, listener costosi, rendering sincrono e terze parti invadenti.
Per migliorare:
- spezza i task lunghi;
- carica script non critici in modo differito;
- elimina librerie usate per micro-funzionalità;
- usa event delegation dove ha senso;
- misura le interazioni reali, non solo Lighthouse;
- rispetta
requestIdleCallbacke scheduling quando opportuno.
Il verde su INP non si compra con un plugin. Si ottiene riducendo lavoro inutile nel main thread.
CLS: layout stabile, utenti meno frustrati
Cumulative Layout Shift misura gli spostamenti inattesi del layout. È una metrica semplice da capire: se un bottone si muove mentre l'utente sta per cliccarlo, l'esperienza è scadente.
Le cause più comuni:
- immagini senza dimensioni;
- iframe e embed senza spazio riservato;
- banner cookie che spingono contenuto;
- font che cambiano misura dopo il caricamento;
- contenuti iniettati sopra elementi già visibili.
La prevenzione è quasi sempre progettuale: definire aspect ratio, riservare spazio e non inserire elementi tardivi sopra il contenuto.
Strumenti di misura
Lighthouse è utile in sviluppo, ma non basta. PageSpeed Insights combina dati di laboratorio e dati reali quando disponibili. Chrome UX Report e strumenti RUM mostrano cosa succede agli utenti veri, su reti e dispositivi diversi.
La differenza è importante: un test locale può essere verde mentre gli utenti mobile su connessione debole hanno un'esperienza lenta. Per decisioni serie servono dati di campo.
Workflow continuo
Un sito resta veloce solo se la performance web diventa una regola di progetto. Imposta budget:
- peso massimo JavaScript;
- numero di font;
- dimensione immagini hero;
- limite script terze parti;
- soglie Lighthouse in CI;
- monitoraggio CWV post-rilascio.
Ogni nuova funzionalità deve rispondere a una domanda: quanto costa in performance e quanto valore porta?
Fonte utile
Conclusione
Core Web Vitals non sono un esercizio per PageSpeed. Sono un modo per proteggere l'esperienza utente da accumuli tecnici invisibili. Il verde si ottiene con buone scelte di progetto; si mantiene con misurazione, budget e disciplina, anche quando il design system introduce motion e componenti ricchi.