Por que “rede” ainda decide a percepção de velocidade
Mesmo com assets bem otimizados, a experiência pode piorar por latência de rede, negociações de conexão e escolhas ruins de prioridade. Antes de qualquer byte útil chegar ao navegador, existe um caminho: resolver DNS, abrir conexão TCP, negociar TLS, possivelmente negociar HTTP/2 ou HTTP/3, e só então enviar a requisição. Em conexões móveis ou em usuários distantes do servidor, esses passos podem custar centenas de milissegundos (ou mais) e afetar diretamente o tempo até o primeiro recurso crítico começar a baixar.
Este capítulo foca em três alavancas práticas para reduzir esse “tempo morto” e guiar o navegador a baixar o que importa primeiro: dns-prefetch, preconnect e priorização de recursos. A ideia não é “carregar mais cedo tudo”, e sim preparar conexões e ordenar downloads para que o conteúdo crítico seja favorecido sem desperdiçar banda, sockets e CPU.
Entendendo o custo de conexão: DNS, TCP e TLS
Quando seu HTML referencia um recurso em outro host (por exemplo, https://cdn.exemplo.com/app.css), o navegador precisa:
- DNS lookup: descobrir o IP do host.
- TCP handshake (em HTTP/1.1 e HTTP/2 sobre TCP): abrir a conexão.
- TLS handshake (HTTPS): negociar criptografia e validar certificados.
- Negociação de protocolo: ALPN para decidir HTTP/2, por exemplo.
Em HTTP/3 (QUIC), parte disso muda, mas ainda existe custo de handshake e validação. Em qualquer caso, antecipar etapas (quando faz sentido) pode reduzir o tempo até o primeiro byte do recurso crítico.
dns-prefetch: antecipando a resolução de DNS
O que é
dns-prefetch pede ao navegador para resolver o DNS de um domínio antes de ele ser realmente necessário. Ele não abre conexão TCP nem TLS; apenas tenta garantir que, quando o recurso for requisitado, o IP já esteja no cache do resolvedor.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Quando usar
- Quando você sabe que provavelmente fará requisições para um domínio em breve, mas não quer pagar o custo de abrir conexão completa.
- Quando o recurso pode ser usado mais tarde (ex.: scripts de analytics, chat, A/B testing), e você quer reduzir um pouco a latência sem “aquecer” demais a rede.
- Quando você tem muitos domínios terceiros e quer ser conservador:
dns-prefetché menos agressivo quepreconnect.
Quando evitar
- Quando o domínio é incerto (ex.: só em fluxos específicos). Prefetch desnecessário aumenta ruído e pode gerar consultas DNS inúteis.
- Quando você já usa
preconnectpara o mesmo host:preconnectinclui DNS, entãodns-prefetchvira redundante.
Como implementar
Adicione no início do documento (o mais cedo possível no HTML):
<link rel="dns-prefetch" href="//cdn.exemplo.com">Observações práticas:
- Use o formato com
//(scheme-relative) ou comhttps://. O importante é o host. - Coloque no
<head>para ser descoberto cedo.
Passo a passo para decidir dns-prefetch
- Liste os hosts externos que aparecem no HTML inicial (CDN, fontes, APIs, tags de terceiros).
- Classifique por “certeza de uso” nos primeiros segundos de navegação.
- Para hosts com uso provável, mas não crítico imediato, aplique
dns-prefetch. - Meça se houve redução de tempo de início de requisições a esses hosts (em waterfall) e se não houve aumento de trabalho desnecessário.
preconnect: abrindo caminho completo até o servidor
O que é
preconnect instrui o navegador a iniciar antecipadamente a conexão com um host: DNS + TCP + TLS (quando aplicável). Isso reduz a latência quando o primeiro recurso desse host for requisitado, porque a conexão já está pronta (ou parcialmente pronta).
Por que é poderoso (e perigoso)
É poderoso porque pode economizar um round-trip inteiro (ou mais) antes do download começar. É perigoso porque:
- Consome sockets e recursos do navegador.
- Pode competir com downloads críticos se usado em excesso.
- Em mobile, pode aumentar consumo de energia e rádio.
Regra prática: use preconnect para poucos hosts, altamente prováveis e que impactam o caminho crítico.
Exemplos típicos de uso
- Seu CDN principal de estáticos (CSS/JS críticos) quando em host diferente do HTML.
- Host de fontes (quando realmente necessário e não auto-hospedado).
- API chamada muito cedo para renderização inicial (ex.: endpoint de dados essenciais para o above-the-fold).
Como implementar
<link rel="preconnect" href="https://cdn.exemplo.com" crossorigin>Detalhes importantes:
- crossorigin: use quando o recurso será buscado com CORS (muito comum em fontes e alguns CDNs). Mesmo quando não é estritamente necessário, é uma prática segura para evitar que a conexão preconnect não seja reutilizada por diferenças de credenciais.
- Coloque o
preconnecto mais cedo possível no<head>.
Passo a passo prático para escolher preconnect
- Identifique os primeiros hosts acessados na navegação inicial (HTML, CSS crítico, JS inicial, fonte essencial, API de dados iniciais).
- Conte quantos hosts diferentes existem no caminho crítico. Tente reduzir antes de adicionar preconnect (consolidar em um CDN, por exemplo).
- Escolha no máximo 1–3 hosts para
preconnect(como ponto de partida) e valide o impacto. - Implemente e compare: tempo até o início do download do primeiro recurso desse host e tempo total até o conteúdo inicial aparecer.
Armadilhas comuns
- Preconnect para terceiros “talvez usados”: chat, heatmap, pixels. Isso aquece conexões que podem nem ser usadas.
- Preconnect demais: muitos hosts abertos cedo podem atrasar o que importa por competição de rede.
- Preconnect para o mesmo origin: se o HTML já vem do mesmo host, o navegador normalmente já tem conexão. O ganho é pequeno ou nulo.
preconnect vs dns-prefetch: como decidir rapidamente
Use este guia:
- Se o host é crítico e certamente usado cedo (primeiros recursos essenciais): preconnect.
- Se o host é provável, mas não necessariamente crítico imediato: dns-prefetch.
- Se o host é incerto ou só aparece em interações posteriores: não use nenhum, ou avalie outras técnicas de carregamento sob demanda.
Prioridade de recursos: fazendo o navegador baixar na ordem certa
Além de preparar conexões, você precisa orientar o navegador sobre o que deve receber atenção primeiro. Em HTTP/2 e HTTP/3, múltiplos recursos compartilham a mesma conexão, então a ordem e a prioridade influenciam bastante o tempo de entrega do que é crítico.
Prioridade pode ser influenciada por:
- Tipo de recurso (CSS tende a ser mais prioritário que imagens abaixo da dobra).
- Descoberta no HTML (o que aparece antes é descoberto antes).
- Preload e atributos de prioridade (quando aplicável).
- Concorrência e tamanho dos recursos (um download grande pode “abafar” vários pequenos se mal priorizado).
fetchpriority: sinal explícito de prioridade
O atributo fetchpriority permite sugerir ao navegador a prioridade de busca de certos recursos. Ele é especialmente útil para ajustar casos em que a heurística padrão não está ideal.
Exemplos:
<img src="/hero.jpg" width="1200" height="600" fetchpriority="high" alt=""><script src="/widget-secundario.js" fetchpriority="low" defer></script>Boas práticas:
- Use
highcom parcimônia (normalmente 1 recurso principal por viewport, como uma imagem hero realmente determinante). - Use
lowpara recursos que você sabe que não devem competir com o caminho crítico. - Evite “marcar tudo como high”: isso anula o benefício e pode piorar a disputa.
Ordem de descoberta: o HTML ainda manda
O navegador só pode priorizar o que ele conhece. Se um recurso crítico é descoberto tarde (por exemplo, injetado via JavaScript após algum tempo), ele começará a baixar tarde, mesmo com boa rede. Estratégias práticas:
- Garanta que referências a CSS essencial e scripts necessários para a primeira renderização estejam no
<head>(respeitando as estratégias de não bloqueio já definidas no projeto). - Evite “encapsular” recursos críticos atrás de chamadas JS que rodam depois do carregamento inicial.
- Quando um recurso é inevitavelmente descoberto tarde, considere mecanismos de antecipação (ex.: preload seletivo) apenas quando houver justificativa clara.
Priorização em APIs de fetch
Para requisições feitas via JavaScript, você pode influenciar prioridade em alguns navegadores usando a opção priority (suporte varia). Exemplo:
fetch("/api/dados-iniciais", { priority: "high" })Use com cuidado: se você elevar a prioridade de uma chamada que não é essencial para a primeira renderização, pode atrasar CSS, fontes ou imagem principal. Aplique apenas quando a resposta é necessária para montar conteúdo visível imediatamente.
Estratégia combinada: preparando conexões e controlando competição
Uma abordagem prática é pensar em “camadas”:
- Camada 1 (crítico imediato): hosts e recursos que precisam acontecer cedo para o conteúdo inicial. Aqui entram poucos
preconnecte sinais de prioridade alta para 1 ou 2 recursos-chave. - Camada 2 (logo após): recursos importantes, mas não bloqueadores. Aqui entram
dns-prefetchpara hosts prováveis e prioridade normal. - Camada 3 (tarde/condicional): terceiros, widgets, tracking, recursos de rotas internas. Aqui entram prioridade baixa e carregamento sob demanda.
Exemplo de head com rede e prioridade bem comportadas
<!-- Conexões para o que é realmente usado cedo --> <link rel="preconnect" href="https://cdn.exemplo.com" crossorigin> <link rel="preconnect" href="https://fonts.exemplo.com" crossorigin> <!-- Apenas DNS para terceiros prováveis, mas não críticos --> <link rel="dns-prefetch" href="//analytics.exemplo.com"> <link rel="dns-prefetch" href="//chat.exemplo.com">Depois, no body/markup do conteúdo:
<img src="/img/hero.webp" width="1200" height="600" fetchpriority="high" alt=""> <script src="/js/terceiro-opcional.js" defer fetchpriority="low"></script>Como validar se preconnect e dns-prefetch estão ajudando
Checklist de validação
- O host preconnectado aparece de fato nas primeiras requisições?
- O primeiro recurso desse host começa a baixar mais cedo?
- Houve redução perceptível no tempo de espera antes do download (menos “stalled/blocked” e menos tempo até request start)?
- Não houve aumento de competição (por exemplo, downloads críticos começando mais tarde porque conexões foram abertas para terceiros)?
Passo a passo de teste controlado
- Crie duas versões: com e sem
preconnect/dns-prefetch. - Teste em condições de rede simuladas (ex.: 4G/latência alta) e também em rede boa. Ganhos costumam aparecer mais em latência alta.
- Compare o início das requisições para os hosts alvo e o tempo até os recursos críticos completarem download.
- Se o ganho for marginal, remova. Em performance, “menos coisas” frequentemente é melhor do que “mais dicas” ao navegador.
Prioridade e terceiros: evitando que scripts externos dominem a rede
Recursos de terceiros podem abrir conexões adicionais, baixar scripts grandes e disparar cascatas de requisições. Mesmo quando não bloqueiam diretamente a renderização, eles competem por banda e por CPU. Estratégias de priorização ajudam a evitar que esses recursos “passem na frente”.
Táticas práticas
- Use
dns-prefetch(nãopreconnect) para terceiros que não são essenciais no primeiro instante. - Carregue scripts de terceiros com
defere, quando fizer sentido, comfetchpriority="low". - Evite iniciar requisições de terceiros antes de o conteúdo principal estar visível. Se um script externo é disparado por JS, atrase a chamada até um momento seguro (por exemplo, após a primeira pintura relevante ou após interação).
Heurística de decisão rápida (para aplicar no dia a dia)
1) Liste hosts e classifique por criticidade
- Crítico: sem ele o conteúdo inicial não aparece corretamente.
- Importante: melhora a experiência, mas pode vir depois.
- Opcional: métricas, anúncios, widgets, integrações.
2) Aplique a menor intervenção possível
- Para críticos fora do origin:
preconnect(poucos). - Para importantes:
dns-prefetch. - Para opcionais: nada no head; carregue sob demanda e com prioridade baixa.
3) Ajuste prioridade apenas onde a heurística falha
- Se a imagem principal está demorando a começar, avalie
fetchpriority="high"nela. - Se um script secundário está competindo cedo, force
fetchpriority="low"e revise o momento de carregamento.
Erros frequentes e como corrigir
“Coloquei preconnect em 10 domínios e piorou”
Correção: reduza para 1–3 domínios realmente críticos. Troque o restante por dns-prefetch ou remova. Preconnect em excesso aquece conexões que competem com downloads essenciais.
“Usei dns-prefetch e não vi diferença”
Correção: o ganho de DNS isolado pode ser pequeno, especialmente se o DNS já está cacheado ou se o gargalo é outro (TLS, servidor, tamanho do recurso). Use preconnect apenas quando o host for realmente usado cedo e o custo de handshake estiver no caminho crítico.
“Marquei vários recursos como high e nada melhorou”
Correção: prioridade alta demais vira empate. Escolha um único candidato principal (por exemplo, a imagem hero) e deixe o restante em prioridade padrão. Se muitos recursos são “críticos”, o problema pode ser excesso de coisas no caminho inicial, não falta de prioridade.
Modelo de implementação incremental (pronto para aplicar)
Etapa 1: comece pelo CDN e por um host de fonte (se existir)
<link rel="preconnect" href="https://cdn.exemplo.com" crossorigin> <link rel="preconnect" href="https://fonts.exemplo.com" crossorigin>Etapa 2: adicione dns-prefetch para 1–2 terceiros prováveis
<link rel="dns-prefetch" href="//analytics.exemplo.com"> <link rel="dns-prefetch" href="//tagmanager.exemplo.com">Etapa 3: ajuste prioridade do recurso visual mais importante
<img src="/img/hero.webp" width="1200" height="600" fetchpriority="high" alt="">Etapa 4: rebaixe prioridade do que é secundário
<script src="/js/feedback-widget.js" defer fetchpriority="low"></script>Em cada etapa, valide se o início dos downloads críticos ficou mais cedo e se não houve efeitos colaterais (mais competição, mais conexões abertas, mais trabalho desnecessário). O objetivo é um carregamento previsível: conexões prontas para o que importa e recursos baixando na ordem certa.
