Minimize a Subparte de Duração do DNS do Time to First Byte

Minimize a Subparte de Duração do DNS do Time to First Byte

Este artigo faz parte do nosso guia sobre Time to First Byte (TTFB). A duração do DNS é a terceira subparte do TTFB e representa o tempo que o navegador gasta para resolver o nome do seu domínio para um endereço IP. Para visitantes de primeira viagem que não possuem um registro de DNS em cache, a pesquisa de DNS pode adicionar de 20 a 200 milissegundos ao TTFB, dependendo do provedor de DNS, da localização geográfica do usuário e das configurações de TTL dos seus registros de DNS.

O Time to First Byte (TTFB) pode ser dividido nas seguintes subpartes:

• Waiting + Redirect (ou duração de espera)
• Worker + Cache (ou duração de cache)
• DNS (ou duração do DNS)
• Connection (ou duração da conexão)
• Request (ou duração da requisição)

Quer otimizar o Time to First Byte? Este artigo cobre a parte de duração do DNS do Time to First Byte. Se você quer entender ou corrigir o Time to First Byte e não sabe o que significa a duração do DNS, leia o que é o Time to First Byte e como corrigir e identificar problemas de Time to First Byte antes de começar este artigo.

Correção Rápida de DNS: se você está enfrentando latência de DNS no Time to First Byte, mude para um provedor de DNS premium e atualize suas configurações de TTL!

A parte de Duração do DNS do Time to First Byte consiste no tempo em que o navegador está pesquisando o endereço de internet (IP) do seu site. Precisamos de pesquisas de DNS porque nós, humanos, achamos mais fácil lembrar nomes de domínio como "www.exemplo.com", enquanto os computadores exigem endereços IP numéricos para se conectar uns aos outros.

Como Funciona o DNS?

As requisições de DNS estão incluídas na medição do TTFB. Isso significa que o tempo que leva para a requisição de DNS terminar é fatorado na pontuação geral do TTFB.

Quando uma página é solicitada, estas são as etapas que o seu navegador segue para converter o nome de domínio em um endereço IP:

• O cache de DNS do navegador é verificado: Antes de fazer uma consulta de DNS, o navegador primeiro verifica seu próprio cache de DNS para ver se já possui o endereço IP do domínio solicitado. Navegadores modernos armazenam registros de DNS em cache por um período definido para melhorar o desempenho, reduzindo a necessidade de pesquisas de DNS repetidas. Se o registro for encontrado no cache do navegador, o navegador pode usá-lo imediatamente sem consultas adicionais.
• O cache do sistema operacional (OS) é verificado: Se o cache do navegador não contiver o registro de DNS necessário, a requisição é passada para o resolvedor de DNS do sistema operacional, muitas vezes chamado de "stub resolver". O sistema operacional também mantém um cache de DNS e o verificará antes de enviar quaisquer requisições de rede.
• Consulta de DNS: Se o registro de DNS não for encontrado nem no navegador nem no cache do sistema operacional, uma consulta recursiva de DNS é enviada a um resolvedor de DNS, normalmente fornecido pelo Provedor de Serviços de Internet (ISP) do usuário. Este resolvedor atua como um intermediário, lidando com o processo de consultar outros servidores de DNS para encontrar o endereço IP.
  • Servidores de Nomes Raiz (Root Name Servers): O resolvedor primeiro entra em contato com um servidor de nomes raiz, que o direciona para o servidor de domínio de nível superior (TLD) apropriado com base na extensão do domínio (por exemplo, ".com", ".org").
  • Servidores de Nomes TLD: O servidor TLD, em seguida, direciona o resolvedor para o servidor de nomes autoritativo para o domínio específico.
  • Servidor de Nomes Autoritativo: Este servidor mantém os registros de DNS para o domínio e fornece o endereço IP ao resolvedor.
• Retornar o Endereço IP: Depois que o resolvedor de DNS obtém o endereço IP do servidor autoritativo, ele retorna essa informação ao navegador. O navegador pode então iniciar uma conexão com o servidor usando o endereço IP para carregar a página da web solicitada.

Como o DNS Impacta o Time to First Byte?

