Sviluppo web

DevTools Performance, pannello per pannello: cosa guardare in un trace

Cinque secondi di registrazione, tre corsie da leggere e un trace esportato da contare con node: cosa guardare davvero nel pannello Performance.

In sintesi

  • Registra con CPU 4x slowdown e cache disattivata, poi leggi solo tre corsie: Frames, Main e Network.
  • Un triangolo rosso nella corsia Main è un long task oltre 50 ms: è lì che l'LCP perde tempo, non nell'immagine.
  • Un trace esportato è JSON con `traceEvents` e `RunTask` in microsecondi: un comando `node` lo trasforma in un numero da report.

Risposta breve: registra cinque secondi nel pannello Performance, poi leggi il trace in tre punti: la corsia Frames, la corsia Main e la corsia Network. Il resto del pannello è dettaglio, e serve solo dopo aver trovato il problema.

Le due impostazioni da mettere prima

Nella barra in alto scegli CPU 4x slowdown e Network Fast 4G: un portatile veloce nasconde i problemi che vede un telefono. Lascia attiva l'opzione che disabilita la cache, altrimenti la seconda registrazione misura la cache e non la pagina.

Le tre corsie che contano

  • Frames: i frame disegnati e quelli persi; un rettangolo rosso è un frame più lungo di 16 ms.
  • Main: le attività JavaScript in ordine cronologico; i triangoli rossi sono long task oltre 50 ms.
  • Network: ordine e durata delle richieste; qui si vede se l'LCP sta aspettando un'immagine.

Contare i long task senza indovinare

# esporta il trace dal pannello (Export trace) e conta i long task
node -e "const t=require('./trace.json');const e=t.traceEvents||t;const tasks=e.filter(x=>x.name==='RunTask'&&x.dur>50000);console.log(tasks.length,'long task; max',Math.max(...tasks.map(x=>Math.round(x.dur/1000))),'ms')"

Un trace esportato è JSON: traceEvents contiene gli eventi, RunTask le attività del thread principale, dur la durata in microsecondi. Il conteggio è lo stesso che leggi nel pannello, ma diventa un numero da mettere nel report.

Le metriche dentro il trace

Il pannello Timings segna LCP, INP e CLS sulla stessa linea temporale. Se l'LCP arriva a 2,9 s e la corsia Main mostra un long task da 400 ms subito prima, il problema è JavaScript e non l'immagine: quello è il punto in cui la misura diventa diagnosi.

Limite dichiarato

Un trace misurato sul tuo portatile non dice cosa vedono gli utenti: è lab data, con rete e CPU simulate. Un long task assente in locale può comparire su un telefono di tre anni, quindi la decisione finale va presa sui dati di campo.

Dove continuare

Nel catalogo trovi il componente gauge, la card con metrica e i blocchi della categoria chart. Per il resto leggi le soglie di Lighthouse CI, la guida a PerformanceObserver e il profiler di React.

Domande frequenti

Quanto deve durare una registrazione?

Quanto l'azione che vuoi misurare, più un secondo prima e uno dopo. Cinque secondi bastano per un caricamento; per un'interazione conviene registrare solo il clic e l'aggiornamento che ne segue.

Che differenza c'è tra long task e frame perso?

Un long task è un blocco del thread principale oltre 50 ms, un frame perso è un frame che non arriva entro 16 ms. Il primo causa il secondo, ma la corsia che li mostra è diversa.

Posso leggere un trace senza Chrome?

Sì, se lo hai esportato: il file è JSON e contiene gli stessi eventi del pannello. Un comando node filtra RunTask e calcola durata e conteggio, utile per confrontare due build.

Perché i numeri cambiano a ogni registrazione?

Perché il trace misura una singola esecuzione, con rete e CPU simulate ma non deterministiche. Registra cinque volte e guarda la mediana: un solo valore non è una misura.

Il pannello Performance sostituisce Lighthouse?

No. Lighthouse dà un punteggio con regole fisse, il pannello dà la causa di un ritardo su una pagina specifica. Servono entrambi: uno per il budget, l'altro per capire perché.