14 lug 2025·6 min
Misura prima di ottimizzare: il flusso di Paul Irish per la velocità
Misura prima di ottimizzare: loop semplice—baseline, profiling, cambia una cosa, verifica l'impatto—e costruisci l'abitudine calma delle performance.
Misura prima di ottimizzare: loop semplice—baseline, profiling, cambia una cosa, verifica l'impatto—e costruisci l'abitudine calma delle performance.
Il lavoro sulle performance sembra casuale quando inizi con correzioni a caso. Un giorno minimizzi file, il giorno dopo aggiusti la cache, poi rimuovi una libreria. A volte aiuta. A volte nulla cambia e non sai perché.
Il rischio più grande è ottimizzare la cosa sbagliata. Se la pagina è lenta perché il main thread è bloccato dal JavaScript, passare ore a comprimere immagini sposterà appena l'ago. Oppure potresti velocizzare qualcosa che gli utenti non notano mentre il vero ritardo è una chiamata API lunga, un layout che continua a ricalcolare, o un singolo script bloccante.
C'è anche la trappola del giudicare a sensazione. “Sembra più veloce” può derivare da cambiamenti placebo (come uno spinner) o dal testare su una rete, dispositivo o orario diverso. “È più veloce” significa che la stessa azione, nelle stesse condizioni, ha prodotto numeri migliori.
Una promessa semplice risolve la maggior parte: misura prima di ottimizzare, poi decidi. Quando tratti le performance come un problema di misurazione, smetti di indovinare e inizi a imparare.
Un loop pratico è questo: scegli una singola azione utente da migliorare, registra una baseline in condizioni ripetibili, fai una sola modifica spiegabile, poi rimesura e mantieni la modifica solo se i numeri migliorano.
Paul Irish è una delle voci più note nelle performance web. Con il suo lavoro sugli strumenti del browser e le guide sulle performance, ha contribuito a diffondere un'idea semplice: il tuo primo compito non è indovinare cosa è lento, è dimostrarlo.
Questa mentalità cambia la dinamica del team. Invece di litigare partendo da abitudini tipo “sono sempre le immagini” o “dev'essere il framework”, inizi con le prove. Quando puoi indicare una timeline, una query lenta o un long task, la conversazione passa dalla colpa alle correzioni.
“Misura prima di ottimizzare” calma anche i dibattiti sulle performance perché crea regole condivise: concorda cosa stai misurando, cosa significa “meglio” e celebra solo quando i numeri si muovono.
Funziona su siti piccoli e app grandi. Una singola baseline può fermare micro-ottimizzazioni casuali su una pagina marketing. Su un prodotto grande, misure coerenti impediscono che le performance diventino una lista infinita di cose da fare.
Un modo semplice per rendere questo concreto è trattare le performance come un bug: passi chiari per riprodurre, la metrica osservata e una singola modifica legata a un risultato. Se due persone non sono d'accordo, riesegui la misura e lascia decidere i dati.
Tratta le performance prima come un problema di strumentazione: aggiungi modi per osservare ciò che gli utenti effettivamente sperimentano. Se non lo vedi, finirai a discutere opinioni, non prove. Questo è il vero significato di misurare prima.
L'osservazione non deve essere sofisticata. È raccogliere alcuni segnali in modo coerente, negli stessi punti, così puoi rispondere alle domande di base:
Di solito desideri due tipi di dati.
I dati di laboratorio sono catturati in un setup controllato: uno specifico laptop o dispositivo di test, un profilo di rete stabile, gli stessi passi a ogni run. Sono ottimi per il debugging perché puoi riprodurre il rallentamento su richiesta.
I dati reali degli utenti sono ciò che le persone sperimentano nel mondo reale: dispositivi, posizioni e qualità di connessione differenti. Sono ottimi per la prioritizzazione perché mostrano cosa danneggia gli utenti reali, non solo un singolo test.
Anche senza essere esperti puoi misurare milestone del caricamento (come il primo contenuto visibile), long task e blocchi del main-thread, richieste di rete lente, lavoro di rendering costoso (layout, style, paint) e tempo di risposta del server.
Questi segnali vivono tipicamente in pochi posti: gli strumenti di sviluppo del browser per il profiling in laboratorio, i log e i trace del server per i tempi backend, e dashboard di analytics o RUM per i dati reali. Per esempio, se il checkout sembra lento, DevTools potrebbe mostrare che il browser è impegnato a renderizzare una grande UI del carrello mentre i log server mostrano che l'API è veloce. Senza strumentazione, potresti ottimizzare il backend e non risolvere il problema reale.
Per misurare prima di ottimizzare, hai bisogno di un punto di partenza affidabile. Una baseline è la stessa azione, misurata nello stesso modo, nelle stesse condizioni.
Inizia con un percorso utente reale, non “l'intero sito”. Scegli qualcosa che puoi descrivere in una frase, per esempio “apri la home e scorri fino alla prima griglia di prodotti” o “effettua il login e raggiungi la dashboard.” Mantenerlo stretto rende i numeri più stabili e i passi successivi più chiari.
Poi scegli 1–3 metriche che corrispondono al percorso. Per una visualizzazione di pagina, una coppia comune è LCP (quanto velocemente appare il contenuto principale) e TTFB (quanto velocemente risponde il server). Per un flusso come il checkout, potresti tracciare il tempo per completare il passo 1 più il tempo di risposta API per la chiamata di pagamento. Troppe metriche rendono facile selezionare quelle che favoriscono il risultato.
Scrivi il setup del test così qualcun altro può riprodurlo più tardi. Piccole differenze possono influenzare i risultati:
Infine, definisci “abbastanza buono” per il tuo pubblico. Per esempio: “LCP sotto 2.5s su uno smartphone di fascia media, in 4G.” Se usi Koder.ai, fare uno snapshot prima dei test aiuta a collegare la baseline a una versione nota.
Prima di profilare, fai succedere di nuovo il problema su richiesta. Se non riesci a ripeterlo, non puoi fidarti del risultato.
Parti da ciò che gli utenti sentono, non da ciò che presumono. È un primo render lento? Un clic che resta appeso prima che qualcosa cambi? Una lunga attesa dopo l'invio di un form? Scegli il momento che gli utenti segnalano e concentrati lì.
Esegui una prova rapida per confermare che il rallentamento è reale e ripetibile. Mantieni tutto il resto uguale: stessa pagina, stesso dispositivo, stessa rete se possibile. Poi annota il trigger e il momento esatto in cui si percepisce il rallentamento, come “dopo aver cliccato Pay, il pulsante si blocca per un secondo” o “lo scrolling scatta quando appare la lista prodotti.”
Un modo semplice per mantenere la ripetibilità è uno script minimo: apri la pagina da una nuova scheda, esegui l'azione lenta, nota il punto esatto in cui rallenta, poi ripeti una volta per confermare.
Cattura una o due registrazioni baseline, non dozzine. Vuoi solo abbastanza prove per dire: “Sì, il rallentamento succede, e succede proprio qui.”
Una volta che puoi riprodurre il rallentamento, smetti di indovinare. Apri un profiler (per la maggior parte delle persone, il pannello Performance del browser) e registra una run dell'interazione lenta. L'obiettivo non è trovare ogni singolo problema. È capire dove va il tempo.
Inizia dai blocchi di tempo più grandi. Picchi piccoli possono essere reali, ma raramente spiegano da soli un ritardo percepibile.
Un modo utile di leggere una registrazione è raggruppare il tempo in poche categorie: rete e caricamento (attesa su richieste), scripting sul main thread (long task), rendering e paint (layout e style), gap inattivi (in attesa di qualcos'altro), e lavoro ripetuto (la stessa operazione costosa che si ripete).
Un errore comune è confondere una risposta server lenta con lavoro client pesante. Se la timeline mostra lunghe pause mentre le richieste sono in volo, il collo di bottiglia può essere network o backend. Se mostra long task sul main thread, hai un problema front-end anche se la rete è veloce.
Prima di cambiare qualcosa, scrivi una breve ipotesi testabile basata su ciò che hai visto. Per esempio: “La pagina sembra lenta perché il main thread è bloccato dal parsing JSON subito dopo l'arrivo della risposta API.” Quella frase prepara il passo successivo.
Dopo aver identificato il probabile collo di bottiglia, resisti alla tentazione di “risolvere tutto”. Cambia una variabile così puoi collegare causa ed effetto.
Mantieni la modifica piccola e facile da annullare. Riscritture grandi sfocano il risultato: se le performance migliorano, non saprai perché. Se peggiorano, il rollback diventa rischioso.
Buone modifiche “una cosa” sono specifiche e testabili. Esempi: deferire o rimuovere un singolo script di terze parti che blocca il rendering, comprimere un'immagine troppo grande su quella pagina lenta, aggiungere caching a una query DB costosa, splittare un componente UI pesante in modo che renda meno lavoro all'avvio, o ridurre il lavoro in un loop caldo che hai visto nel profiler.
Prima di toccare il codice, annota cosa hai cambiato, perché lo hai scelto e cosa ti aspetti che migliori (per esempio, “ridurre il tempo sul main-thread” o “tagliare in metà il tempo del DB”).
Se il tuo team usa una piattaforma che supporta snapshot e rollback (come Koder.ai), fai uno snapshot subito prima della modifica così “piccolo e reversibile” è reale, non solo aspirazionale.
Hai cambiato una cosa. Ora dimostra che ha aiutato.
Riesegui esattamente lo stesso setup usato per la baseline: stesso dispositivo, stessa versione del browser, stesso percorso e flow, e lo stesso numero di esecuzioni. Confronta prima vs dopo usando le stesse metriche. Non aggiungere nuove metriche a metà strada solo perché sembrano migliori.
Il rumore è la ragione più comune per cui i team discutono sulle performance. Fai attenzione a cache calda vs fredda, estensioni o processi in background, condizioni di rete diverse o VPN, varianza del server (minuto tranquillo vs minuto occupato) e la differenza tra “subito dopo il deploy” e stato stazionario.
Se la mediana migliora ma il worst-case peggiora, è un tradeoff reale. Decidi cosa conta per i tuoi utenti, poi documenta la decisione: mantieni la modifica, ripristina o scrivi una nuova ipotesi e testa ancora.
Il lavoro sulle performance si confonde quando misuri la cosa sbagliata o cambi troppe cose in una volta. Puoi bruciare molte energie senza avere un miglioramento chiaro, anche se la tua app migliora.
Un errore comune è trattare un singolo punteggio come obiettivo. I punteggi possono essere utili, ma gli utenti non sperimentano “un 92”. Sperimento “la pagina mostra contenuto in 2 secondi” o “toccando Compra risponde subito”. Scegli un risultato visibile all'utente e misuralo coerentemente.
Un'altra trappola è testare solo su un laptop potente. Molti rallentamenti si vedono su telefoni di fascia media, reti instabili o quando la CPU è occupata. Se profili solo sul tuo miglior dispositivo, puoi perdere il collo di bottiglia.
La confusione spesso deriva da pattern come migliorare ciò che è più facile invece di ciò che richiede più tempo, raggruppare più tweak in un'unica modifica, cambiare percorso di test a ogni run, saltare un retest perché “sembra più veloce”, o dichiarare vittoria senza rieseguire la stessa baseline.
Se costruisci l'app con una piattaforma guidata da chat come Koder.ai, la stessa disciplina vale: una modifica, poi verifica sullo stesso flow esatto così puoi fidarti del risultato.
Se mantieni una sola abitudine, mantieni questa: misura prima di ottimizzare. Lo scopo non è accumulare dati infiniti. È un loop ripetibile di cui ti puoi fidare.
Nomina il percorso utente esatto che ti interessa. “Homepage lenta” è vago. “Dal product page al clic su Compra fino alla conferma” ti dà un percorso ripetibile.
Usa questa checklist:
La versione calma del lavoro sulle performance è semplice: un percorso, un setup, una modifica, un risultato verificato.
Una lamentela comune: il checkout è lento subito dopo che il cliente clicca “Pay.” Le persone iniziano a indovinare (immagini, font, il pulsante). Invece, trattalo come un test ripetibile.
Definisci una baseline che puoi rieseguire. Scegli un dispositivo e un percorso (carrello → checkout → Pay → conferma). Attiva il throttling di rete (per esempio, Fast 3G) e mantienilo uguale a ogni run. Misura un numero semplice: tempo dal clic su “Pay” alla schermata di conferma.
Poi profila lo stesso momento e guarda dove va il tempo. Di solito decidi tra tre categorie: rete (una richiesta lunga o troppe richieste), server (la chiamata di pagamento è lenta mentre il browser è inattivo), o main thread (il browser è occupato a eseguire JavaScript e non può aggiornare l'UI).
Immagina che il profilo mostri che dopo il clic su “Pay” il browser invia una chiamata analytics e un script di fraud-check, e la richiesta di pagamento resta in coda dietro di loro. Non è un problema “rendere tutto più veloce”. È un singolo passo che blocca.
Fai una sola modifica intenzionale. Per esempio, lascia partire immediatamente la richiesta di pagamento e invia l'analytics solo dopo che la schermata di conferma è mostrata.
Verifica con lo stesso setup: stesso throttling, stessi passi, più run. Se il tempo di conferma diminuisce e gli errori non aumentano, hai un vero miglioramento. Controlla anche che non hai rotto rimborsi, retry o protezioni da doppio invio.
Le performance restano sotto controllo quando sono una routine, non una missione di salvataggio. Fai della misurazione l'azione predefinita, anche quando tutto sembra a posto.
Scegli un piccolo set di metriche che il team traccerà sempre. Mantienile coerenti così le tendenze sono facili da vedere:
Costruisci un loop attorno a quelle metriche. Un controllo settimanale della baseline è spesso sufficiente. Quando una metrica deriva, quello è il trigger per riprodurre il rallentamento, profilare, fare una modifica e verificarne l'impatto.
Tieni un semplice registro delle performance nel formato che il tuo team usa davvero. Registra cosa hai misurato (inclusi dispositivo, rete e build), cosa hai cambiato e come sono cambiati i numeri.
Se costruisci con Koder.ai, Planning Mode può aiutarti a scrivere il percorso utente e la metrica che ti interessa prima di cambiare qualcosa. Poi usa snapshot e rollback per mantenere gli esperimenti sicuri: snapshot, applica una modifica, ritesa e rollback se il risultato è rumoroso o peggiore.
In planning o review, una domanda mantiene la cultura sana: “Cosa abbiamo misurato e cosa è cambiato?”
Perché puoi facilmente passare ore a migliorare qualcosa che in realtà non sta causando il rallentamento. Comincia dimostrando dove va il tempo (network, server, main thread, rendering), poi indirizza il collo di bottiglia più grande.
Scrivi una singola azione e le condizioni esatte, poi ripetila:
Se non riesci a ripeterlo, non puoi fidarti del risultato.
Scegli 1–3 metriche che corrispondono a ciò che gli utenti notano:
I dati di laboratorio sono controllati e ripetibili (ottimi per il debugging). I dati reali degli utenti riflettono dispositivi e reti reali (ottimi per la priorizzazione).
Una buona pratica: usa i dati reali per trovare i percorsi peggiori, poi usa il profiling in laboratorio per spiegare perché sono lenti e testare le correzioni in sicurezza.
Trattalo come un bug report:
Questo sposta la conversazione dalle opinioni (“devono essere le immagini”) alle prove.
Registra l'interazione lenta in un profiler e cerca il blocco di tempo più grande:
Poi scrivi un'ipotesi in una frase che puoi testare.
Mantiene chiaro causa ed effetto. Se cambi cinque cose e la pagina è più veloce, non saprai cosa ha funzionato. Se peggiora, il rollback è complicato.
Regola pratica: una sola modifica che puoi spiegare, una metrica che ti aspetti che cambi, poi rimesura.
Esegui lo stesso setup di test e confronta prima/dopo usando le stesse metriche.
Per ridurre il rumore:
Mantieni la modifica solo se i numeri migliorano nelle stesse condizioni.
Trappole comuni:
Attieniti a un percorso, un setup e un risultato verificato.
Usali per rendere gli esperimenti sicuri e confrontabili:
Gli strumenti aiutano, ma il vero vantaggio è il loop ripetibile: baseline → profile → una modifica → verifica.
Evita di tracciare troppi numeri insieme o finirai per scegliere quelli che ti favoriscono.