Dimensão CoreDash: Velocidade da Rede

Dimensão: Velocidade da Rede (dl)

A dimensão dl relata a largura de banda de download efetiva da conexão de cada usuário no momento da visita à página, medida em Megabits por segundo (Mbps). O CoreDash coleta esse valor da Network Information API do navegador e agrupa as visitas em níveis de largura de banda. Cada linha na tabela do CoreDash representa um intervalo de velocidade específico, para que você possa comparar suas pontuações de Core Web Vitals entre usuários de banda larga rápida, conexões de velocidade moderada e conexões lentas ou móveis lado a lado.

A largura de banda é uma das duas características de rede que moldam a performance de carregamento da página. A outra é a latência, que controla o tempo de round-trip para o servidor. A dimensão dl do CoreDash isola a variável de largura de banda para que você possa responder a uma pergunta concreta: as suas pontuações de Core Web Vitals estão degradando à medida que a velocidade da conexão cai, e em quanto?

Por que a Velocidade da Rede importa para os Core Web Vitals

A largura de banda de download tem um impacto direto e mensurável no Largest Contentful Paint. O LCP é quase sempre acionado por uma imagem hero, uma grande imagem de fundo ou uma fonte web pesada. Em uma conexão de 100 Mbps, uma imagem hero de 400 KB chega em aproximadamente 32 milissegundos de tempo de transferência. Em uma conexão de 5 Mbps, essa mesma imagem leva mais de 640 milissegundos apenas em tempo de transferência, antes de contabilizar qualquer latência ou overhead de processamento. Essa diferença por si só pode empurrar uma pontuação de LCP aprovada para a faixa de "precisa de melhorias".

O Time to First Byte é menos sensível à largura de banda. O TTFB é dominado pelo tempo de processamento do servidor e pela latência de round-trip da rede, não pelo volume de bytes transferidos. Uma resposta lenta do servidor é lenta em qualquer velocidade de conexão. Se o TTFB for ruim em todos os níveis de largura de banda no CoreDash, isso aponta para problemas no servidor ou no CDN, em vez de um problema de largura de banda do lado do cliente.

Interaction to Next Paint é quase inteiramente limitado pela CPU. O INP mede o tempo entre a entrada do usuário e a próxima atualização visual. A execução pesada de JavaScript, tarefas longas e o bloqueio da thread principal (main thread) geram pontuações de INP ruins. Uma conexão lenta pode atrasar o download inicial de pacotes JavaScript, o que pode piorar indiretamente o INP se os scripts ainda estiverem sendo analisados (parsing) quando o usuário interage pela primeira vez com a página. Mas uma vez que os scripts são carregados, a performance do INP é determinada pelo poder de processamento do dispositivo, não pela rede.

Na prática, problemas de largura de banda surgem claramente no LCP Load Time, a subparte do LCP que mede quanto tempo o navegador gastou baixando o recurso LCP depois que ele foi descoberto. O CoreDash relata o LCP Load Time separadamente, tornando simples confirmar se os usuários lentos estão esperando pela rede ou por outra coisa.

Lendo os Dados

O tráfego do CoreDash em sites típicos se divide em três níveis de largura de banda. Entender o que cada nível representa ajuda você a priorizar as correções.

Banda Larga Rápida: 50 Mbps e acima

Aproximadamente 35% do tráfego do CoreDash cai neste nível. Isso inclui conexões de fibra, banda larga a cabo e usuários móveis 5G em boas condições de sinal. As velocidades médias de download do 5G em 2025 giram em torno de 184 Mbps, e as médias de banda larga fixa nos EUA atingiram 214 Mbps. É improvável que usuários neste nível experimentem atrasos de LCP causados pela rede em páginas bem otimizadas. Se as pontuações de LCP forem ruins aqui, o problema é o tempo de resposta do servidor, recursos que bloqueiam o render ou atraso na descoberta do elemento LCP, não a largura de banda.

Velocidade Moderada: 10 a 50 Mbps

