Core/Dash Dimension: Network Speed

Dimension: Network Speed (dl)

La dimensione dl riporta la larghezza di banda di download effettiva della connessione di ogni utente al momento della visita alla pagina, misurata in Megabit al secondo (Mbps). CoreDash raccoglie questo valore dalla Network Information API del browser e raggruppa le visite in fasce di larghezza di banda. Ogni riga nella tabella di CoreDash rappresenta uno specifico scaglione di velocità, in modo da poter confrontare i punteggi dei Core Web Vitals tra utenti con banda larga veloce, connessioni a velocità moderata e connessioni lente o mobili fianco a fianco.

La larghezza di banda è una delle due caratteristiche di rete che influenzano le prestazioni di caricamento della pagina. L'altra è la latenza, che controlla il tempo di round-trip verso il server. La dimensione dl di CoreDash isola la variabile della larghezza di banda in modo da poter rispondere a una domanda concreta: i punteggi dei tuoi Core Web Vitals stanno peggiorando al calare della velocità di connessione, e di quanto?

Perché la Network Speed è importante per i Core Web Vitals

La larghezza di banda in download ha un impatto diretto e misurabile sulla Largest Contentful Paint. LCP è quasi sempre attivata da un'immagine hero, una grande immagine di sfondo o un web font pesante. Su una connessione a 100 Mbps, un'immagine hero di 400 KB arriva in circa 32 millisecondi di tempo di trasferimento. Su una connessione a 5 Mbps, la stessa immagine impiega oltre 640 millisecondi solo per il trasferimento, prima di tenere conto di qualsiasi latenza o overhead di elaborazione. Questa differenza da sola può spingere un punteggio LCP superato nella fascia "needs improvement" (richiede miglioramento).

Il Time to First Byte è meno sensibile alla larghezza di banda. Il TTFB è dominato dal tempo di elaborazione del server e dalla latenza di round-trip della rete, non dal volume di byte trasferiti. Una risposta lenta del server è lenta su qualsiasi velocità di connessione. Se il TTFB è scarso in tutte le fasce di larghezza di banda in CoreDash, ciò indica problemi al server o alla CDN piuttosto che un problema di larghezza di banda lato client.

L'Interaction to Next Paint è quasi interamente legata alla CPU. L'INP misura il tempo tra l'input dell'utente e il successivo aggiornamento visivo. L'esecuzione pesante di JavaScript, i long task e il blocco del main thread causano punteggi INP scarsi. Una connessione lenta può ritardare il download iniziale dei bundle JavaScript, il che può peggiorare indirettamente l'INP se gli script sono ancora in fase di parsing quando l'utente interagisce per la prima volta con la pagina. Ma una volta caricati gli script, le prestazioni INP sono determinate dalla potenza di elaborazione del dispositivo, non dalla rete.

In pratica, i problemi di larghezza di banda emergono chiaramente in LCP Load Time, la sotto-parte della LCP che misura quanto tempo ha impiegato il browser a scaricare la risorsa LCP dopo che è stata scoperta. CoreDash riporta l'LCP Load Time separatamente, rendendo semplice confermare se gli utenti lenti stanno aspettando la rete o qualcos'altro.

Lettura dei Dati

Il traffico di CoreDash nei siti tipici si divide in tre fasce di larghezza di banda. Comprendere cosa rappresenta ogni fascia ti aiuta a dare priorità alle correzioni.

Banda larga veloce: 50 Mbps e oltre

Circa il 35% del traffico di CoreDash rientra in questa fascia. Ciò include connessioni in fibra, banda larga via cavo e utenti mobili 5G in buone condizioni di segnale. Le velocità medie di download in 5G nel 2025 si aggirano intorno a 184 Mbps, e le medie della banda larga fissa negli Stati Uniti hanno raggiunto 214 Mbps. È improbabile che gli utenti in questa fascia subiscano ritardi nella LCP causati dalla rete su pagine ben ottimizzate. Se i punteggi LCP sono scarsi qui, il problema è il tempo di risposta del server, le risorse render-blocking o il ritardo nella scoperta dell'elemento LCP, non la larghezza di banda.

