Core/Dash Dimension: Velocità di Rete

Dimensione: Velocità di Rete (dl)

La dimensione dl riporta la larghezza di banda di download effettiva della connessione di ciascun utente al momento della visita alla pagina, misurata in Megabit al secondo (Mbps). CoreDash raccoglie questo valore dall'API Network Information del browser e raggruppa le visite in fasce di larghezza di banda. Ogni riga nella tabella di CoreDash rappresenta uno specifico gruppo di velocità, in modo da poter confrontare i punteggi dei tuoi 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 determinano 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 Velocità di Rete è Importante per i Core Web Vitals

La larghezza di banda di download ha un impatto diretto e misurabile sul Largest Contentful Paint. L'LCP è quasi sempre attivato da un'immagine hero, una grande immagine di sfondo o un web font pesante. Su una connessione a 100 Mbps, un'immagine hero da 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 tempo di trasferimento, prima di tenere conto di qualsiasi latenza o sovraccarico di elaborazione. Quella differenza da sola può spingere un punteggio LCP sufficiente nella fascia "needs improvement".

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 del server o della CDN piuttosto che un problema di larghezza di banda lato client.

L'Interaction to Next Paint è quasi interamente legato alla CPU. L'INP misura il tempo che intercorre tra l'input dell'utente e il successivo aggiornamento visivo. L'esecuzione pesante di JavaScript, i task lunghi e il blocco del thread principale portano a scarsi punteggi INP. 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 dell'INP sono determinate dalla potenza di elaborazione del dispositivo, non dalla rete.

In pratica, i problemi di larghezza di banda emergono chiaramente nell'LCP Load Time, la sotto-parte dell'LCP che misura quanto tempo il browser ha impiegato per 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.

Leggere i Dati

Il traffico di CoreDash sui siti tipici si suddivide in tre fasce di larghezza di banda. Comprendere cosa rappresenta ogni fascia ti aiuta a stabilire le priorità per le 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 del 5G nel 2025 si aggirano intorno a 184 Mbps e le medie della banda larga fissa negli Stati Uniti hanno raggiunto i 214 Mbps. È improbabile che gli utenti in questa fascia subiscano ritardi dell'LCP dovuti alla rete su pagine ben ottimizzate. Se i punteggi LCP sono scarsi qui, il problema è il tempo di risposta del server, risorse render-blocking o un 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 tipiche velocità del 4G nel mondo reale si situano tra 10 e 50 Mbps) e alcuni utenti wireless fissi. Un'immagine hero da 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 non superare le soglie LCP in questa fascia. Questa è la fascia in cui le scelte del formato dell'immagine (WebP, AVIF) e il precaricamento aggressivo con fetchpriority="high" fanno una differenza misurabile.

Lente e Mobili: Sotto i 10 Mbps

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

Flusso di Lavoro per il Debugging

1. Filtra per la fascia sotto i 10 Mbps in CoreDash e controlla l'LCP Load Time. Se l'LCP Load Time è il contributore dominante a 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 sia 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 con una connessione a 15 Mbps servito da un nodo edge CDN a 200 ms di distanza avrà un'esperienza di gran lunga peggiore rispetto a un utente alla stessa velocità servito da un nodo a 10 ms di distanza.
3. Controlla i punteggi INP e TTFB attraverso le fasce. Se l'INP peggiora nelle fasce di larghezza di banda inferiori ma non in quelle alte, bundle JavaScript di grandi dimensioni stanno ancora scaricando quando gli utenti interagiscono per la prima volta. Dividi il tuo JavaScript, deferisci gli script non critici e considera di fare yielding al thread principale durante l'inizializzazione per ridurre l'esposizione dell'INP durante la fase di parsing.

Regola Pratica 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 al di sotto di 500 KB per fornire un LCP ragionevole su connessioni a 10 Mbps entro la soglia di 2,5 secondi.
• Usa fetchpriority="high" sull'immagine LCP e precaricala nel <head> del documento in modo che il browser non sprechi prima larghezza di banda su risorse a priorità più bassa.
• Servi tutti gli asset statici da una CDN. I numeri di larghezza di banda in CoreDash misurano la connessione del client, non del server. Una connessione client veloce non aiuta se il server è geograficamente distante e aggiunge 300 ms di latenza prima che arrivi il 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.