Minimizar a Subparte DNS Duration do Time to First Byte

Minimizar a Subparte DNS Duration do Time to First Byte

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

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

• Waiting + Redirect (ou waiting duration)
• Worker + Cache (ou cache duration)
• DNS (ou DNS duration)
• Connection (ou connection duration)
• Request (ou request duration)

Procurando otimizar o Time to First Byte? Este artigo oferece uma análise aprofundada da parte DNS duration do Time to First Byte. Se você deseja entender ou corrigir o Time to First Byte e não sabe o que significa a DNS duration, leia o que é o Time to First Byte e identifique e corrija 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 DNS premium e atualize suas configurações de TTL!

A parte DNS Duration do Time to First Byte consiste no tempo em que o navegador procura o endereço de internet (IP) do seu site. Precisamos de consultas DNS porque nós humanos achamos mais fácil lembrar nomes de domínio como "www.example.com", enquanto os computadores precisam de endereços IP numéricos para se conectarem entre si.

Como o DNS Funciona?

As requisições DNS estão incluídas na medição do TTFB. Isso significa que o tempo necessário para a requisição DNS ser concluída é considerado na pontuação geral do TTFB.

Quando uma página é solicitada, estes são os passos que o seu navegador realiza para converter o nome de domínio em um endereço IP:

• O cache DNS do navegador é verificado: Antes de fazer uma consulta DNS, o navegador primeiro verifica seu próprio cache DNS para ver se já possui o endereço IP do domínio solicitado. Os navegadores modernos armazenam registros DNS em cache por um período definido para melhorar o desempenho, reduzindo a necessidade de consultas DNS repetidas. Se o registro for encontrado no cache do navegador, ele pode ser usado imediatamente sem consultas adicionais.
• O cache do sistema operacional é verificado: Se o cache do navegador não contiver o registro DNS necessário, a requisição é passada para o resolvedor DNS do sistema operacional, frequentemente chamado de "stub resolver". O sistema operacional também mantém um cache DNS e o verifica antes de enviar qualquer requisição de rede.
• Consulta DNS: Se o registro DNS não for encontrado no cache do navegador nem no do sistema operacional, uma consulta DNS recursiva é enviada para um resolvedor DNS, geralmente fornecido pelo provedor de serviços de internet (ISP) do usuário. Este resolvedor atua como intermediário, gerenciando o processo de consulta a outros servidores DNS para encontrar o endereço IP.
  • Servidores de Nomes Raiz: O resolvedor primeiro contata um servidor de nomes raiz, que o direciona ao 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 então direciona o resolvedor ao servidor de nomes autoritativo do domínio específico.
  • Servidor de Nomes Autoritativo: Este servidor contém os registros DNS do domínio e fornece ao resolvedor o endereço IP.
• Retornar o Endereço IP: Assim que o resolvedor 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 solicitada.

Como o DNS Impacta o Time to First Byte?

Para visitantes recorrentes, a consulta DNS geralmente está armazenada em cache no navegador ou no sistema operacional, reduzindo a DNS duration para próximo de zero. Para visitantes pela primeira vez, no entanto, a consulta DNS recursiva completa deve ser concluída antes que o navegador possa prosseguir para a etapa de conexão TCP. É por isso que o TTFB é frequentemente mensuravelmente pior para novos visitantes em comparação com os recorrentes.

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 precisa resolver o DNS de cada domínio separadamente. Você pode instruir o navegador a iniciar a resolução DNS antecipadamente 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 de terceiros críticas onde você sabe que também precisará estabelecer uma conexão TCP e TLS, use preconnect em vez disso, que inclui a resolução DNS mais o handshake de conexão:

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

Use dns-prefetch como 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 essas dicas no <head> do seu HTML o mais cedo possível. Adicione dicas apenas para domínios que sua página realmente utiliza; adicionar dicas para domínios não utilizados desperdiça 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 DNS Rápido

Alguns provedores DNS são mais rápidos do que outros. Escolher um provedor DNS rápido e confiável é uma das maneiras mais fáceis de reduzir a latência DNS. Provedores DNS premium como Cloudflare, Amazon Route 53 e Google Cloud DNS possuem infraestruturas globais extensas. Essas infraestruturas reduzem a distância física entre os usuários e os servidores DNS, eliminando uma parte importante da latência envolvida nas requisições DNS.

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

A diferença entre um provedor DNS premium e um DNS básico de registrador pode ser de 40 a 90 milissegundos por consulta. Para visitantes pela primeira vez, isso se traduz diretamente em um TTFB mais rápido. Para saber como configurar o Cloudflare como seu provedor DNS e CDN, leia nosso guia de configuração do Cloudflare.

Otimize o Time to Live do Cache DNS

O cache DNS armazena os resultados das consultas DNS localmente, reduzindo a necessidade de consultas repetidas. Ao definir valores "ideais" de Time-To-Live (TTL) para os registros 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 consultas DNS mais frequentes. Valores de TTL mais altos significam que os registros ficam em cache por mais tempo, reduzindo as consultas DNS, mas fazendo com que as alterações de DNS se propaguem mais lentamente. O TTL ideal depende da frequência com que você altera seus registros DNS e do quanto você valoriza a velocidade da consulta DNS versus flexibilidade.

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

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

DICA: se você está usando registros CNAME, considere implementar CNAME flattening. 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 DNS. Isso elimina uma consulta DNS extra que seria necessária para resolver o CNAME para seu destino e, em seguida, o destino para seu endereço IP.

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

As consultas DNS tradicionais são enviadas em texto simples via 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 DNS, melhorando tanto a privacidade quanto 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 DNS:

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

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

Medindo a DNS Duration com JavaScript

Você pode medir a subparte DNS duration 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 DNS duration de 0ms nos seus dados de RUM normalmente indica que a consulta DNS foi servida pelo cache do navegador ou do sistema operacional (um cenário de visitante recorrente). Valores acima de 50ms sugerem que o usuário teve que realizar uma consulta DNS recursiva completa, o que é comum para visitantes pela primeira vez.

Como Medir Problemas de TTFB Causados por Consultas DNS Lentas

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

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

Leitura Adicional: Guias de Otimização

Para técnicas de otimização relacionadas que complementam a otimização de DNS, explore estes guias:

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

Subpartes do TTFB: Artigos de Aprofundamento

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

• Identificar e Corrigir Problemas de TTFB: o ponto de partida diagnóstico para toda otimização de TTFB.
• Waiting Duration: redirecionamentos, enfileiramento do navegador e otimização de HSTS.
• Cache Duration: desempenho de service worker, consultas de cache do navegador e bfcache.
• Connection Duration: handshake TCP, otimização TLS, HTTP/3 e preconnect.