PageSpeed Insights e Lighthouse dicono se una pagina è lenta e suggeriscono dove intervenire. Ma quando si tratta di capire perché un LCP arriva tardi, quale script blocca un clic, quale elemento provoca uno spostamento del layout, serve uno strumento che mostri cosa fa il browser, millisecondo per millisecondo. È il pannello Performance dei DevTools di Chrome, lo stesso strumento che usano gli sviluppatori dei browser e gli specialisti di prestazioni.
A prima vista è intimidatorio: decine di tracce colorate, termini tecnici, migliaia di eventi. In realtà, per la maggior parte delle diagnosi bastano poche funzioni, usate con metodo. In questa guida vediamo come preparare una registrazione affidabile, come leggerla e come usarla per diagnosticare i problemi delle tre Core Web Vitals.
Prima di registrare
Una registrazione è utile solo se riproduce condizioni realistiche. Tre accorgimenti fanno la differenza:
- una finestra pulita: le estensioni del browser eseguono codice su ogni pagina e compaiono nella registrazione, confondendo la diagnosi. Una finestra in navigazione in incognito o un profilo ospite, senza estensioni, evita il problema;
- il rallentamento della CPU: il computer di uno sviluppatore è molte volte più veloce dello smartphone medio. Il pannello permette di rallentare la CPU di quattro o sei volte, e le versioni recenti propongono valori calibrati sulla macchina in uso per simulare dispositivi di fascia bassa e media. Senza rallentamento, molti problemi semplicemente non si vedono;
- il rallentamento della rete: per i problemi di caricamento, come l’LCP, conviene simulare una connessione mobile. Per i problemi di interazione, come l’INP, la rete conta meno e si può lasciare senza limiti.
Quando si apre il pannello, prima ancora di registrare, le versioni recenti di Chrome mostrano una vista con le metriche in tempo reale: LCP, CLS e INP misurati sulla pagina mentre la si usa, con la possibilità di confrontarli con i dati reali degli utenti provenienti dal Chrome UX Report. È un buon punto di partenza: permette di capire subito se il problema che si sta cercando si riproduce sul proprio computer con le impostazioni scelte, e se le condizioni della prova sono paragonabili a quelle degli utenti.
Registrare un caricamento
Per analizzare il caricamento si usa il pulsante che ricarica la pagina e registra: il browser svuota la registrazione, ricarica la pagina e si ferma poco dopo la fine del caricamento. Conviene decidere prima se si vuole studiare una prima visita, con la cache vuota, o una visita successiva: i risultati sono molto diversi, e la prima visita è di solito quella più critica. La cache si può disattivare dal pannello Rete durante la registrazione.
Per analizzare un’interazione si avvia invece la registrazione normale, si compie l’azione sulla pagina, come aprire un menu o applicare un filtro, e si ferma la registrazione. Registrazioni brevi sono più facili da leggere: pochi secondi, concentrati sull’azione che interessa.
Leggere la registrazione
La registrazione si presenta come una serie di tracce orizzontali allineate sullo stesso asse temporale. Le più importanti sono cinque.
La panoramica, in alto, mostra l’attività della CPU nel tempo, con i colori delle diverse attività, e una sequenza di schermate della pagina. Serve a orientarsi: si vedono subito i momenti in cui il browser è impegnato e si può selezionare un intervallo per ingrandirlo.
Le tracce della rete e dei tempi mostrano le richieste nel tempo, come un waterfall compatto, e i momenti chiave del caricamento, tra cui FCP e LCP. Selezionando il riferimento dell’LCP, il pannello indica quale elemento è stato considerato il più grande.
La traccia delle interazioni mostra ogni clic, tocco o pressione di tasto registrata, con la sua durata complessiva. Le interazioni lente sono evidenziate.
Il main thread è il cuore della registrazione. Il lavoro è rappresentato come un grafico a fiamma: ogni rettangolo è un’attività, la larghezza è la durata, e i rettangoli sottostanti sono le funzioni chiamate da quello sopra. I colori indicano il tipo di lavoro: giallo per l’esecuzione di script, viola per il calcolo degli stili e del layout, verde per il disegno. I task che superano i 50 millisecondi, i task lunghi, sono segnati con un triangolo rosso e con la parte eccedente evidenziata.
Il pannello inferiore mostra i dettagli di ciò che è selezionato. La scheda di riepilogo divide il tempo tra le categorie di attività. La scheda che raggruppa dal basso elenca le funzioni che hanno consumato più tempo, e permette di raggrupparle per dominio o per prodotto: è il modo più rapido per vedere quanto pesano gli script di terze parti. L’albero delle chiamate mostra la stessa informazione partendo dall’alto, e il registro degli eventi elenca le attività in ordine cronologico.
Gli approfondimenti automatici
Le versioni recenti del pannello affiancano alla registrazione una colonna di approfondimenti, derivati in buona parte dagli audit di Lighthouse ma collegati direttamente alla traccia: la scomposizione dell’LCP nelle sue fasi, le risorse che bloccano il rendering, la scoperta della richiesta dell’elemento LCP, le cause degli spostamenti di layout, l’impatto delle terze parti, la dimensione del DOM, i ricalcoli forzati del layout. Selezionando un approfondimento, il pannello evidenzia nella registrazione gli eventi corrispondenti. Per chi è alle prime armi è il modo migliore per entrare nella registrazione: si parte da un problema segnalato e si vede dove si trova.
Diagnosticare l’LCP
Per l’LCP la domanda è: dove è andato il tempo tra la richiesta della pagina e la comparsa dell’elemento più grande? Il pannello lo divide in quattro fasi. Il tempo fino al primo byte dice quanto ha impiegato il server. Il ritardo di caricamento è il tempo tra il primo byte e l’inizio del download della risorsa dell’elemento LCP, per esempio l’immagine principale: se è lungo, l’immagine è stata scoperta tardi, perché caricata da uno script, indicata solo nel CSS o rallentata dal lazy loading. La durata di caricamento è il tempo di download della risorsa: se è lunga, la risorsa è troppo pesante o la connessione è lenta. Il ritardo di rendering è il tempo tra la fine del download e la comparsa: se è lungo, il main thread era occupato o il rendering era bloccato da fogli di stile e script.
Sapere quale fase domina indica subito la direzione: il server e la cache nel primo caso, la priorità e la scoperta della risorsa nel secondo, il peso dell’immagine nel terzo, il CSS e il JavaScript nel quarto.
Diagnosticare il CLS
Per il CLS il pannello offre una traccia dedicata agli spostamenti di layout, raggruppati nelle finestre usate per il calcolo della metrica. Selezionando uno spostamento, il pannello indica quali elementi si sono mossi e, quando riesce a individuarla, la causa probabile: un’immagine senza dimensioni, un carattere web che cambia le metriche del testo, un contenuto inserito dinamicamente. Le schermate della panoramica, osservate a cavallo dello spostamento, aiutano a capire cosa è successo sullo schermo.
Diagnosticare l’INP
Per l’INP si registra l’interazione lenta e la si seleziona nella traccia delle interazioni. Il pannello la divide in tre fasi, ciascuna con un rimedio diverso.
Il ritardo di input è il tempo in cui l’interazione ha atteso che il main thread si liberasse. Se è lungo, basta guardare nel main thread cosa stava succedendo al momento del clic: spesso è uno script di terze parti, un timer o il completamento del caricamento. L’elaborazione è l’esecuzione dei gestori dell’evento: il grafico a fiamma mostra quali funzioni hanno richiesto più tempo, e se il codice legge e modifica alternativamente il layout, il pannello segnala i ricalcoli forzati. La presentazione è il lavoro necessario a mostrare il risultato: calcolo degli stili, layout, disegno. Se è lunga, di solito la pagina ha un DOM molto grande o la modifica coinvolge molti elementi, come visto negli articoli sul costo del DOM e sul CSS moderno.
Gli strumenti che lo affiancano
Il pannello Performance non lavora da solo. Il pannello Rete permette di esaminare nel dettaglio le singole richieste, le intestazioni, le priorità e i tempi di connessione. Il pannello Rendering, raggiungibile dal menu dei DevTools, evidenzia sullo schermo le aree ridisegnate e gli spostamenti di layout mentre si usa la pagina, ed è utile per individuare a colpo d’occhio le animazioni costose. Il pannello Coverage mostra quanta parte del CSS e del JavaScript scaricati viene effettivamente usata. Lighthouse, integrato negli stessi DevTools, offre il quadro d’insieme con i suoi audit, mentre il pannello Performance permette di verificare nel dettaglio ciò che gli audit segnalano: come spiegato nell’articolo sulle differenze tra PageSpeed Insights e Lighthouse, sono strumenti complementari, non alternativi.
Gli errori più comuni
- registrare senza rallentamento: su un computer veloce tutto sembra rapido, e si conclude che il problema non esiste;
- fidarsi di una sola registrazione: i tempi variano da una prova all’altra. Per confrontare un prima e un dopo servono più registrazioni, osservando la tendenza e non il singolo valore;
- confondere laboratorio e campo: la registrazione mostra cosa succede sul proprio computer, in condizioni simulate. Come spiegato a proposito di CrUX e dati di laboratorio, è uno strumento di diagnosi: il giudizio finale spetta ai dati degli utenti reali;
- perdersi nei dettagli: una registrazione contiene migliaia di eventi, e studiarli tutti è inutile. Conviene partire dalla metrica da migliorare, trovare il momento corrispondente e risalire alla causa;
- dimenticare le estensioni: un blocco di pubblicità o un gestore di password possono aggiungere lavoro che gli utenti non hanno, o eliminare script che gli utenti invece eseguono.
Salvare e condividere
Una registrazione si può salvare come file e riaprire in seguito, anche su un altro computer. È utile per documentare lo stato di una pagina prima di un intervento, per confrontarlo con quello successivo, e per condividere una diagnosi con uno sviluppatore o un fornitore. Le versioni recenti permettono anche di aggiungere annotazioni direttamente sulla registrazione, evidenziando un intervallo o collegando due eventi, così che chi la riceve sappia subito dove guardare. Va ricordato che una registrazione può contenere indirizzi, parametri e schermate della pagina: se la pagina mostra dati riservati, va condivisa con attenzione.
Un esempio concreto
Un sito di annunci riceve dal rapporto di Search Console la segnalazione di un INP scarso sulle pagine di ricerca. In laboratorio, senza rallentamento, i filtri sembrano rispondere subito. Con la CPU rallentata di quattro volte e una registrazione durante l’applicazione di un filtro, l’interazione dura quasi 400 millisecondi. La scomposizione mostra un ritardo di input importante, dovuto a uno script di chat che esegue un task lungo ogni pochi secondi, e un’elaborazione lunga, in cui il gestore del clic ricostruisce l’intera lista dei risultati. La scheda che raggruppa per prodotto conferma che lo script di chat occupa una parte rilevante del main thread. Gli interventi sono chiari: caricare la chat solo quando l’utente la apre, e aggiornare solo gli elementi della lista che cambiano. Una seconda serie di registrazioni conferma il miglioramento, e nelle settimane successive i dati reali lo verificano.
In sintesi
Il pannello Performance mostra cosa fa il browser durante il caricamento e le interazioni, ed è lo strumento che trasforma un punteggio in una diagnosi. Per usarlo bene servono condizioni realistiche, cioè una finestra senza estensioni e la CPU rallentata, e un metodo: partire dalla metrica da migliorare, trovare il momento corrispondente nella registrazione, scomporlo nelle sue fasi e risalire alla causa nel main thread. Gli approfondimenti automatici e la vista delle metriche in tempo reale rendono l’ingresso più semplice. Il resto è pratica: dopo qualche registrazione, le tracce colorate diventano una mappa leggibile di dove va il tempo.