Aproximadamente 40% do tráfego do CoreDash aterrissa nesta faixa. Este nível cobre conexões de cabo mais antigas, 4G LTE em condições médias de sinal (as velocidades reais típicas do 4G ficam entre 10 e 50 Mbps) e alguns usuários de rede fixa sem fio. Uma imagem hero de 300 KB leva entre 48 e 240 milissegundos de tempo de transferência nessas velocidades. Páginas com imagens não otimizadas ou múltiplos recursos que bloqueiam o render começarão a falhar nos limites de LCP neste nível. Este é o nível onde as escolhas de formato de imagem (WebP, AVIF) e o preloading agressivo com fetchpriority="high" fazem uma diferença mensurável.

Lento e Móvel: Abaixo de 10 Mbps

Aproximadamente 25% do tráfego do CoreDash vem de conexões abaixo de 10 Mbps. Isso inclui usuários móveis 3G, conexões fixas rurais e usuários 4G em condições de sinal ruim ou rede congestionada. A 5 Mbps, uma imagem de 400 KB leva mais de 640 milissegundos de tempo de transferência. Falhas de LCP neste nível são quase certas, a menos que a imagem LCP tenha sido compactada agressivamente, servida através de um nó de borda de CDN próximo ao usuário e pré-carregada corretamente. Se o seu negócio atende usuários em regiões com infraestrutura historicamente mais lenta, verifique a dimensão Country do CoreDash ao lado de dl para confirmar se o tráfego de baixa velocidade se concentra geograficamente.

Fluxo de Trabalho de Depuração

1. Filtre para o nível abaixo de 10 Mbps no CoreDash e verifique o LCP Load Time. Se o LCP Load Time for o contribuinte dominante para uma pontuação de LCP com falha, o recurso LCP é muito grande para conexões lentas. Compacte a imagem ainda mais, mude para o formato AVIF e confirme se o recurso é servido de um CDN com um nó de borda próximo aos usuários afetados.
2. Cruze as informações com a dimensão Country. Se os usuários de baixa velocidade se concentrarem em países específicos, verifique se o seu CDN tem boa cobertura nessas regiões. Um usuário em uma conexão de 15 Mbps servido por um nó de borda de CDN a 200 ms de distância terá uma experiência muito pior do que um usuário na mesma velocidade servido por um nó a 10 ms de distância.
3. Verifique as pontuações de INP e TTFB entre os níveis. Se o INP piorar em níveis baixos de largura de banda, mas não nos altos, grandes pacotes JavaScript ainda estão sendo baixados quando os usuários interagem pela primeira vez. Divida seu JavaScript, adie scripts não críticos e considere ceder à thread principal (yielding to the main thread) durante a inicialização para reduzir a exposição do INP durante a fase de análise (parse phase).

Regra de Ouro da Engenharia

• Busque um tamanho de arquivo de imagem LCP abaixo de 100 KB (AVIF ou WebP) para manter o LCP Load Time abaixo de 200 ms, mesmo em conexões de 5 Mbps.
• O peso total da página para recursos acima da dobra (above-the-fold) deve permanecer abaixo de 500 KB para dar um LCP razoável em conexões de 10 Mbps dentro do limite de 2,5 segundos.
• Use fetchpriority="high" na imagem LCP e faça o preload dela no <head> do documento para que o navegador não desperdice largura de banda com recursos de menor prioridade primeiro.
• Sirva todos os ativos estáticos de um CDN. Os números de largura de banda no CoreDash medem a conexão do cliente, não a do servidor. Uma conexão rápida do cliente não ajuda se o servidor estiver geograficamente distante e adicionar 300 ms de latência antes que o primeiro byte chegue.
• Se mais de 15% do seu tráfego estiver no nível abaixo de 10 Mbps e o LCP estiver falhando para esses usuários, trate a otimização de imagem e a cobertura do CDN como problemas P1 antes de abordar qualquer outra coisa.