Para visitantes recorrentes, a pesquisa de DNS geralmente é armazenada em cache no navegador ou no sistema operacional, reduzindo a duração do DNS para quase zero. Para visitantes de primeira viagem, no entanto, a pesquisa recursiva de DNS completa deve ser concluída antes que o navegador possa prosseguir para a etapa de conexão TCP. É por isso que o TTFB é frequentemente pior de forma mensurável para novos visitantes em comparação com os que retornam.

Use dns-prefetch e preconnect para Domínios de Terceiros

Se a sua página carrega recursos de domínios de terceiros (como analytics, fontes ou subdomínios de CDN), o navegador deve resolver o DNS para cada domínio separadamente. Você pode instruir o navegador a iniciar a resolução de DNS precocemente usando o resource hint dns-prefetch:

<!-- DNS prefetch for third-party domains -->
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://cdn.example.com">
<link rel="dns-prefetch" href="https://analytics.example.com">

Para origens críticas de terceiros, onde você sabe que também precisará estabelecer uma conexão TCP e TLS, use preconnect em vez disso, que inclui a resolução de DNS mais o handshake da conexão:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Use dns-prefetch como um fallback para navegadores que não suportam preconnect:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">

Coloque esses hints na <head> do seu HTML o mais cedo possível. Adicione hints apenas para domínios que a sua página realmente usa; adicionar hints para domínios não utilizados desperdiça os recursos do navegador. Para mais técnicas de otimização relacionadas ao carregamento de recursos, consulte nosso guia sobre 103 Early Hints.

Como Minimizar o Impacto do DNS no TTFB

Use um Provedor de DNS Rápido

Alguns provedores de DNS são mais rápidos que outros. Escolher um provedor de DNS rápido e confiável é uma das maneiras mais fáceis de reduzir a latência de DNS. Provedores de DNS premium, como Cloudflare, Amazon Route 53 e Google Cloud DNS, executam servidores em centenas de locais em todo o mundo. Quanto mais próximo o servidor de DNS estiver do seu usuário, mais rápida será a pesquisa.

Aqui está uma comparação de provedores de DNS populares e seus tempos de resposta típicos:

A diferença entre um provedor de DNS premium e um DNS básico de registrador pode ser de 40 a 90 milissegundos por pesquisa (fonte: benchmarks do DNSPerf). Para visitantes de primeira viagem, isso se traduz diretamente em um TTFB mais rápido. Para aprender como configurar a Cloudflare como seu provedor de DNS e CDN, leia nosso guia para configurar a Cloudflare.

Otimize o Time to Live do Cache de DNS

O cache de DNS armazena os resultados das consultas de DNS localmente, reduzindo a necessidade de pesquisas repetidas. Ao definir valores "ideais" de Time-To-Live (TTL) para registros de DNS, você pode controlar por quanto tempo esses registros são armazenados em cache.

Valores de TTL mais baixos significam que os registros expiram mais cedo, causando pesquisas de DNS mais frequentes. Valores de TTL mais altos significam que os registros são armazenados em cache por mais tempo, reduzindo as pesquisas de DNS, mas fazendo com que as alterações de DNS se propaguem mais lentamente. O TTL certo depende da frequência com que você altera seus registros de DNS e do quanto você valoriza a velocidade da pesquisa de DNS em relação à flexibilidade.

Quais São as Configurações Ideais de TTL do DNS?

Ao planejar uma migração de DNS ou mudança de servidor, abaixe temporariamente seu TTL para 5 minutos (300 segundos) pelo menos 24 horas antes de fazer a alteração. Isso garante que, após a alteração, os usuários pegarão o novo endereço IP rapidamente. Uma vez que a migração for concluída e verificada, aumente o TTL de volta para um valor mais alto para reduzir a frequência das pesquisas de DNS.

DICA: se você está usando registros CNAME, considere implementar o CNAME flattening. O CNAME flattening é uma técnica que permite usar um registro CNAME no nível do domínio raiz (apex), resolvendo-o efetivamente para um endereço IP sem violar os padrões de DNS. Isso elimina uma pesquisa de DNS extra que, de outra forma, seria necessária para resolver o CNAME para o seu destino e, em seguida, o destino para o seu endereço IP.