Velocità moderata: da 10 a 50 Mbps

Circa il 40% del traffico di CoreDash rientra in questo intervallo. Questa fascia copre le vecchie connessioni via cavo, il 4G LTE in condizioni di segnale medie (le velocità tipiche del 4G nel mondo reale si attestano tra 10 e 50 Mbps) e alcuni utenti wireless fissi. Un'immagine hero di 300 KB impiega tra 48 e 240 millisecondi di tempo di trasferimento a queste velocità. Le pagine con immagini non ottimizzate o risorse render-blocking multiple inizieranno a fallire le soglie LCP in questa fascia. Questa è la fascia in cui le scelte del formato dell'immagine (WebP, AVIF) e il preloading aggressivo con fetchpriority="high" fanno una differenza misurabile.

Lento e Mobile: Sotto i 10 Mbps

Circa il 25% del traffico di CoreDash proviene da connessioni inferiori a 10 Mbps. Questo include utenti mobili 3G, connessioni fisse rurali e utenti 4G in condizioni di segnale scarso o di rete congestionata. A 5 Mbps, un'immagine di 400 KB richiede oltre 640 millisecondi di tempo di trasferimento. I fallimenti della LCP in questa fascia sono quasi certi, a meno che l'immagine LCP non sia stata compressa in modo aggressivo, servita tramite un nodo edge di una CDN vicino all'utente e precaricata correttamente. Se la tua azienda serve utenti in regioni con infrastrutture storicamente più lente, controlla la dimensione Country in CoreDash insieme a dl per confermare se il traffico a bassa velocità si concentra geograficamente.

Workflow di Debug

1. Filtra per la fascia sotto i 10 Mbps in CoreDash e controlla l'LCP Load Time. Se l'LCP Load Time è il principale responsabile di un punteggio LCP insufficiente, la risorsa LCP è troppo grande per le connessioni lente. Comprimi ulteriormente l'immagine, passa al formato AVIF e conferma che la risorsa viene servita da una CDN con un nodo edge vicino agli utenti interessati.
2. Incrocia i dati con la dimensione Country. Se gli utenti a bassa velocità si concentrano in paesi specifici, controlla se la tua CDN ha una buona copertura in quelle regioni. Un utente su una connessione a 15 Mbps servito da un nodo edge della CDN a 200 ms di distanza avrà un'esperienza di gran lunga peggiore di un utente alla stessa velocità servito da un nodo a 10 ms di distanza.
3. Controlla i punteggi INP e TTFB nelle varie fasce. Se l'INP peggiora nelle fasce di larghezza di banda basse ma non in quelle alte, i bundle JavaScript di grandi dimensioni stanno ancora scaricando quando gli utenti interagiscono per la prima volta. Dividi il tuo JavaScript, differisci gli script non critici e valuta di fare yield al main thread durante l'inizializzazione per ridurre l'esposizione dell'INP durante la fase di parsing.

Regola Empirica di Ingegneria

• Punta a una dimensione del file dell'immagine LCP inferiore a 100 KB (AVIF o WebP) per mantenere l'LCP Load Time sotto i 200 ms anche su connessioni a 5 Mbps.
• Il peso totale della pagina per le risorse above-the-fold dovrebbe rimanere sotto i 500 KB per fornire una LCP ragionevole su connessioni a 10 Mbps entro la soglia di 2,5 secondi.
• Usa fetchpriority="high" sull'immagine LCP e precaricala nell'<head> del documento in modo che il browser non sprechi prima la larghezza di banda per risorse a priorità più bassa.
• Servi tutti gli asset statici da una CDN. I numeri relativi alla larghezza di banda in CoreDash misurano la connessione del client, non quella del server. Una connessione veloce del client non è d'aiuto se il server è geograficamente distante e aggiunge 300 ms di latenza prima dell'arrivo del primo byte.
• Se più del 15% del tuo traffico si trova nella fascia sotto i 10 Mbps e l'LCP fallisce per quegli utenti, tratta l'ottimizzazione delle immagini e la copertura della CDN come problemi P1 prima di affrontare qualsiasi altra cosa.