Rendere veloce un sito è un progetto; mantenerlo veloce è un'abitudine. Senza un controllo sistematico, le prestazioni peggiorano poco alla volta: una libreria in più, un'immagine non ottimizzata, un nuovo script di marketing. Nessuna modifica presa da sola sembra grave, ma dopo qualche mese il lavoro di ottimizzazione è stato annullato. Un budget di prestazioni è un insieme di limiti espliciti che il sito non deve superare, verificati automaticamente a ogni modifica.
Che tipo di limiti fissare
I budget si dividono in tre famiglie, con vantaggi diversi:
| Tipo di budget | Esempi | Pregi | Limiti |
|---|---|---|---|
| Quantità | KB di JavaScript, numero di richieste, peso delle immagini | Stabili e facili da misurare | Indiretti rispetto all'esperienza |
| Tempi | LCP, TBT, tempo all'interattività in laboratorio | Vicini a ciò che l'utente percepisce | Variabili tra una misura e l'altra |
| Punteggi | Punteggio di prestazioni di Lighthouse | Sintetici e comprensibili | Nascondono la causa |
Una combinazione efficace usa i budget di quantità come primo filtro, perché sono deterministici e un aumento di peso si vede subito, e i budget di tempo come controllo di sicurezza sulle pagine principali.
Come scegliere i valori
I valori non vanno presi da una tabella generica, ma dal sito stesso:
- misura lo stato attuale delle pagine più importanti, come home, scheda prodotto e articolo;
- se sono già buone, fissa il budget poco sopra i valori attuali, per bloccare ogni peggioramento;
- se sono scarse, fissa il budget sui valori attuali e abbassalo gradualmente man mano che le ottimizzazioni procedono;
- per i tempi, parti dalle soglie dei Core Web Vitals sui dati reali e ricava un obiettivo di laboratorio più severo, perché il laboratorio non rappresenta i dispositivi peggiori.
Lighthouse CI
Lighthouse CI è lo strumento più usato per questo scopo. Si integra nella pipeline di integrazione continua, esegue Lighthouse sulle pagine indicate a ogni modifica e fallisce se le asserzioni non sono rispettate. Una configurazione minima:
{
"ci": {
"collect": {
"url": ["http://localhost:8080/", "http://localhost:8080/prodotto/esempio"],
"numberOfRuns": 3
},
"assert": {
"assertions": {
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"total-blocking-time": ["warn", { "maxNumericValue": 200 }],
"resource-summary:script:size": ["error", { "maxNumericValue": 250000 }]
}
}
}
}
Le asserzioni possono essere di livello error, che blocca la modifica, o warn, che segnala senza bloccare. Conviene iniziare con molte segnalazioni e pochi blocchi, poi irrigidire le regole che si dimostrano affidabili.
Il problema della variabilità
Le misure di tempo variano da un'esecuzione all'altra, anche senza alcuna modifica al codice. Le macchine delle pipeline sono condivise, il carico cambia, la rete simulata non è perfettamente costante. Un budget di tempo troppo stretto produce falsi allarmi, e un controllo che dà falsi allarmi viene presto ignorato o disattivato.
Alcune contromisure pratiche:
- più esecuzioni: con tre o cinque misure per pagina, Lighthouse CI considera un valore rappresentativo invece di una singola misura fortunata o sfortunata;
- margini realistici: lascia uno spazio tra il valore tipico e il limite;
- budget di quantità per i blocchi: i byte di JavaScript non oscillano, quindi sono ideali per le asserzioni di livello
error; - ambiente stabile: dove possibile, usa macchine dedicate o di dimensione costante per le misure.
Limiti di dimensione sul codice
Per i progetti con molto JavaScript esistono strumenti più leggeri che controllano solo il peso dei file prodotti. size-limit, per esempio, legge una configurazione nel package.json e fallisce se un file supera il limite, indicando anche quale dipendenza è cresciuta:
"size-limit": [
{ "path": "dist/app.js", "limit": "120 KB" },
{ "path": "dist/vendor.js", "limit": "90 KB" }
]
Il controllo è rapido, deterministico e si esegue in pochi secondi, quindi può girare anche localmente prima di ogni commit.
Rendere visibile il risultato
Un budget funziona davvero quando chi modifica il codice vede subito l'effetto. Lighthouse CI può pubblicare i report e confrontarli con quelli del ramo principale; molte piattaforme permettono di commentare automaticamente la richiesta di modifica con le differenze di peso e di tempo. Una riga come «JavaScript: +38 KB rispetto al ramo principale» apre una discussione prima che il problema arrivi agli utenti.
Quando un limite viene superato, ci sono tre risposte legittime: ottimizzare la modifica, rinunciare a qualcos'altro per compensare, oppure decidere consapevolmente di alzare il budget, documentando il motivo. Quella da evitare è disattivare il controllo.
Non dimenticare i dati reali
I budget in laboratorio prevengono le regressioni evidenti, ma non vedono tutto: contenuti caricati dal CMS, script aggiunti tramite tag manager o problemi legati a dispositivi specifici sfuggono alla pipeline. Per questo vanno affiancati dal monitoraggio dei dati reali, con avvisi quando il 75° percentile di una metrica peggiora in modo stabile.
In sintesi
- Un budget di prestazioni fissa limiti espliciti e li verifica a ogni modifica.
- Combina budget di quantità, stabili, con budget di tempo sulle pagine principali.
- Ricava i valori dallo stato attuale del sito e abbassali gradualmente.
- Gestisci la variabilità con più esecuzioni, margini realistici e ambienti stabili.
- Rendi visibili le differenze nelle richieste di modifica e affianca i dati reali.
