WordPress 4.5 – A nova página de Edição de Termos
Com a nova versão do WordPress 4.5, novas funcionalidades o acompanham, especialmente a nova página para a edição de termos.
DNS lookup é o processo em que o navegador converte um nome de domínio (como apiki.com) no endereço IP do servidor correspondente antes de baixar qualquer recurso da página. Cada domínio externo carregado em um site WordPress dispara um novo DNS lookup, adicionando de 20ms a 120ms ao tempo de carregamento, segundo dados do Web Almanac de Performance do HTTP Archive.
Se você gerencia um site WordPress em escala, com vários editores publicando e dezenas de scripts de terceiros acumulados ao longo do tempo, provavelmente já viu esse efeito na prática: páginas que demoram a iniciar o carregamento sem motivo aparente. Boa parte desse atraso acontece antes do primeiro byte chegar ao navegador, durante a resolução de DNS. Neste artigo, mostramos como medir, entender e reduzir DNS lookup para acelerar o WordPress de verdade, sem depender de mágica de plugin.
O que é DNS lookup?
DNS lookup é a etapa de tradução entre o nome legível de um domínio e o endereço IP do servidor que responde por ele. O navegador não sabe conversar diretamente com “fonts.googleapis.com”: ele precisa primeiro descobrir qual IP corresponde a esse nome antes de abrir qualquer conexão.
A analogia mais direta é a agenda do celular. Você liga para um contato pelo nome, mas o aparelho consulta o número antes de completar a chamada. No DNS, esse número é o endereço IP.
A resolução de DNS não acontece em um passo único. Ela percorre quatro estágios encadeados:
- Recursive resolver: servidor DNS do provedor de acesso ou de um serviço como o Cloudflare, que recebe a consulta e coordena toda a busca em nome do navegador.
- Root server: indica qual servidor responde pela extensão do domínio, seja .com, .br ou .org, direcionando o próximo passo da consulta.
- TLD server: servidor da extensão do domínio que aponta para o servidor autoritativo responsável por aquele domínio específico.
- Authoritative server: entrega o endereço IP final que o navegador vai usar para abrir a conexão TCP e baixar os recursos.
Quando o resultado já está em cache no navegador ou no resolver, a resposta é quase instantânea. Quando não está, toda a cadeia precisa ser percorrida. Por isso o primeiro acesso a um domínio novo costuma ser o mais lento.
Por que o DNS lookup impacta a performance do WordPress?
Cada domínio novo carregado em uma página obriga o navegador a executar uma sequência completa antes de baixar qualquer arquivo: DNS lookup, abertura de conexão TCP e handshake TLS. Só depois disso o primeiro byte do recurso começa a chegar. Não é o servidor que está lento: é a fila de resoluções que roda antes do primeiro byte.
Esse tempo pesa diretamente no LCP (Largest Contentful Paint), uma das métricas dos Core Web Vitals do Google. Se a imagem principal da página vem de um domínio externo que ainda não teve o DNS resolvido, o LCP só dispara depois de toda a negociação de rede terminar. Em conexões móveis, onde a latência por requisição cresce, o impacto é ainda maior.
Vale entender o mecanismo por trás disso. O navegador resolve vários domínios em paralelo, mas existe um limite prático. Quando a página depende de 20 ou 30 domínios distintos (fontes, analytics, pixels, chat, CDN externa), a fila de resoluções de DNS vira gargalo. Reduzir DNS lookup gera ganhos em cascata: do tempo de carregamento à estabilidade da renderização, com impacto direto nos Core Web Vitals.
Como medir o tempo de DNS lookup de um site?
Medir antes de otimizar é regra. Sem número, você não sabe onde está o gargalo nem se a mudança trouxe ganho real. Estas são as ferramentas que usamos no dia a dia aqui na Apiki:
- Chrome DevTools: abra a aba Network, clique em uma requisição e veja a seção Timing. O campo “DNS Lookup” mostra o tempo exato gasto na resolução daquele domínio específico.
- WebPageTest: gera um waterfall completo com o tempo de DNS isolado por recurso, ideal para auditar quais domínios externos estão custando mais na sua página.
- Comandos dig e nslookup: executados no terminal, consultam o servidor autoritativo e medem o tempo de resposta da resolução de DNS direto na fonte, sem interferência do navegador.
- PageSpeed Insights: aponta a recomendação “Reduce DNS lookup time” quando identifica domínios externos pesando no carregamento da página.
Um exemplo prático com o comando dig ajuda a ler o resultado. Ao rodar dig apiki.com +stats, a saída inclui uma linha como Query time: 24 msec, que indica quanto tempo o servidor DNS levou para responder aquela consulta. Repita a consulta e o tempo tende a cair, porque a resposta passa a vir do cache.
Para uma visão mais ampla do site, vale combinar essas medições com as ferramentas de análise de performance WordPress que reunimos em outro conteúdo.
Quantos DNS lookups uma página WordPress costuma disparar?
A maioria dos sites WordPress acumula DNS lookups sem critério. Cada plugin de marketing, cada botão social e cada fonte hospedada fora adiciona pelo menos um domínio novo à página. A tabela abaixo mostra um panorama típico que encontramos em auditorias internas da Apiki:
| Tipo de site WordPress | DNS lookups médios | Domínios externos comuns |
|---|---|---|
| Blog institucional sem otimização | 12-18 | Google Fonts, GA4, GTM, Gravatar, jQuery CDN, Facebook |
| E-commerce WooCommerce médio | 18-28 | Anteriores + gateway, antifraude, chat, pixel de remarketing |
| Site otimizado (self-host + GTM consolidado) | 4-7 | CDN própria, GTM, gateway de pagamento |
A diferença entre as faixas não é detalhe. Cada lookup a menos elimina uma negociação de rede inteira antes do recurso carregar. Sair de 25 para 6 domínios pode representar segundos de economia no carregamento móvel.
Como reduzir DNS lookup em sites WordPress?
A lógica é simples: menos domínios externos, menos resoluções de DNS. Estas são as ações com melhor retorno para reduzir DNS lookup no WordPress:
- Self-host de Google Fonts: hospede as fontes no próprio domínio em vez de carregá-las de fonts.googleapis.com. O plugin OMGF automatiza esse processo no WordPress, ou você pode baixar os arquivos WOFF2 e servi-los manualmente pelo tema.
- Consolidar scripts de tracking: use o Google Tag Manager como container único para GA4, pixels e tags de remarketing. Em vez de cada ferramenta abrir seu próprio domínio, o GTM centraliza boa parte do carregamento em uma única resolução.
- Remover botões sociais com script externo: botões oficiais de redes sociais carregam scripts de domínios próprios que disparam DNS lookup. Substitua por botões estáticos com links simples, que não exigem nenhuma resolução extra.
- DNS prefetch para domínios inevitáveis: antecipe a resolução de DNS de domínios externos não-críticos, como serviços de analytics, para que o navegador já tenha o IP pronto quando precisar do recurso.
- Preconnect para domínios críticos: abra a conexão completa com antecedência para recursos que afetam o LCP, como a CDN que serve a imagem principal ou o domínio do checkout.
O uso de DNS prefetch e preconnect é feito com tags no <head> do site. Estes são os snippets prontos para colar:
<link rel="dns-prefetch" href="https://fonts.gstatic.com"><link rel="preconnect" href="https://cdn.seusite.com" crossorigin>
Outra recomendação é manter o servidor em HTTP/2 e paralelismo de requisições, que ajuda o navegador a processar várias conexões de forma mais eficiente. Os detalhes de implementação estão na documentação oficial do web.dev sobre preconnect e dns-prefetch.
DNS prefetch, preconnect ou preload: qual usar?
Esses três recursos parecem fazer a mesma coisa, mas atuam em camadas diferentes da negociação de rede. Escolher o errado desperdiça banda ou não resolve o gargalo. A tabela abaixo deixa a diferença clara:
| Recurso HTML | O que faz | Custo de rede | Quando usar | Suporte |
|---|---|---|---|---|
| <link rel=”dns-prefetch”> | Resolve apenas o DNS do domínio | Baixo (5-20ms economizados) | Domínios de terceiros não-críticos (analytics, pixels) | 96% dos navegadores |
| <link rel=”preconnect”> | Resolve DNS + abre TCP + handshake TLS | Médio (100-300ms economizados) | Domínios críticos que servem recursos do LCP (CDN de imagem, fontes) | 95% dos navegadores |
| <link rel=”preload”> | Baixa o recurso completo antecipadamente | Alto (consome banda no carregamento inicial) | Recursos conhecidos e críticos (fonte WOFF2, imagem hero) | 94% dos navegadores |
Os dados de suporte vêm do levantamento de compatibilidade do caniuse.com. Na prática, use dns-prefetch como rede de segurança barata para muitos domínios e reserve preconnect para os dois ou três domínios realmente críticos. Abrir preconnect demais consome recursos do navegador sem retorno claro. Os detalhes técnicos estão na referência MDN sobre preconnect.
Perguntas frequentes sobre DNS lookup
Qual é o tempo ideal de DNS lookup?
Um DNS lookup saudável costuma ficar abaixo de 50ms com cache quente e até 120ms na primeira resolução, segundo dados do Web Almanac do HTTP Archive. Valores acima de 200ms por domínio indicam servidor DNS lento ou TTL mal configurado, e merecem investigação com dig ou WebPageTest.
DNS lookup afeta o SEO?
Sim, de forma indireta e mensurável. O tempo de DNS lookup entra na composição do LCP, uma das métricas dos Core Web Vitals que o Google usa como sinal de ranqueamento. Reduzir DNS lookup melhora o LCP, o que reforça a avaliação de experiência da página no ranqueamento de busca.
DNS prefetch funciona em todos os navegadores?
O dns-prefetch tem suporte em cerca de 96% dos navegadores em uso, incluindo Chrome, Firefox, Safari e Edge, segundo o caniuse.com. Em navegadores antigos que não reconhecem a tag, ela é simplesmente ignorada, sem gerar erro nem quebrar a página.
O Cloudflare reduz DNS lookup?
O Cloudflare atua como resolver e servidor autoritativo de alta performance, com pontos de presença distribuídos globalmente, o que reduz a latência da primeira resolução. Ele não elimina a quantidade de domínios da sua página, mas torna cada lookup mais rápido. Para reduzir a quantidade de lookups, ainda é preciso consolidar scripts e fazer self-host de recursos.
Quanto tempo dura o cache de DNS do navegador?
O tempo de cache é controlado pelo TTL definido nos registros DNS do domínio, geralmente entre alguns minutos e algumas horas. Enquanto o registro está em cache, o navegador reutiliza o IP sem disparar novo DNS lookup. TTLs muito baixos aumentam a frequência de resoluções e podem prejudicar a performance.
Vale a pena usar múltiplos servidores DNS?
Usar servidores DNS redundantes é recomendável para disponibilidade, garantindo que a resolução continue funcionando se um provedor falhar. Para performance, o que importa mais é a velocidade e a distribuição geográfica do resolver do que a quantidade de servidores. Um provedor DNS rápido com cache eficiente costuma render mais que empilhar servidores.
Conclusão
Reduzir DNS lookup é uma das otimizações de melhor custo-benefício no WordPress: mexe pouco no código, mas ataca o atraso que acontece antes do primeiro byte, exatamente a fase invisível que os plugins de cache não resolvem sozinhos. O caminho é sempre o mesmo: medir com DevTools ou dig, cortar domínios externos desnecessários, fazer self-host de fontes, consolidar tracking no GTM e reservar preconnect apenas para os domínios críticos do LCP.
Na prática, muito desse ganho depende da infraestrutura por baixo do site. Aqui na Apiki, nossa hospedagem WordPress gerenciada já entrega CDN integrada e cabeçalhos de preconnect configurados por padrão, o que elimina boa parte do trabalho manual de reduzir DNS lookup e acelerar o WordPress. Se o seu time convive com páginas lentas e dependência da TI interna para cada ajuste, fale com a gente e leve essa otimização para o nível de infraestrutura.
