Core/Dash Dimensão: Velocidade da Rede

Dimensão: Velocidade da Rede (dl)

A dimensão dl relata a largura de banda efetiva de download da conexão de cada usuário no momento da visita à página, medida em Megabits por segundo (Mbps). O CoreDash coleta esse valor a partir 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 lado a lado, entre usuários de banda larga rápida, conexões de velocidade moderada e conexões lentas ou móveis.

A largura de banda é uma das duas características de rede que moldam o desempenho do carregamento da página. A outra é a latência, que controla o tempo de ida e volta ao servidor. A dimensão dl do CoreDash isola a variável da 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 diminui, e em quanto?

Por que a Velocidade da Rede é Importante 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 web font 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 no tempo de transferência, antes de contabilizar qualquer latência ou sobrecarga de processamento. Essa diferença por si só pode empurrar uma pontuação LCP de aprovação para a faixa "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 ida e volta 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 na CDN, em vez de um problema de largura de banda no lado do cliente.

O Interaction to Next Paint é quase totalmente limitado pela CPU. O INP mede o tempo entre a entrada do usuário e a próxima atualização visual. Execução pesada de JavaScript, longas tarefas e o bloqueio da thread principal impulsionam pontuações ruins de INP. 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 quando o usuário interagir com a página pela primeira vez. Mas, uma vez que os scripts são carregados, o desempenho do INP é determinado 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 fazendo o download do recurso LCP após sua descoberta. O CoreDash relata o LCP Load Time separadamente, tornando simples confirmar se os usuários lentos estão aguardando a rede ou alguma 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 se enquadra 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 estão em torno de 184 Mbps, e as médias da banda larga fixa nos EUA chegaram a 214 Mbps. Os usuários neste nível dificilmente experimentarão atrasos de LCP causados pela rede em páginas bem otimizadas. Se as pontuações LCP forem ruins aqui, o problema é o tempo de resposta do servidor, recursos de bloqueio de renderização 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 cai nesta faixa. Este nível abrange conexões a cabo mais antigas, 4G LTE em condições médias de sinal (velocidades reais típicas do 4G ficam entre 10 e 50 Mbps) e alguns usuários de conexão sem fio fixa. 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 de bloqueio de renderização começarão a falhar nos limites do LCP neste nível. É neste nível que as escolhas de formato de imagem (WebP, AVIF) e o pré-carregamento 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 redes congestionadas. Em 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 edge node da CDN próximo ao usuário e pré-carregada corretamente. Se o seu negócio atende a usuários em regiões com infraestrutura historicamente mais lenta, verifique a dimensão Country do CoreDash juntamente com 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 inferior a 10 Mbps no CoreDash e verifique o LCP Load Time. Se o LCP Load Time for o principal contribuinte para uma pontuação de LCP reprovada, o recurso LCP é muito grande para conexões lentas. Comprima ainda mais a imagem, mude para o formato AVIF e confirme se o recurso é servido de uma CDN com um edge node próximo aos usuários afetados.
2. Faça referência cruzada com a dimensão Country. Se os usuários de baixa velocidade se concentrarem em países específicos, verifique se a sua CDN possui boa cobertura nessas regiões. Um usuário em uma conexão de 15 Mbps atendido por um edge node da CDN a 200 ms de distância terá uma experiência muito pior do que um usuário na mesma velocidade atendido 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 nos níveis de baixa largura de banda, mas não nos altos, os grandes pacotes JavaScript ainda estão sendo baixados quando os usuários interagem pela primeira vez. Divida o seu JavaScript, adie scripts não críticos e considere o yield para a thread principal durante a inicialização para reduzir a exposição do INP durante a fase de análise.

Regra Prática de Engenharia

• Tenha como meta um tamanho de arquivo da 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 "above-the-fold" deve ficar abaixo de 500 KB para fornecer 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 pré-carregamento no <head> do documento para que o navegador não desperdice largura de banda em recursos de prioridade mais baixa primeiro.
• Sirva todos os ativos estáticos de uma CDN. Os números de largura de banda no CoreDash medem a conexão do cliente, não do servidor. Uma conexão rápida de cliente não ajuda se o servidor for 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 inferior a 10 Mbps e o LCP estiver falhando para esses usuários, trate a otimização de imagem e a cobertura da CDN como problemas P1 antes de abordar qualquer outra coisa.