Lighthouse e i report dei Core Web Vitals dicono che cosa è lento; il pannello Performance di Chrome DevTools dice perché. Registra tutto ciò che il browser fa in un intervallo di tempo, dalle richieste di rete all'esecuzione di ogni funzione JavaScript, dal calcolo degli stili al disegno dei pixel. Al primo impatto la schermata è intimidatoria, ma basta imparare a leggerne poche parti per diagnosticare la maggior parte dei problemi.
Preparare una registrazione affidabile
Una misura utile richiede alcune accortezze:
- finestra in incognito o profilo pulito: le estensioni del browser eseguono codice nella pagina e sporcano il profilo;
- CPU rallentata: nelle impostazioni del pannello si può rallentare la CPU di 4 o 6 volte, per avvicinarsi a un telefono di fascia media. Un problema invisibile su un portatile potente diventa evidente;
- rete rallentata, se si studia il caricamento;
- screenshot attivi, per vedere cosa appare sullo schermo in ogni istante.
Per analizzare il caricamento si usa il pulsante che ricarica la pagina e registra fino al termine. Per un'interazione, si avvia la registrazione, si compie l'azione, per esempio aprire un menu, e la si ferma subito dopo: registrazioni brevi sono molto più facili da leggere.
Le tracce principali
Il profilo è organizzato in righe orizzontali, dette tracce, che condividono la stessa linea del tempo:
| Traccia | Cosa mostra |
|---|---|
| Screenshot | Miniature della pagina nel tempo |
| Network | Le richieste, come in un waterfall compatto |
| Frames | I fotogrammi prodotti e quelli persi |
| Interactions | Le interazioni dell'utente e la loro durata |
| Timings | Marcatori come FCP, LCP e misure personalizzate |
| Main | Tutto il lavoro del main thread |
| Worker e altri thread | Lavoro svolto fuori dal main thread |
La traccia Main è quella in cui si passa la maggior parte del tempo.
Leggere la flame chart
Nella traccia Main il lavoro è disegnato come una flame chart: ogni barra è un'attività, la sua larghezza è la durata e le barre sottostanti sono le funzioni chiamate da quella sopra. In cima ci sono i task, le unità di lavoro del browser; sotto, gli eventi, le funzioni e le sottofunzioni.
I task che superano i 50 millisecondi hanno un triangolo rosso nell'angolo e una zona tratteggiata che evidenzia la parte eccedente. Sono i primi da guardare, perché durante un task lungo la pagina non può rispondere all'utente.
I colori aiutano a orientarsi: in giallo lo scripting, in viola il calcolo degli stili e il layout, in verde il disegno e la composizione. Un task in gran parte viola indica un problema di CSS o di DOM, non di JavaScript.
Dal task alla causa
Il metodo che uso nel mio lavoro è sempre lo stesso:
- individuo il task lungo più vicino al problema, per esempio subito dopo il clic nella traccia Interactions;
- lo seleziono e leggo il riquadro Summary, che divide il tempo per categoria;
- scendo nella flame chart fino alle barre più larghe in basso: sono le funzioni che consumano davvero il tempo;
- seleziono la funzione e nel riquadro di dettaglio trovo il file e la riga, cliccabili per aprire il sorgente;
- se è uno script di terze parti, il nome del dominio lo rivela subito.
Per una visione aggregata servono le schede in basso:
- Bottom-Up elenca le funzioni ordinate per tempo proprio, cioè escluse le sottochiamate: rivela le funzioni che costano di più ovunque vengano chiamate;
- Call Tree mostra l'albero delle chiamate dall'alto, utile per capire quale gestore di evento ha originato il lavoro;
- Event Log elenca le attività in ordine cronologico.
In Bottom-Up si può anche raggruppare per dominio o per file, ottenendo in un colpo solo la quota di tempo di ciascuna terza parte.
Segnali da riconoscere
Alcuni schemi ricorrono spesso:
- molte barre viola alternate a gialle in un ciclo: reflow forzati, cioè letture della geometria del DOM dopo modifiche. DevTools li segnala con un avviso sulla voce di layout;
- un unico blocco giallo enorme all'avvio: valutazione di un bundle JavaScript molto grande o idratazione di un framework;
- lunghe barre di Recalculate Style dopo un clic: un cambio di classe su un elemento in alto nella gerarchia che costringe a ricalcolare gli stili di tutta la pagina;
- lavoro di garbage collection frequente: creazione eccessiva di oggetti temporanei, a volte segno di una perdita di memoria.
Misure personalizzate
Per seguire porzioni specifiche del proprio codice, l'API User Timing permette di creare marcatori che compaiono nella traccia Timings:
performance.mark('filtro-inizio');
applicaFiltri();
performance.mark('filtro-fine');
performance.measure('Applicazione filtri', 'filtro-inizio', 'filtro-fine');
La misura appare come una barra con il proprio nome, allineata al lavoro del main thread, e si può raccogliere anche dagli utenti reali con un PerformanceObserver.
Salvare e condividere
Un profilo si può esportare in un file e riaprire in seguito, o inviare a un collega. È il modo migliore per documentare un problema: invece di «il menu è lento», si consegna la registrazione con il task incriminato già individuato.
In sintesi
- Registra in un profilo pulito, con CPU rallentata e registrazioni brevi.
- La traccia Main mostra il lavoro del main thread come flame chart.
- I task con il triangolo rosso sono i primi da analizzare.
- Scendi fino alle barre più larghe in basso e apri file e riga dal dettaglio.
- Usa Bottom-Up per le funzioni più costose e User Timing per misure personalizzate.
