Minimizar a subparte DNS Duration do Time to First Byte

A DNS duration mede as pesquisas de DNS do navegador. Saiba como escolher um provedor de DNS rápido, otimizar as configurações de TTL, usar dns-prefetch e entender o DNS over HTTPS para reduzir o TTFB.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-05
[include]breadcrumbs.html[\/include]

Minimizar a subparte DNS Duration do Time to First Byte

Este artigo faz parte do nosso guia [url=\/core-web-vitals\/time-to-first-byte]Time to First Byte (TTFB)[\/url]. 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 de primeira viagem que não possuem um registro 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 DNS.

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

  • [url=\/core-web-vitals\/time-to-first-byte\/waitingduration]Waiting + Redirect (ou waiting duration)
  • [url=\/core-web-vitals\/time-to-first-byte\/cacheduration]Worker + Cache (ou cache duration)
  • DNS (ou DNS duration)
  • [url=\/core-web-vitals\/time-to-first-byte\/connectionduration]Connection (ou connection duration)
  • [url=\/core-web-vitals\/time-to-first-byte\/requestduration]Request (ou request duration)

    Quer otimizar o Time to First Byte? Este artigo cobre a parte de DNS duration do Time to First Byte. Se você deseja entender ou corrigir o Time to First Byte e não sabe o que DNS duration significa, leia [url=\/core-web-vitals\/time-to-first-byte]o que é o Time to First Byte[\/url] e [url=\/core-web-vitals\/time-to-first-byte\/fix-and-identify]corrigir e identificar problemas de Time to First Byte[\/url] antes de começar este artigo.

    Correção rápida de DNS: se você estiver 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 DNS Duration do Time to First Byte consiste no tempo em que o navegador está procurando 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.example.com", enquanto os computadores exigem endereços IP numéricos para se conectarem uns aos outros.

    [include]toc.html[\/include]

    Como o DNS funciona?

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

    Quando uma página é solicitada, estes são os passos que seu navegador segue 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 para o domínio solicitado. Os navegadores modernos armazenam registros DNS por um período definido para melhorar a performance, reduzindo a necessidade de pesquisas de DNS repetidas. Se o registro for encontrado no cache do navegador, ele pode usá-lo imediatamente sem novas consultas.
    • O cache do sistema operacional (SO) é verificado: Se o cache do navegador não contiver o registro DNS necessário, a solicitação é passada para o resolvedor de DNS do sistema operacional, muitas vezes chamado de "stub resolver". O SO também mantém um cache DNS e o verificará antes de enviar qualquer solicitação de rede.
    • Consulta DNS: Se o registro DNS não for encontrado nem no cache do navegador nem no do SO, uma consulta DNS recursiva é 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 consulta a outros servidores DNS para encontrar o endereço IP.
      • 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 (ex: ".com", ".org").
      • TLD Name Servers: O servidor TLD então direciona o resolvedor para o servidor de nomes autoritativo para o domínio específico.
      • Authoritative Name Server: Este servidor contém os registros DNS do domínio e fornece o endereço IP ao resolvedor.
      • Retornar o Endereço IP: Assim 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 web solicitada.

        Como o DNS impacta o Time to First Byte?
        A pesquisa de DNS pode retardar o Time to First Byte devido à latência da rede (o tempo que leva para se conectar ao Name Server, neste caso), à qualidade e velocidade do servidor de nomes autoritativo ou ao tempo de cache DNS (já que consultas DNS em cache são muito mais rápidas do que consultas DNS não armazenadas em cache).

        Para visitantes recorrentes, a pesquisa de DNS normalmente é armazenada em cache no navegador ou no SO, reduzindo a duração do DNS para quase zero. Para visitantes de primeira viagem, 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 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 antecipadamente usando a dica de recurso dns-prefetch: 

        <!-- DNS prefetch para domínios de terceiros -->
