Impostazioni del Pannello Network di Chrome DevTools per i Core Web Vitals
Le impostazioni del pannello Network che uso in ogni audit dei Core Web Vitals
Il pannello Network di Chrome DevTools è uno degli strumenti più utili per il debug dei Core Web Vitals. Ma le impostazioni predefinite nascondono metà delle informazioni necessarie. Ecco come configuro il pannello Network in ogni audit.
Ultima revisione di Arjen Karel a marzo 2026
Table of Contents!
Configurare il Pannello Network
Per accedere al pannello Network, apri i Chrome DevTools (F12 o Ctrl+Shift+I) e clicca sulla scheda "Network".
Throttling
I tuoi visitatori non sono sul Wi-Fi del tuo ufficio. A livello globale, il 30% delle connessioni mobili è ancora su 3G e un altro 55% è su 4G (GSMA Mobile Economy 2025). Il throttling di rete ti permette di vedere ciò che vedono loro.
Clicca sul menu a tendina "No throttling" nel pannello Network. Seleziona "Fast 4G", "Slow 4G" o "3G" per simulare le condizioni della rete mobile. L'opzione migliore dipende dal tuo pubblico. Se il tuo pubblico utilizza tipicamente dispositivi mobili di fascia alta con connessioni veloci, abilita "Fast 4G". Se le condizioni di rete tipiche sono un po' più scarse, seleziona "Slow 4G". Altrimenti vai sul sicuro e seleziona "3G".
Throttling di singole richieste (Chrome 145+)
Da dicembre 2025, è possibile applicare il throttling a una singola richiesta invece che all'intera pagina. Clicca con il tasto destro del mouse su qualsiasi richiesta nel pannello Network e seleziona "Throttle request". Questo ti permette di rispondere a domande come: cosa succede al mio LCP se questo script di terze parti si carica lentamente? Oppure: come si comporta la mia pagina quando la CDN è lenta ma la connessione dell'utente è veloce? È il modo più rapido per isolare l'impatto sulle prestazioni di una singola risorsa.
Disabilita Cache
Per assicurarti di testare il tuo sito come lo vivrebbe un visitatore per la prima volta, spunta la casella "Disable cache" nel pannello Network.
Abilita Big Request Rows
Le "Big request rows" mostrano dettagli critici che la vista compatta predefinita nasconde:
- La colonna size mostra sia la dimensione compressa (trasferimento) che non compressa (effettiva) di ogni richiesta.
- La colonna name mostra il percorso completo, non solo il nome del file.
- La colonna priority mostra la fetch priority iniziale e finale. Questo è il modo per verificare che la tua immagine LCP si carichi con priorità High o per individuare quando Chrome ricalcola la priorità di una risorsa.
Abilita gli Screenshot
Abilita gli screenshot e Chrome catturerà una sequenza (filmstrip) di ogni cambiamento visivo durante il caricamento della pagina. Questo è il modo per individuare i layout shifts e verificare che il tuo LCP element venga renderizzato quando te lo aspetti.
- Con la scheda Network in primo piano, premi Ctrl+F5 (Cmd+R su Mac) per aggiornare la pagina.
- Chrome catturerà degli screenshot durante il processo di caricamento della pagina.
- Le miniature di questi screenshot appariranno sotto la riga delle caselle di controllo nel pannello Network.
La panoramica degli screenshot ha alcune piccole funzionalità molto utili che potresti non conoscere ancora:
- Passa il mouse su uno screenshot per vedere quando è stato catturato. Questo sarà indicato da una linea verticale gialla sul grafico Overview.
- Clicca sulla miniatura di uno screenshot per filtrare le richieste avvenute dopo lo scatto di quello screenshot.
- Fai doppio clic su una miniatura per ingrandire e visualizzare lo screenshot in maggior dettaglio.
Abilita le migliori colonne del pannello Network
Le colonne predefinite mancano di dati critici. Clicca col tasto destro del mouse sull'intestazione di qualsiasi colonna per aggiungerne altre. Queste sono quelle che abilito in ogni audit:
| Nome Colonna | Descrizione | Perché è importante per i Core Web Vitals |
|---|---|---|
| Name | Nome della richiesta | Identifica ogni risorsa che il browser scarica |
| Status | Codici di stato HTTP | Individua i redirect (301, 302) che aggiungono latenza al tuo TTFB e gli errori 404 per le risorse che sprecano un viaggio di andata e ritorno sulla rete |
| Protocol | Protocollo di rete utilizzato | HTTP/3 elimina l'head-of-line blocking. Secondo Cloudflare Radar, solo il 21% delle richieste utilizza HTTP/3. Se la tua CDN lo supporta e non vedi h3 in questa colonna, controlla la tua configurazione DNS |
| Domain | Dominio della risorsa | Separa le richieste di prime parti da quelle di terze parti. Il Web Almanac 2024 ha scoperto che il 92% delle pagine carica almeno una terza parte. Ordinare per dominio rivela quanta parte del tuo waterfall è al di fuori del tuo controllo |
| Type | Tipo di risorsa | Filtra per tipo per isolare script, immagini o font che competono per la larghezza di banda |
| Initiator | Trigger della richiesta | Scopri quale script o foglio di stile ha innescato ogni richiesta. In questo modo puoi rintracciare una catena lenta di critical requests fino alla sua origine |
| Size | Dimensione di trasferimento ed effettiva | Individua risorse non compresse o sovradimensionate. La pagina mobile mediana carica 66 richieste per un totale di 2,3 MB (Web Almanac 2024) |
| Priority | Priorità di caricamento della risorsa | Mostra la fetch priority iniziale e finale. Verifica che la tua immagine LCP si carichi con priorità High e gli script non critici si carichino con priorità Low |
| Waterfall | Timeline visiva delle richieste | La timeline che mostra dove viene speso il tempo. Le barre lunghe prima del primo paint influenzano direttamente il tuo LCP e FCP |
Abilita le intestazioni di risposta personalizzate
| Nome Colonna | Descrizione | Perché è importante per i Core Web Vitals |
|---|---|---|
| Cache-Control | Comportamento di caching della risorsa | Verifica che gli asset statici abbiano lunghi tempi di cache e che l'HTML abbia una revalidation appropriata. Un caching scarso costringe i visitatori abituali a scaricare nuovamente le risorse, danneggiando ogni metrica. Vedi anche: Configurazione della cache di Cloudflare |
| Link | Intestazione di risposta Link | Controlla se il tuo server invia hint di preload o preconnect, incluso tramite 103 Early Hints |
| Content-Encoding | La codifica utilizzata | Verifica che il tuo server invii Brotli (br) invece di gzip. Brotli comprime il JavaScript in modo che sia dal 15 al 20% più piccolo rispetto a gzip. Il Web Almanac 2024 mostra che Brotli ha superato gzip per le risorse JavaScript (45% vs 41%) |
Se vuoi analizzare le intestazioni di risposta in blocco senza aprire i DevTools per ogni pagina, prova lo strumento HTTP Header Performance Analyzer.
Connettiti al pannello Performance
Il pannello Network ti mostra cosa viene caricato e quando. Per vedere come ogni risorsa influisce sui Core Web Vitals, passa al pannello Performance. Ora mostra in tempo reale i punteggi di LCP, CLS e INP senza dover registrare, e può sovrapporre i field data di CrUX da utenti reali. Usa il pannello Network per diagnosticare, il pannello Performance per confermare.
Per un monitoraggio continuo oltre la singola sessione di debug, connetti uno strumento di Real User Monitoring in modo da poter tracciare se le tue correzioni nel pannello Network migliorano effettivamente i field data nel tempo.
Il setup completo
Ricarica la pagina con queste impostazioni e il tuo pannello Network apparirà in questo modo. Ogni colonna è mappata su qualcosa che influenza i Core Web Vitals.
CoreDash has MCP built in.
Connect it to Claude or any AI agent. Ask it why your INP spiked last Tuesday.
See how it works