DNS over HTTPS (DoH) e DNS over TLS (DoT)

As consultas de DNS tradicionais são enviadas em texto simples sobre UDP, o que significa que podem ser interceptadas, modificadas ou bloqueadas por intermediários (como ISPs ou operadores de rede). DNS over HTTPS (DoH) e DNS over TLS (DoT) criptografam as consultas de DNS, melhorando a privacidade e a segurança.

Embora DoH e DoT abordem principalmente questões de segurança e privacidade, eles também podem afetar o desempenho da resolução de DNS:

• Impacto na latência: a sobrecarga da criptografia adiciona uma pequena quantidade de latência à conexão inicial de DNS (TLS handshake). No entanto, como as conexões DoH/DoT são persistentes e reutilizadas, as consultas subsequentes na mesma conexão costumam ser mais rápidas do que o DNS tradicional.
• Interferência do ISP: alguns ISPs injetam suas próprias respostas de DNS ou desaceleram as consultas de DNS para não-clientes. O DoH ignora essa interferência inteiramente, o que pode realmente melhorar o tempo de resolução de DNS para os usuários afetados.
• Suporte do navegador: navegadores modernos (Chrome, Firefox, Edge, Safari) todos suportam DoH. Na maioria dos casos, o provedor de DNS padrão do navegador já usa DoH quando disponível.

Para proprietários de sites, você não pode controlar se os seus visitantes usam DoH ou DoT (isso é uma configuração de nível de navegador e sistema operacional). No entanto, você pode garantir que o seu provedor de DNS autoritativo suporte DNSSEC, que fornece uma camada complementar de verificação para respostas de DNS, independentemente da criptografia de transporte.

Medindo a Duração do DNS com JavaScript

Você pode medir a subparte de duração do DNS do TTFB diretamente no navegador usando a Navigation Timing API:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;

  console.log('DNS Duration:', dnsDuration.toFixed(0), 'ms');

  if (dnsDuration > 50) {
    console.warn('High DNS duration detected. Consider:');
    console.warn('1. Switching to a premium DNS provider');
    console.warn('2. Increasing DNS TTL values');
    console.warn('3. Using dns-prefetch for third-party domains');
  }
}).observe({
  type: 'navigation',
  buffered: true
});

Uma duração de DNS de 0ms nos seus dados de RUM normalmente indica que a pesquisa de DNS foi servida a partir do cache do navegador ou do sistema operacional (um cenário de visitante recorrente). Valores acima de 50ms sugerem que o usuário teve que executar uma pesquisa de DNS recursiva completa, o que é comum para visitantes de primeira viagem.

Como Medir Problemas de TTFB Causados por Pesquisas Lentas de DNS

Para descobrir o impacto que os usuários reais experimentam causado pela latência de DNS, você precisará usar uma ferramenta de RUM como o CoreDash. O Real User Monitoring permitirá que você rastreie os Core Web Vitals com mais detalhes e sem o atraso de 28 dias do Google.

No CoreDash, clique em "Time to First Byte breakdown" para visualizar a parte de DNS do Time to First Byte.

Leitura Adicional: Guias de Otimização

Guias relacionados:

• 103 Early Hints: envie resource hints antes que a resposta completa esteja pronta, permitindo que o navegador inicie a resolução de DNS e as conexões para recursos críticos ainda mais cedo.
• Configure Cloudflare for Performance: use a Cloudflare tanto como o seu provedor de DNS quanto de CDN, combinando resolução de DNS rápida com cache na edge e suporte a HTTP/3.

Subpartes do TTFB: Guias Completos

A duração do DNS é uma das cinco subpartes do TTFB. Explore as outras subpartes para entender o panorama completo:

• Fix and Identify TTFB Issues: o ponto de partida de diagnóstico para toda a otimização de TTFB.
• Waiting Duration: redirecionamentos, filas do navegador e otimização de HSTS.
• Cache Duration: desempenho do service worker, pesquisas em cache do navegador e bfcache.
• Connection Duration: TCP handshake, otimização de TLS, HTTP/3 e preconnect.
• Request Duration: tempo de processamento do servidor, consultas de banco de dados e otimização de backend.