<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, 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 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 usa; 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 [url=\/pagespeed\/103-early-hints]103 Early Hints[\/url].

                
        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 operam servidores em centenas de locais em todo o mundo. Quanto mais perto o servidor 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:
                
        Provedor de DNS
                            Tempo de Resposta Típico
                            PoPs Globais
                            Recursos Notáveis
                        
                    
                    
        Cloudflare DNS
                            ~11ms
                            300+
                            Nível gratuito disponível, DNSSEC, achatamento de CNAME (flattening)
                        
                        
        Amazon Route 53
                            ~20ms
                            100+
                            Verificações de integridade, roteamento baseado em latência, geolocalização
                        
                        
        Google Cloud DNS
                            ~15ms
                            Anycast global
                            SLA de 100% de disponibilidade, DNSSEC
                        
                        
        NS1
                            ~15ms
                            25+
                            Cadeias de filtros, roteamento DNS inteligente
                        
                        
        DNS típico de ISP\/registrador
                            ~50 a 100ms
                            Limitado
                            Apenas funcionalidade básica
                        
                    
                
                
        A diferença entre um provedor de DNS premium e um DNS de registrador básico pode ser de 40 a 90 milissegundos por pesquisa (fonte: benchmarks [url=https:\/\/www.dnsperf.com\/]DNSPerf[\/url]). Para visitantes de primeira viagem, isso se traduz diretamente em um TTFB mais rápido. Para saber como configurar a Cloudflare como seu provedor de DNS e CDN, leia nosso [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]guia para configurar a Cloudflare[\/url].

                
                
        Otimize o DNS Cache Time to Live (TTL)
                
        O cache DNS armazena os resultados das consultas DNS localmente, reduzindo a necessidade de pesquisas repetidas. Ao definir valores "ideais" de Time-To-Live (TTL) para 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 são armazenados em cache por mais tempo, reduzindo as consultas DNS, mas fazendo com que as alterações de DNS se propaguem mais lentamente. O TTL correto depende da frequência com que você altera seus registros DNS e do quanto você valoriza a velocidade da pesquisa DNS versus a flexibilidade.

                
        Quais são as Configurações Ideais de TTL de DNS?
                
        
                    
        Registros A e AAAA (registros de endereço IP): Para a maioria dos sites: 5 minutos a 1 hora. Para sites estáticos que não mudam frequentemente: 1 a 24 horas.
                    
        Registros CNAME: Normalmente 24 horas.
                    
        Registros TXT e MX: Cerca de 12 horas.
                    
        Registros NS: TTLs mais longos, como 1 a 2 dias, pois são críticos e geralmente estáticos.
                    
        SOA e outros registros estáticos: TTLs mais longos, até alguns dias.
                
                

        Ao planejar uma migração de DNS ou mudança de servidor, diminua 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 obtenham o novo endereço IP rapidamente. Assim que a migração for concluída e verificada, aumente o TTL de volta para um valor mais alto para reduzir a frequência de pesquisas de DNS.

                
        DICA: se você estiver usando registros CNAME, considere implementar o CNAME flattening (achatamento de CNAME). 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 DNS. Isso elimina uma pesquisa de DNS extra que, de outra forma, 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). O DNS over HTTPS (DoH) e o DNS over TLS (DoT) criptografam as consultas DNS, melhorando a privacidade e a segurança.
                
        Embora o DoH e o DoT abordem principalmente questões de segurança e privacidade, eles também podem afetar a performance da resolução de DNS:
                
        • Impacto na latência: o overhead da criptografia adiciona uma pequena quantidade de latência à conexão DNS inicial (TLS handshake). 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 retardam as consultas DNS para quem não é cliente. O DoH ignora essa interferência completamente, o que pode realmente melhorar o tempo de resolução de DNS para os usuários afetados.
                    
        • Suporte do navegador: os navegadores modernos (Chrome, Firefox, Edge, Safari) 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 seus visitantes usam DoH ou DoT (essa é uma configuração no nível do navegador e do SO). No entanto, você pode garantir que seu provedor de DNS autoritativo suporte DNSSEC, que fornece uma camada complementar de verificação para respostas DNS, independentemente da criptografia de transporte.

                
          Medir 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('Alta duração de DNS detectada. Considere:');
    console.warn('1. Mudar para um provedor de DNS premium');
    console.warn('2. Aumentar os valores de TTL do DNS');
    console.warn('3. Usar dns-prefetch para domínios de terceiros');
  }
}).observe({
  type: 'navigation',
  buffered: true
});
                
          Uma DNS duration de 0ms em seus dados RUM normalmente indica que a pesquisa de DNS foi servida do cache do navegador ou do SO (um cenário de visitante recorrente). Valores acima de 50ms sugerem que o usuário teve que realizar uma pesquisa DNS recursiva completa, o que é comum para visitantes de primeira viagem.

                
          Como Medir Problemas de TTFB Causados por Pesquisas de DNS Lentas
                
          Para encontrar o impacto que os usuários reais experimentam causado pela latência de DNS, você precisará usar uma ferramenta RUM como o CoreDash. O Real User Monitoring permitirá que você acompanhe 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: