Core Web Vitals e performance budget: dai dati reali alle priorità
Un performance budget web trasforma le metriche in limiti operativi prima che una regressione raggiunga gli utenti. I Core Web Vitals aiutano a descrivere caricamento, reattività e stabilità visiva, ma diventano utili soltanto se sono misurati su persone reali, segmentati per pagina e dispositivo e collegati a un responsabile.
Il punteggio di un singolo test non è una strategia. Serve un sistema che distingua dati di laboratorio e dati sul campo, individui le esperienze peggiori e impedisca a immagini, script o nuove funzionalità di consumare senza controllo il budget tecnico.
Core Web Vitals: cosa misurano davvero
I Core Web Vitals sono metriche orientate all’esperienza reale. Nel giugno 2025 il set stabile comprende:
- Largest Contentful Paint (LCP): misura quando il contenuto principale visibile è stato renderizzato; la soglia “buona” è fino a 2,5 secondi;
- Interaction to Next Paint (INP): misura la reattività delle interazioni durante la visita; la soglia “buona” è fino a 200 millisecondi;
- Cumulative Layout Shift (CLS): misura gli spostamenti inattesi del layout; la soglia “buona” è fino a 0,1.
La valutazione usa il 75° percentile delle visite. In pratica, almeno il 75% delle esperienze deve rispettare la soglia buona. Questa scelta evita di nascondere una quota significativa di utenti dietro una media favorevole.
LCP, INP e CLS non spiegano automaticamente la causa. Dicono dove l’esperienza è lenta o instabile; l’analisi tecnica deve poi collegare il problema a immagini, font, JavaScript, server, terze parti, rendering o comportamento dell’interfaccia.
Dati reali e laboratorio rispondono a domande diverse
RUM: ciò che accade agli utenti
Il Real User Monitoring raccoglie misure dai browser durante visite effettive. Cattura dispositivi, reti, aree geografiche, percorsi e contenuti che un test controllato non può riprodurre interamente. La guida MDN su RUM e monitoraggio sintetico distingue chiaramente i due approcci: il RUM è utile per tendenze ed esperienze reali, mentre il laboratorio aiuta a isolare regressioni durante lo sviluppo.
Un cruscotto RUM dovrebbe segmentare almeno per:
- template o gruppo di pagine;
- mobile e desktop;
- browser e sistema operativo principali;
- utente nuovo o di ritorno, quando il dato è disponibile in modo legittimo;
- versione o data di rilascio;
- 75° percentile e numerosità del campione.
La media globale può nascondere un checkout lento su mobile o un’area riservata con interazioni pesanti. La priorità nasce dal segmento, non dal colore generale del sito.
Laboratorio: riprodurre e prevenire
Lighthouse, Chrome DevTools e test sintetici eseguono pagine in condizioni controllate. Sono ideali per confrontare due versioni, analizzare waterfall e main thread, simulare reti lente e bloccare una regressione nella pipeline.
Il laboratorio non misura pienamente INP perché manca l’insieme delle interazioni reali; metriche come Total Blocking Time possono però indicare rischi di reattività. Il processo efficace usa il campo per scegliere il problema e il laboratorio per riprodurlo, correggerlo e verificarlo prima del rilascio.
Come definire un performance budget web
Un performance budget è un insieme di limiti applicati a metriche che influenzano la velocità. La guida Performance budgets 101 di web.dev distingue limiti quantitativi, regole di qualità e metriche orientate all’utente.
Il budget dovrebbe includere tre livelli:
1. Risultato percepito
Definire soglie per LCP, INP e CLS per i template critici. Le soglie ufficiali sono una base, non un obiettivo universale: un’applicazione strategica può richiedere margini più severi per assorbire variazioni e future funzionalità.
2. Risorse e complessità
Limitare JavaScript, CSS, immagini, font, richieste e script di terze parti. Questi valori sono controllabili durante la build e aiutano a individuare la causa prima che il dato RUM peggiori.
3. Processo e responsabilità
Per ogni limite servono owner, frequenza, strumento, azione in caso di superamento ed eventuale procedura di eccezione. Un budget senza conseguenze è soltanto una dashboard.
| Voce | Soglia | Segmento | Owner | Azione |
|---|---|---|---|---|
| LCP | 75° percentile entro obiettivo | Landing mobile | Frontend | Analisi hero e critical path |
| INP | 75° percentile entro obiettivo | Area riservata | Product team | Profilazione interazioni |
| CLS | 75° percentile entro obiettivo | Articoli | Design e frontend | Riservare spazi e font |
| JavaScript | KB massimi compressi | Tutti i template | Tech lead | Bloccare bundle regressivo |
Metodo passo passo: dai dati alle priorità
1. Costruire una baseline
Raccogliere almeno alcune settimane di RUM, verificare la qualità del campione e raggruppare le URL per template. Annotare rilasci, campagne e incidenti che possono influenzare il dato.
2. Incrociare impatto e volume
Una pagina lenta con molte visite o un passaggio critico vale più di un’anomalia rara. La priorità combina utenti coinvolti, gravità, valore del percorso e costo della correzione.
3. Cercare la causa
Usare strumenti di laboratorio, Performance API e tracciamenti applicativi. La Performance API documentata da MDN consente di osservare voci della timeline e creare misure specifiche del prodotto, come apertura di un pannello o completamento di un’operazione.
4. Correggere e verificare
Prima del rilascio confrontare build e budget. Dopo il rilascio seguire il segmento RUM interessato e verificare che il miglioramento sia stabile senza danni a funzionalità, accessibilità o conversioni.
Errori frequenti
- Ottimizzare soltanto la home page.
- Confondere un test Lighthouse con l’esperienza reale.
- Usare la media invece del 75° percentile.
- Ignorare dispositivi e connessioni più lenti.
- Aggiungere script di terze parti senza owner e scadenza.
- Ridurre peso sacrificando leggibilità o accessibilità.
- Monitorare metriche senza una soglia di rilascio.
Checklist finale
- RUM attivo sui template più importanti.
- LCP, INP e CLS segmentati e accompagnati dal campione.
- Budget per risorse integrato nella pipeline.
- Owner e azione definiti per ogni soglia.
- Test sintetici riproducibili sulle funzioni critiche.
- Rilasci annotati nel cruscotto.
- Performance, accessibilità e obiettivi di business letti insieme.
Core Web Vitals e performance budget web creano valore quando diventano un processo di prodotto, non un’attività occasionale. Nella mia attività di sviluppo web e applicazioni digitali, collego dati reali, architettura e controllo dei rilasci per ridurre regressioni e costi futuri.
Vuoi trasformare i punteggi in priorità tecniche? Analizziamo architettura, sicurezza e qualità del progetto digitale.