# 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.

> Pagina: https://ui.eneawork.it/blog/come-usare-chrome-devtools-performance
> Markdown: https://ui.eneawork.it/blog/come-usare-chrome-devtools-performance.md

*2026-11-01*

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.

Cinque caricamenti headless di /blog/lighthouse-ci-soglie su ui.eneawork.it il 1 novembre 2026, viewport 1366x900, CPU rallentata 4x, cache disattivata: mediana FCP 1.092 ms, LCP 1.372 ms, TBT 44 ms, 2 long task oltre 50 ms, 553 nodi nel DOM. Il catalogo EneUI misura 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, misurati da /api/stats il 1 novembre 2026.

## 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

## 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.

## FAQ

### 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é.