Saltar para o conteúdo 
Pré-busca de DNS e a otimização orientada da cache reduzem significativamente o tempo de espera para a resolução de nomes, porque o navegador consulta os nomes dos anfitriões em segundo plano e fornece respostas a partir de caches rápidas. Combino estas técnicas para reduzir as chamadas iniciais para domínios externos, minimizar os pedidos recorrentes do Cache do resolvedor e, assim, obter sítios Web mensuráveis mais rápidos.
Pontos centrais
- Pré-busca de DNSResolução proactiva de nomes de anfitriões antes de os recursos serem carregados.
- Cache do resolvedorA elevada taxa de acerto reduz significativamente os tempos de pesquisa.
- Estratégia TTLEscolha sabiamente os tempos de funcionamento e reduza-os antes de efetuar alterações.
- Dicas de recursos: dns-prefetch, preconnect, preload clean disconnect.
- RedundânciaVários resolvedores garantem disponibilidade e velocidade.
Porque é que a resolução de DNS torna as coisas mais lentas
Cada recurso começa com um Resolução de nomes, Dependendo da carga da rede, esta primeira viagem de ida e volta pode demorar entre milissegundos e atrasos visíveis. Se eu solicitar muitos fornecedores terceiros, como fontes, análises, CDNs ou anúncios, os atrasos na pesquisa rapidamente se transformam em uma parada percetível no processo. As caches de resolvedores frios têm de descer a cadeia de delegação até aos servidores autoritativos, o que custa saltos adicionais e, por conseguinte, tempo. Se o domínio esteve recentemente na cache local ou recursiva, estes caminhos já não são necessários e a resposta aparece quase imediatamente. Abordo especificamente estas flutuações e adio a resolução em fases em que o utilizador está à espera de qualquer forma, por exemplo durante a análise de HTML, a fim de Perceção e melhorar os valores medidos.
O que faz a pré-busca de DNS
Com dns-prefetch Resolvo os nomes de anfitrião em segundo plano, sem estabelecer TCP ou TLS, e assim preencho as caches do browser atempadamente. Se o utilizador clicar mais tarde numa hiperligação ou descarregar um ficheiro deste domínio, não há atraso na pesquisa e a transferência começa imediatamente. É exatamente isto que compensa para fontes, activos CDN, scripts analíticos ou serviços de pagamento, porque o navegador já prepara os nomes de anfitrião relevantes durante a renderização. O efeito é particularmente notório para os visitantes de primeira viagem, uma vez que ainda não existem entradas locais. Mantenho o número de anfitriões pré-resolvidos baixo, para que a sobrecarga seja minimizada. baixo e o lucro é elevado.
Limites e riscos do prefetching
Por mais útil que a pré-busca de dns seja, não devo exagerar. Cada host resolvido proactivamente gera consultas adicionais, o que pode sobrecarregar a rede e o resolvedor. Além disso, os domínios de terceiros tornam-se visíveis mais cedo, o que em ambientes sensíveis pode ser visto como um Fuga de privacidade aplica-se. Por conseguinte, trabalho com uma lista positiva clara, dou prioridade aos anfitriões com uma elevada probabilidade de acerto e removo os candidatos que raramente são utilizados ou que só aparecem em etapas tardias do percurso. Nas configurações com gestão de consentimento, certifico-me de que a pré-busca só é activada depois de as categorias relevantes terem sido aprovadas. E monitorizo o rácio de milissegundos ganhos em relação às consultas geradas, para que o Efeito líquido correto. Por conseguinte, a pré-busca continua a ser uma ferramenta precisa e não um regador.
Implementação no cabeçalho HTML
Coloco os avisos o mais cedo possível no Cabeça, para que o navegador possa iniciar as resoluções para além da análise. O padrão básico é simples: <link rel="dns-prefetch" href="//example.com">. Para os tipos de letra, utilizo algo como <link rel="dns-prefetch" href="//fonts.googleapis.com"> e, opcionalmente, para o anfitrião estático //fonts.gstatic.com. Acrescento deliberadamente prefetch e não o confundo com pré-conexão ou pré-carga, porque cada dica tem uma tarefa diferente. Se precisar de mais informações, pode encontrar explicações compactas em Pré-busca e pré-carregamento, que utilizo para planear. É assim que mantenho a minha secção de cabeça arrumado e eficaz.
Controlo através de cabeçalho e meta
Alguns navegadores respeitam a ativação ou desativação explícita da pré-busca por cabeçalho. Defino isto deliberadamente quando as políticas são rigorosas ou estão a decorrer testes A/B. Posso ativar a pré-busca globalmente no cabeçalho HTML:
<meta http-equiv="x-dns-prefetch-control" content="on">
Em alternativa, controlo-o no lado do servidor, por exemplo, por caminho ou anfitrião:
# Nginx
add_header X-DNS-Prefetch-Control "on";
# Apache (htaccess)
Conjunto de cabeçalhos X-DNS-Prefetch-Control "on"
Utilizo o controlo de cabeçalhos com moderação, documento as excepções e mantenho a lista dos cabeçalhos que podem ser utilizados por dns-prefetch abordou brevemente os anfitriões. Isto significa que o controlo e Transparência preservado.
WordPress: Automatizar a pré-busca
No WordPress, anexei um pequeno excerto wp_head e manter os domínios de forma centralizada, para que cada tema seja beneficiado de forma limpa. Isto evita que eu tenha de fazer entradas repetidas nos modelos e dá-me um melhor controlo sobre os anfitriões que são realmente relevantes. Um exemplo mostra o procedimento:
<?php
add_action('wp_head', function () {
$hosts = [
'//fonts.googleapis.com',
'//fonts.gstatic.com',
'//cdn.example.com',
];
foreach ($hosts as $host) {
echo '' . "\n";
}
}, 5);
Os plugins de desempenho reconhecem muitas fontes automaticamente, mas eu verifico a lista manualmente e elimino entradas supérfluas. Desta forma, minimizo os pedidos, concentro-me no Candidatos com um efeito mensurável e manter a página rápida.
Delimitar corretamente as sugestões de recursos
Cada pista tem o seu próprio centro de gravidade e, por conseguinte, uma Efeito. O prefetch apenas trata da resolução de nomes, o preconnect pré-configura adicionalmente o TCP e o TLS, o preload carrega um ficheiro específico mais cedo, o prefetch vai buscar recursos para passos posteriores e o prerender prepara mesmo páginas inteiras. Misturo estas opções de forma direcionada, de modo a manter o equilíbrio entre o esforço e o benefício. Eu protejo recursos críticos e muito iniciais com preconnect ou preload; eu cubro todo o resto com dns-prefetch para eliminar o tempo de pesquisa. A seguinte visão geral ajuda-me na seleção e evita mal-entendidos distante:
| Dica | O que acontece | Custos gerais da rede | Utilização típica |
|---|---|---|---|
| dns-prefetch | Apenas resolução de DNS | Muito baixo | Anfitriões externos, espera-se uma utilização rápida |
| pré-conexão | DNS + TCP + TLS | Médio | Anfitriões críticos, ligação imediata |
| pré-carga | Carregar ficheiro de betão | Médio a elevado | CSS/JS/Fonts, rendercritical |
| pré-busca | Carregar ficheiro para mais tarde | Médio | Próximas etapas da viagem |
| pré-processamento | Preparar a página inteira | Elevado | Navegação previsível |
HTTP/2/3, fusão de ligações e QUIC
Com HTTP/2 e HTTP/3, posso poupar mais configurações de ligação se vários subdomínios forem executados através do mesmo IP e de um certificado partilhado. O navegador coalescido e depois pedidos através de uma única ligação. Nesses casos, o dns-prefetch ainda é útil, pré-conexão no entanto, proporciona uma maior vantagem - especialmente se muitos objectos vierem de um anfitrião numa fase inicial. Com o HTTP/3 (QUIC), as retomadas 0-RTT encurtam os apertos de mão se o cliente já tiver bilhetes; o preconnect pode preparar esta rota. Por conseguinte, verifico quais os anfitriões que beneficiam de coalescência, mantenho os certificados consistentes (SAN) e minimizo o número de origens separadas. Desta forma, as sugestões de recursos e os protocolos modernos trabalham em conjunto.
Consolidação de nomes de anfitrião em vez de fragmentação de domínios
O que costumava ajudar nos tempos do HTTP/1 torna as coisas mais lentas atualmente: artificial Fragmentação de domínios cria pesquisas, contactos e contextos adicionais. Por isso, junto os activos estáticos em poucos hosts bem armazenados em cache e dispenso os subdomínios desnecessários. Isto não só reduz a latência do DNS, como também melhora a multiplexagem H2/H3 e a definição de prioridades. Nos casos em que os fornecedores terceiros são inevitáveis, verifico alternativas (por exemplo, auto-hospedagem de tipos de letra), avalio as estratégias de armazenamento em cache e decido conscientemente quais as dependências que são realmente necessárias. Crítico são. Cada domínio eliminado poupa uma resolução - muitas vezes com um efeito maior do que uma entrada de pré-busca adicional.
Resolvedores e caches de DNS: o panorama geral
As caches dos browsers apenas cobrem parte do Viagem A qualidade dos resolvedores recursivos também determina a velocidade e a consistência. Uma elevada taxa de acerto da cache reduz os pedidos aos servidores autorizados, protege a infraestrutura e diminui as latências globais. Prefiro resolvedores com gestão de memória eficiente, latência interna curta e bons tempos de caminho anycast. Para obter informações mais aprofundadas, vale a pena dar uma vista de olhos em Cache do resolvedor, que utilizo como base para as decisões de arquitetura. Isto significa que cada pesquisa beneficia de um poderoso Infra-estruturas.
Serve-Stale e Caching Negativo
Utilizar resolvedores potentes Servir-Salgado, para continuar a fornecer entradas expiradas num curto espaço de tempo, enquanto actualiza em segundo plano. Isto suaviza os picos de carga e protege contra falhas de autoridade, sem a necessidade de Latência alta. Ao mesmo tempo, presto atenção ao armazenamento em cache negativo: as respostas NXDOMAIN são armazenadas em cache de acordo com as especificações SOA e podem conservar estados de erro demasiado longos. Mantenho os TTLs negativos moderados, monitorizo a taxa de pedidos falhados e corrijo consistentemente as fontes de erro de digitação (por exemplo, URLs de script incorrectos). Juntamente com resolvedores seguros (revalidação de stale), a entrega permanece estável, mesmo que os servidores upstream flutuem temporariamente.
Estratégia TTL com um plano
O TTL de um registo controla o tempo que as respostas permanecem válidas nas caches, controlando assim diretamente o número de consultas futuras. Antes de fazer alterações nos registos A, AAAA ou CNAME, reduzo o TTL para cerca de 300 segundos, com vários dias de antecedência, para que a troca tenha efeito rapidamente. Depois de uma alteração bem sucedida, aumento novamente o TTL para utilizar mais as caches e reduzir a carga no resolvedor. Para entradas com rotação frequente, como por exemplo atrás de balanceadores de carga, escolho valores mais curtos e mantenho-me atento à taxa de acerto. Este ciclo mantém o equilíbrio entre adaptabilidade rápida e Eficiência.
Cadeias CNAME, SVCB/HTTPS e nivelamento
Longo Cadeias CNAME custam pesquisas adicionais. Mantenho a profundidade baixa e, sempre que possível, uso mecanismos de achatamento (ALIAS/ANAME) para que o Apex permaneça resolvível sem um salto extra. Os registos SVCB/HTTPS modernos agrupam parâmetros de ligação (por exemplo, escrows Alt-Svc) no DNS e podem acelerar os handshakes. Introduzo estas inovações gradualmente, verifico a compatibilidade do resolvedor e selecciono o TTLS de forma concertada para que as caches beneficiem. O objetivo: menos saltos relacionados com a delegação, caminhos mais claros e resolução de nomes que seja consistente rápido restos.
Monitorização e limpeza da cache
Após as actualizações do DNS, verifico o Propagação em todos os locais e avaliar quais resolvedores já estão fornecendo novas respostas. Limpo especificamente as caches locais: Sistema operativo (por exemplo, através de ipconfig/flushdns), tabelas DNS internas do navegador, routers ou firewalls com as suas próprias funções DNS. Ao mesmo tempo, meço as durações de pesquisa de diferentes regiões para reconhecer os atrasos causados por resolvedores distantes. Esta perspetiva ajuda-me a evitar falsas conclusões, porque uma única localização rápida não conta a história toda. Só quando a maioria das localizações fornece consistentemente novas entradas é que a alteração é considerada aplicadas.
Medição em pormenor: Tempo de navegação e RUM
A fim de fornecer provas fiáveis dos efeitos, avalio Navegação/Cronograma de recursos de: domainLookupStart até domainLookupEnd mostra a fase de pesquisa por recurso. Registo estes valores através do RUM, segmento por dispositivo, tipo de rede e localização e considero p50/p90/p99, e não apenas valores médios. Também faço a correlação com connectStart/connectEnd, TTFB e FCP para reconhecer se as limitações estão no DNS, no aperto de mão ou no servidor. Os testes A/B com e sem prefetching separam a causalidade da correlação. Só quando várias métricas melhoram de forma consistente é que eu adoto as configurações permanente.
Combinar a minimização de consultas de forma sensata
Durante a resolução recursiva, muitos resolvedores truncam a mensagem transmitida FQDN em fases para aumentar a proteção dos dados. Esta minimização de consultas reduz a divulgação, mas pode gerar mais consultas individuais se a cache estiver mal preenchida. Eu confio numa combinação de minimização de consultas e numa elevada taxa de acerto da cache para que a segurança e a velocidade andem de mãos dadas. A observação continua a ser importante: se o número de etapas de delegação aumentar de forma mensurável, verifico se os TTL, a cache negativa e a estrutura da zona são consistentes. Desta forma, o efeito protetor é mantido sem Latência para conduzir.
DoH/DoT e DNSSEC em resumo
Resolução encriptada através de DoH/DoT protege os conteúdos e pode funcionar de forma estável graças às ligações TLS persistentes. Comparo as latências de diferentes fornecedores, presto atenção à proximidade de anycast e utilizo resolvedores locais com DoT a montante, quando apropriado. DNSSEC aumenta a fiabilidade, mas aumenta os pacotes de resposta - o tratamento limpo do EDNS e a prevenção da fragmentação são obrigatórios. Para a renovação de chaves, planeio o TTLS de forma conservadora e monitorizo os erros de validação. Desta forma, combino segurança com velocidade sem provocar surpresas na cadeia.
Redundância e alta disponibilidade
Se um resolvedor individual falhar ou ficar sob carga, o Tempo de resposta É por isso que planeio vários resolvedores através de redes e localizações separadas. Os nós Anycast e distribuídos garantem que os pedidos encontram o caminho mais rápido e acessível. A monitorização dos tempos de pesquisa e das taxas de erro revela os estrangulamentos numa fase inicial e desencadeia redireccionamentos antes de os utilizadores terem de esperar. Para as etapas de planeamento, utilizo visões gerais práticas como Desempenho do resolvedor, a fim de dar prioridade aos parafusos de ajuste corretamente. Deste modo, a resolução do nome mantém-se inalterada mesmo em caso de falhas parciais. Fiável rápido.
IPv6 e globos oculares felizes
A pilha dupla traz velocidade se os caminhos IPv6 forem bons - caso contrário, custa dinheiro. Olhos felizes Tempo, porque A e AAAA estão a competir. Verifico se os nós CDN estão tão próximos e disponíveis via IPv6 como via IPv4 e optimizo o encaminhamento e os registos em conformidade. Se ocorrer regularmente um timeout na rota AAAA, perco milissegundos antes de cada ligação ser estabelecida. A conetividade v6 limpa, o TTLS consistente e a monitorização das taxas de sucesso A/AAAA garantem que a pilha dupla continua a ser uma vantagem e não se torna um problema oculto. travão ...a vontade.
Guia prático: em cinco passos
1. inventárioFaço uma lista de todos os anfitriões externos que o meu sítio utiliza (tipos de letra, activos CDN, serviços de script, sistemas de pagamento) e organizo-os por relevância e frequência.
2. seleçãoOs candidatos com utilização precoce e latência percetível recebem dns prefetch; deixo de fora as fontes raras ou tardias para manter as despesas gerais baixas.
3. instalação: Eu defino o <link rel="dns-prefetch">-tags no topo do cabeçalho, testar variantes e limpar consistentemente os anfitriões desactualizados.
4. TTLAntes das alterações planeadas, reduzo temporariamente o TTL, valido a propagação e depois aumento-o para obter um melhor efeito de cache.
5. mediçãoAs comparações antes e depois da duração da pesquisa, TTFB e FCP mostram o efeito; utilizo isto para derivar as próximas optimizações.
Brevemente resumido
Eu fixo Pré-busca de DNS a fim de resolver os nomes dos anfitriões antes da recuperação efectiva, evitando assim pesquisas frias. Também optimizo as caches dos resolvedores e os valores TTL para que as respostas venham muitas vezes diretamente de memórias rápidas. Uma separação clara das sugestões de recursos evita escolhas erradas e minimiza as despesas gerais. Estruturas redundantes de resolvedores e uma boa monitorização garantem a disponibilidade em caso de picos de carga ou falhas. Se agrupar estes componentes, encurtará visivelmente os tempos de carregamento, aumentará a fiabilidade da resolução de nomes e oferecerá aos visitantes uma experiência de utilizador tranquila. Experiência.
