Tra tutti gli strumenti di analisi delle prestazioni, il grafico a cascata delle richieste di rete, il cosiddetto waterfall, è probabilmente il più ricco di informazioni e il meno letto. Punteggi e metriche dicono se una pagina è lenta; il waterfall dice perché. Mostra ogni risorsa scaricata, quando il browser l’ha scoperta, quanto ha aspettato, quanto ha impiegato il server a rispondere, quanto è durato il download e in che ordine tutto è avvenuto. Chi impara a leggerlo trova in pochi minuti problemi che nessun report automatico descrive con la stessa chiarezza.
In questo articolo vediamo dove trovare il waterfall, come leggerne ogni parte, quali schemi ricorrenti indicano un problema e come usarlo per verificare che un intervento abbia davvero funzionato. Gli esempi si riferiscono al pannello Network dei DevTools di Chrome e a WebPageTest, i due strumenti più usati, ma i concetti valgono per qualsiasi strumento che mostri le richieste nel tempo.
Dove trovarlo
Nel browser, il pannello Network dei DevTools di Chrome mostra l’elenco delle richieste con una colonna Waterfall sulla destra. Conviene ricaricare la pagina con la cache disattivata, dall’apposita casella, e con un rallentamento della rete e della CPU che simuli un dispositivo mobile: su un computer veloce con una connessione in fibra molti problemi semplicemente non si vedono. Il pannello Performance offre una traccia della rete allineata a quella del main thread, utile per capire cosa succede nel browser mentre le risorse arrivano.
WebPageTest esegue il test su dispositivi e connessioni reali in diverse località e produce un waterfall molto dettagliato, con le fasi di ogni richiesta colorate, gli eventi principali segnati da linee verticali, l’utilizzo della CPU e della banda sotto il grafico e una sequenza di fotogrammi che mostra la pagina mentre si costruisce. È lo strumento di riferimento per analisi approfondite e per confrontare versioni diverse di una pagina. Anche PageSpeed Insights, nella sezione di diagnosi, mostra l’albero delle dipendenze di rete, una vista che mette in evidenza le catene di richieste critiche.
L’anatomia del grafico
Ogni riga del waterfall è una richiesta, e l’asse orizzontale è il tempo dall’inizio della navigazione. La posizione in cui inizia la barra indica quando il browser ha avviato la richiesta, cioè quando ha scoperto la risorsa e ha deciso di scaricarla. La lunghezza indica quanto è durata. Il colore, a seconda dello strumento, indica il tipo di risorsa, la fase della richiesta o entrambe.
All’interno di ogni barra si distinguono le fasi della richiesta. Le prime tre compaiono solo quando il browser apre una connessione nuova verso un dominio: la risoluzione DNS, che traduce il nome in un indirizzo; la connessione TCP; la negoziazione TLS per la cifratura. Poi c’è l’attesa, il tempo tra l’invio della richiesta e l’arrivo del primo byte della risposta, che corrisponde al lavoro del server e al tempo di andata e ritorno sulla rete. Infine il download vero e proprio, la cui durata dipende dalla dimensione della risorsa e dalla banda disponibile. Prima di tutto questo può esserci un tempo di coda, quando il browser ha scoperto la risorsa ma non l’ha ancora richiesta, per esempio perché ha una priorità bassa o perché ci sono troppe richieste contemporanee.
Le linee verticali segnano gli eventi della pagina: il First Contentful Paint, quando compare il primo contenuto; il Largest Contentful Paint; l’evento DOMContentLoaded, quando il documento è stato letto e gli script differiti eseguiti; l’evento load, quando tutte le risorse iniziali sono state scaricate. La posizione delle richieste rispetto a queste linee dice molto: tutto ciò che si trova prima del primo disegno è, potenzialmente, qualcosa che l’utente aspetta davanti a uno schermo bianco.
Un metodo di lettura in otto domande
Davanti a un waterfall con decine o centinaia di richieste è facile perdersi. Un metodo aiuta: porsi sempre le stesse domande, nello stesso ordine.
1. Quanto dura la prima richiesta?
La prima riga è il documento HTML, e tutto il resto dipende da lei. Se la sua fase di attesa dura mezzo secondo o più, il problema principale è il server: la pagina non viene servita dalla cache, l’applicazione è lenta o il server è lontano. È il campo del TTFB e della cache di pagina, e nessuna ottimizzazione del front-end potrà recuperare quel tempo. Se prima del documento compaiono uno o più reindirizzamenti, ciascuno aggiunge un intero giro di richiesta e risposta: vanno eliminati, per esempio facendo puntare i link direttamente all’indirizzo definitivo.
2. Cosa blocca il primo disegno?
Le risorse che bloccano il rendering, cioè i fogli di stile nell’intestazione e gli script sincroni, devono essere scaricate prima che il browser possa disegnare qualsiasi cosa. WebPageTest le segnala con un’icona dedicata. Conviene contarle e guardarne la durata: più sono e più pesano, più tardi arriva il primo disegno. Le soluzioni sono quelle viste negli articoli sul CSS critico e sul differimento degli script.
3. Quando parte la risorsa LCP?
È la domanda più importante per l’LCP. Si individua la risorsa dell’elemento LCP, di solito un’immagine, e si guarda quando inizia la sua barra rispetto al documento. Idealmente dovrebbe partire subito dopo l’arrivo dell’HTML, in parallelo con i fogli di stile. Se parte molto più tardi, dopo il CSS, dopo gli script o dopo altre immagini, c’è un problema di scoperta o di priorità: l’immagine è inserita da JavaScript, è uno sfondo definito nel CSS, ha il caricamento differito o ha una priorità bassa. Le soluzioni sono nell’articolo su preload, preconnect e fetchpriority.
4. Ci sono catene?
Una catena di richieste si riconosce da una forma a scala: una risorsa che inizia solo quando la precedente è finita, perché è quella precedente a richiederla. Il foglio di stile che importa un altro foglio di stile, che dichiara un font; lo script che carica un altro script, che carica un’immagine. Ogni gradino aggiunge un intero giro di rete. Le catene vanno accorciate, portando le risorse finali più in alto nel documento o anticipandole con un preload.
5. Quanti domini e quante connessioni?
Ogni dominio diverso richiede una connessione nuova, visibile nel waterfall come la sequenza colorata di DNS, TCP e TLS all’inizio della barra. Su una rete mobile ogni apertura può costare da 100 a 300 millisecondi. Se il waterfall mostra molte di queste sequenze, soprattutto prima del primo disegno, conviene chiedersi quali domini sono davvero necessari: font da servizi esterni, librerie da CDN pubbliche, script di terze parti. Ospitare le risorse critiche sul proprio dominio elimina queste aperture; per i domini indispensabili, un preconnect le anticipa.
6. Ci sono buchi?
A volte il waterfall mostra intervalli in cui la rete è ferma: nessuna richiesta in corso, eppure la pagina non è pronta. Quasi sempre significa che il collo di bottiglia non è la rete ma il processore: il browser sta eseguendo JavaScript, calcolando stili o disegnando, e non può scoprire né richiedere nuove risorse. In WebPageTest il grafico dell’utilizzo della CPU sotto il waterfall lo conferma a colpo d’occhio; nei DevTools, il pannello Performance mostra quali task occupano il main thread in quel momento.
7. Quali risorse sono troppo grandi?
Le barre con una lunga fase di download indicano risorse pesanti. Ordinando il pannello Network per dimensione si trovano subito immagini non ottimizzate, pacchetti JavaScript enormi, font completi non ridotti, video caricati automaticamente. Conviene controllare anche la colonna che confronta la dimensione trasferita con quella effettiva: se sono uguali per un file di testo, manca la compressione.
8. Cosa succede dopo?
Anche ciò che avviene dopo l’evento load merita uno sguardo. Script di analytics, pixel, chat, mappe di calore, richieste periodiche: non ritardano il primo caricamento, ma occupano banda e processore proprio quando l’utente inizia a interagire, con effetti sull’INP. Una lunga coda di richieste di terze parti dopo il caricamento è il segnale che vale la pena rivedere gli script di terze parti.
Le colonne che aiutano
Nel pannello Network dei DevTools alcune colonne, non visibili per impostazione predefinita, rendono la lettura molto più efficace. Si aggiungono con un clic destro sull’intestazione della tabella.
- Priority: la priorità assegnata dal browser, utile per verificare che l’immagine LCP e il CSS critico abbiano priorità alta.
- Initiator: chi ha richiesto la risorsa, l’HTML, un foglio di stile o uno script, indispensabile per ricostruire le catene.
- Protocol: HTTP/1.1, HTTP/2 o HTTP/3, per verificare che le connessioni usino i protocolli moderni.
- Size con la dimensione trasferita ed effettiva, e le intestazioni di risposta come
Content-EncodingeCache-Control.
Passando il mouse su una barra del waterfall, i DevTools mostrano la suddivisione esatta delle fasi con le durate, e nella scheda Timing della singola richiesta si trovano gli stessi dati in forma dettagliata. In WebPageTest, facendo clic su una riga si apre il dettaglio completo della richiesta e della risposta, con tutte le intestazioni.
Prima visita e visita ripetuta
Il waterfall di una prima visita, con la cache vuota, e quello di una visita ripetuta raccontano storie diverse. WebPageTest li produce entrambi. Nella visita ripetuta molte risorse dovrebbero sparire o comparire come risposte dalla cache del browser: se vengono scaricate di nuovo, le intestazioni di cache non sono configurate correttamente. Le richieste che compaiono con una risposta 304 indicano risorse riconvalidate con il server, un meccanismo utile ma che costa comunque un giro di rete, come spiegato nell’articolo su HTTP 304 Not Modified.
Il waterfall come strumento di verifica
Oltre che per la diagnosi, il waterfall è il modo migliore per verificare un intervento. Un preload dovrebbe spostare a sinistra la risorsa a cui si applica; un fetchpriority dovrebbe cambiarne la priorità; l’eliminazione di un dominio dovrebbe far sparire una sequenza di connessione; un CSS critico dovrebbe anticipare la linea del primo disegno. Confrontare i waterfall prima e dopo, con le stesse condizioni di test, mostra se l’intervento ha avuto l’effetto previsto e se ha avuto effetti collaterali, come una risorsa critica spostata a destra perché un’altra le ha sottratto banda.
WebPageTest permette di confrontare due test affiancati, con i waterfall e le sequenze di fotogrammi allineati. È uno strumento efficace anche per comunicare: la sequenza di fotogrammi di una pagina che si costruisce in un secondo accanto a quella della stessa pagina che impiegava quattro secondi convince più di qualsiasi numero.
I limiti
Il waterfall descrive un singolo caricamento, in condizioni precise: un dispositivo, una rete, una località, uno stato della cache. È uno strumento di laboratorio, prezioso per capire le cause, ma non rappresenta la varietà delle esperienze reali. Un problema che il waterfall non mostra può comunque esistere per una parte degli utenti, e viceversa. Per questo va sempre usato insieme ai dati di campo, come spiegato nell’articolo sul motivo per cui CrUX e test di laboratorio servono entrambi: i dati reali dicono dove guardare, il waterfall dice cosa succede.
In sintesi
Il waterfall mostra ogni richiesta della pagina nel tempo, con le sue fasi: apertura della connessione, attesa del server, download. Letto con metodo, risponde alle domande che contano: quanto tarda il server, cosa blocca il primo disegno, quando parte la risorsa LCP, dove sono le catene, quanti domini vengono contattati, dove la rete è ferma perché lavora il processore, quali risorse sono troppo grandi e cosa succede dopo il caricamento.
Le colonne giuste nei DevTools, il confronto tra prima visita e visita ripetuta in WebPageTest e il confronto prima e dopo ogni intervento ne fanno lo strumento di lavoro quotidiano di chi si occupa di prestazioni. Imparare a leggerlo richiede qualche ora; il tempo che fa risparmiare nelle analisi successive è molto di più.
