Pré-busca e pré-carregamento de DNS: otimizar a velocidade do sítio Web

A pré-busca e o pré-carregamento de DNS reduzem ativamente o tempo até ao primeiro conteúdo visível, accionando o DNS, o TCP e o TLS antecipadamente e fornecendo ficheiros críticos com antecedência. Vou mostrar-lhe como utilizar Pré-busca de DNS, Pré-conectar e pré-carregar o Velocidade do sítio Web de forma notável - incluindo código, configuração do WordPress e prioridades testadas e comprovadas.

Pontos centrais

• Pré-busca de DNSA resolução antecipada de nomes reduz a latência.
• Pré-conexãoAbrir DNS, TCP e TLS com antecedência.
• Pré-cargaAtribuição ativa de prioridades aos ficheiros críticos.
• Definição de prioridadesPoucos domínios, mas decisivos.
• MonitorizaçãoVerificar os efeitos na cascata.

Pré-busca de DNS: breve explicação

Com Pré-busca de DNS o navegador resolve antecipadamente o IP de um domínio antes de carregar um ficheiro, poupando assim 20-250 ms por domínio - especialmente em ligações móveis com muito tráfego. Latência. Defino a sugestão para anfitriões externos de que necessito na área acima da dobra, por exemplo, para tipos de letra, análises ou uma CDN. O browser efectua a pesquisa de DNS em segundo plano, encurtando assim o caminho crítico para a primeira apresentação. Por vezes, os browsers modernos utilizam a pré-busca automaticamente, mas eu asseguro o efeito com uma dica clara na cabeça. Isto reduz as viagens de ida e volta, estabiliza o início da renderização e acelera o processo de renderização. Principais dados vitais da Web.

Diferença: pré-busca de DNS vs. pré-conexão

A pré-busca apenas acciona o DNS-enquanto o Preconnect também abre o handshake TCP e TLS e mantém a conexão aquecida. Para hosts críticos, como um CDN para renderizar CSS ou fontes da web, prefiro o Preconnect a apenas o Prefetch. Eu o uso com moderação, pois cada soquete aberto ocupa slots do navegador. O atributo origem cruzada pertence a todos os anfitriões com CORS para que os pedidos posteriores não sejam abrandados. Pode encontrar uma visão geral clara da seleção e sequência no compacto Guia para Prefetch.

Pré-carregamento: Pré-carregar ficheiros específicos

Cargas de pré-carga específicas Arquivos ativamente na cache antes de o analisador os solicitar, acelerando assim o FCP e o LCP. Só o utilizo para recursos que são definitivamente necessários, como CSS essenciais, imagens de heróis ou tipos de letra WOFF2. O atributo prioridade de pesquisa direciona a ponderação para cima sem deslocar completamente outras transferências importantes. Verifico se o tipo MIME, o atributo as e a utilização efectiva correspondem, caso contrário, perco largura de banda. O HTTP/3 é uma boa adição, conforme descrito no artigo sobre HTTP/3 e pré-carregamento descrito.

Ganho de desempenho na configuração do alojamento

Um rápido Hospedagem aumenta o efeito das dicas porque RTTs baixos, HTTP/3 e uma CDN próxima reduzem os tempos de espera por estágio. Vejo regularmente o TTFB cair até um segundo quando o DNS, o TCP e o TLS começam a ser pré-aquecidos e a Origem responde rapidamente. Em dispositivos móveis com alta latência, isso compensa duas vezes, pois cada viagem de ida e volta economizada vai diretamente para o LCP. Presto atenção ao manuseamento estável do TLS, ao agrafamento OCSP e a uma configuração TLS simples. Desta forma, o browser utiliza da melhor forma as suas poucas ligações simultâneas e acelera o Velocidade do sítio Web.

Comparação rápida: que tecnologia para quê?

A tabela seguinte resume as etiquetas de efeito, utilização e exemplo e ajuda-me a escolher a medida certa para cada anfitrião. Combino prefetch para largura, preconnect para hosts críticos e preload para ficheiros essenciais. Mantenho baixo o número de conexões abertas simultaneamente. Isto deixa espaço suficiente para descobertas de analisadores e activos críticos tardios. Esta visão geral toma decisões sobre Definição de prioridades mais fácil.

Tecnologia	O que acontece	Utilização típica	Exemplo de etiqueta	Impacto no FCP/LCP
Pré-busca de DNS	Precoce Resolução de nomes	Anfitriões externos com pedidos posteriores	<link rel="dns-prefetch" href="//fonts.googleapis.com">	Moderadamente positivo, dependendo da latência
Pré-conexão	DNS + TCP + TLS pré-aquecer	CDN, tipos de letra, APIs críticas	<link rel="preconnect" href="https://cdn.example.com" crossorigin>	Claramente positivo, poupa viagens de ida e volta
Pré-carga	Ficheiro ativo pré-carga	CSS crítico, WOFF2, Hero-Image	<link rel="preload" as="style" href="/critical.css">	Muito positivo, se escolhido corretamente

Integração com o WordPress: simples e fácil de manter

No WordPress, defino as sugestões muito cedo no Cabeça, para que o browser os veja antes do estrangulamento do analisador. Desduplico os hosts, verifico a presença de https e adiciono origem cruzada apenas se necessário. O código seguinte coloca as entradas no topo, o que maximiza o efeito. Eu também verifico após as implementações se novos hosts externos foram adicionados. Isso mantém a lista de dicas enxuta, atualizada e eficaz.

função add_dns_prefetch() {
    $domains = ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de', 'https://fonts.gstatic.com'];
    $printed = [];
    foreach ($domains as $domain) {
        $key = preg_replace('#^https?:#', '', $domain);
        se (isset($printed[$key])) { continue; }
        $printed[$key] = true;
        echo '' . "\n";
        if (strpos($domain, 'https://') === 0) {
            echo '' . "\n";
        }
    }
}
add_action('wp_head', 'add_dns_prefetch', 1);

Melhores práticas: concisas mas eficazes

Limito o Preconnect a três ou cinco Anfitriões, caso contrário, o browser bloqueará prematuramente demasiados sockets. Coloco sempre as dicas no início do cabeçalho, seguidas dos pré-carregamentos e depois dos estilos e scripts. Para os tipos de letra, combino Preconnect com apresentação da fonte: swap, para que o texto apareça imediatamente e o CLS se mantenha baixo. Certifico-me de que os ficheiros de pré-carregamento são garantidamente utilizados, caso contrário estou a desperdiçar largura de banda e a não dar prioridade ao que é necessário. No caso de scripts de terceiros, verifico criticamente se cada Domínio é necessário.

Medição e monitorização: tornar o sucesso visível

No separador Rede do DevTools, vejo a ordem de DNS, TCP e TLS e verificar se começam mais cedo do que antes. Uma comparação antes e depois na cascata mostra claramente se as dicas estão a funcionar. Utilizo o Lighthouse ou o PageSpeed Insights para observar o FCP, o LCP e o CLS, bem como a tendência TTFB. O WebPageTest também fornece uma vista de ligação e tiras de filme que documentam o início da renderização. Após grandes alterações, repito a medição e removo os ficheiros desactualizados Anfitriões da lista de sugestões.

HTTP/3, QUIC e fusão de ligações

Com o HTTP/3 através do QUIC, poupo mais Viagens de ida e volta, porque a configuração da ligação, o tratamento de perdas e a multiplexagem funcionam de forma mais eficiente. Verifico se o meu CDN e a minha Origem oferecem HTTP/3 e continuo a utilizar o Preconnect de forma selectiva. A fusão de ligações reduz o número de ligações separadas se os certificados e os IPs coincidirem. Isto permite que os anfitriões com o mesmo certificado sirvam vários subdomínios através de uma ligação partilhada Ligação. Em geral, o caminho de renderização inicial beneficia significativamente, especialmente com muitos ficheiros pequenos.

Combine o aquecimento e a pré-busca da CDN

Aqueço a minha CDN quando prevejo picos de tráfego e combino isto com Pré-busca e Preconnect para hosts Edge. Isto significa que os objectos importantes são armazenados na cache do Edge e que os handshakes já estão preparados. Isto reduz as latências, especialmente nas chamadas iniciais e em condições móveis. Instruções práticas podem ser encontradas no artigo sobre Aquecimento da CDN, que gosto de utilizar como lista de controlo. Antes dos lançamentos, testo as taxas de acerto da cache e observo o TTFB-desenvolvimento.

Governação: Manter a lista de sugestões actualizada

Estou a liderar uma curta Inventário de todos os anfitriões externos e verifico trimestralmente se foram adicionados novos scripts, tipos de letra ou imagens. Elimino as integrações removidas juntamente com a sugestão para manter a lista enxuta. Para cada anfitrião, anoto o objetivo, a importância e a tecnologia utilizada (pré-busca, pré-conexão ou pré-carregamento). Introduzo imediatamente as alterações na CDN ou nas fontes para que não fiquem entradas órfãs. Isto permite-me manter o controlo, reduzir as despesas gerais e garantir a coerência Desempenho.

Suporte do navegador, heurística e limites

Calculo que as sugestões do browser são Sinais não como um comando. Com uma largura de banda reduzida, um protetor de dados ativo ou um separador em segundo plano, o navegador pode ajustar as prioridades ou reduzir as sugestões. O Safari é mais conservador com as pré-conexões, o Firefox tem uma heurística diferente para as caches DNS em alguns casos e as variantes móveis reduzem as tomadas paralelas. É por isso que formulei sugestões preciso e evitar a sobre-sinalização: um pequeno número de anfitriões, uma como-valores, correto tipo-informação. Para as fontes, presto atenção a origem cruzada, caso contrário, existe o risco de duplas pesquisas ou de bloqueio tardio do CORS. Se eu quiser controlar completamente a pré-busca, posso usar <meta http-equiv="x-dns-prefetch-control" content="on"> ou desligado influenciam as heurísticas automáticas.

Cabeçalho HTTP e 103 dicas iniciais

Para além das etiquetas HTML, utilizo Cabeçalho da ligação, para que as dicas cheguem com a primeira resposta do servidor - ideal para renderização no lado do servidor. 103 Early Hints até enviam estes cabeçalhos antes de da resposta final 200 e, assim, ganhar dezenas de milissegundos em linhas longas.

# NGINX: Pré-conexão e pré-carregamento via cabeçalho de link
add_header Link '; rel=preconnect; crossorigin' sempre;
add_header Link '; rel=preload; as=style; fetchpriority=high' sempre;
add_header Link '; rel=preload; as=font; type=font/woff2; crossorigin' sempre;

# Apache (htaccess)
Header add Link '; rel=preconnect; crossorigin'
Cabeçalho adicionar link '; rel=preload; as=image'

O servidor suporta 103 Dicas iniciais, Também envio os cabeçalhos das ligações mais cedo. Importante: guardo a lista curto, porque cada entrada gera um esforço de análise e potenciais aberturas de ligação.

SPA e Service Worker: pré-busca de rotas e dados

Para aplicações de uma só página, utilizo sugestões baseado no estadoAssim que o herói estiver visível, inicio um pré-carregamento direcionado para a rota seguinte (fragmento JS, imagem crítica, esquema API). No Service Worker, posso armazenar em cache os resultados do pré-carregamento e usá-los após os eventos de navegação. Defino critérios de cancelamento claros (separador oculto, CPU sobrecarregada, rede fraca) para que a pré-busca não se torne um fator de custo. Para os módulos ES, defini pré-carregamento do módulo, para que a cadeia de dependências não se torne mais lenta.

<link rel="modulepreload" href="/assets/js/app.entry.js">
<script>
// Vorsichtige SPA-Vorladung
if (navigator.connection?.saveData !== true) {
  const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 300));
  idle(() => {
    const l = document.createElement('link');
    l.rel = 'preload';
    l.as = 'script';
    l.href = '/assets/js/route-checkout.js';
    document.head.appendChild(l);
  });
}
</script>

Segurança, proteção de dados e orientações

Considero os quadros políticos: um quadro estrito CSP pode bloquear os pré-carregamentos se fonte-fonte, estilo-src ou img-src não permitir os alvos. origem cruzada é obrigatório para os tipos de letra, caso contrário a cache não funcionará em todas as origens. Não estabeleço uma ligação prévia com terceiros sensíveis se puder remover o domínio no futuro - cada sugestão é um sinal para o navegador e pode acelerar os scripts de rastreio. Também verifico Guardar dados e Proteção de dadosNesses modos, reduzo a agressividade dos pré-carregamentos e deixo a pré-busca de DNS ativa apenas para os hosts centrais.

Aprofundar a prática de medição: API de temporização e registos

Para além das cascatas, utilizo o API de temporização de recursos e Observador de desempenhocom o objetivo de no terreno para medir se as pistas chegam à frente do analisador e como domainLookupStart, connectStart e secureConnectionStart mover. Isto permite-me reconhecer se uma Preconnect foi realmente utilizada ou se foi rejeitada pelo navegador.

<script>
new PerformanceObserver((list) => {
  for (const e of list.getEntriesByType('resource')) {
    if (e.name.includes('fonts.gstatic.com')) {
      console.log('DNS:', e.domainLookupEnd - e.domainLookupStart,
                  'TLS:', e.secureConnectionStart > 0 ? e.connectEnd - e.secureConnectionStart : 0,
                  'Start:', e.startTime.toFixed(1));
    }
  }
}).observe({ type: 'resource', buffered: true });
</script>

Comparo esses dados com os logs do servidor e as estatísticas da CDN (taxa de retomada do TLS, compartilhamento de HTTP/3, acessos ao cache). Se eu vir que o TLS é quase sempre retomado, posso reduzir o número de pré-conexões ativas e liberar slots para detecções de analisador.

WordPress em profundidade: utilizar os filtros do núcleo de forma limpa

O WordPress já vem com uma infraestrutura para dicas de recursos. Eu ligo-me a wp_resource_hints, em vez de imprimir eu próprio HTML em bruto, e apenas passo alvos deduplicados. Para o pré-carregamento, defino wp_enqueue_style/wp_enqueue_script e adicionar o como-atributos via wp_style_add_data.

// Pré-conexão e pré-busca de DNS através do filtro principal
add_filter('wp_resource_hints', function($urls, $relation_type) {
    $critical = [
        'preconnect' => ['https://fonts.gstatic.com', 'https://cdn.example.com'],
        'dns-prefetch' => ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de']
    ];
    se (!empty($critical[$relation_type])) {
        foreach ($critical[$relation_type] as $u) {
            if (!in_array($u, $urls, true)) { $urls[] = $u; }
        }
    }
    return $urls;
}, 10, 2);

// Enfileirar o pré-carregamento corretamente
add_action('wp_enqueue_scripts', function() {
    wp_enqueue_style('critical', get_stylesheet_directory_uri() . '/assets/css/critical.css', [], null);
    wp_style_add_data('critical', 'preload', true);
    wp_style_add_data('critical', 'as', 'style');

    wp_register_style('font-inter', false);
    wp_enqueue_style('font-inter');
    add_action('wp_head', function() {
        echo '' . "\n";
    }, 2);
}, 1);

Também me certifico de que os plug-ins de otimização (adiar, combinar) Não deixar que as dicas fiquem para trás no analisador. Após a ativação, testo se a ordem na cabeça é mantida e se não existem pré-carregamentos duplicados.

Resolução de problemas e anti-padrões

• Demasiadas pré-ligações: Mais de 3-5 anfitriões desperdiçam tomadas. Eu encurto para o primeira crítica Objectivos (tipos de letra/CDN/API).
• Errado como/tipo: A as="font" sem type="font/woff2" pode levar a uma prioridade incorrecta ou a pedidos duplicados.
• Pré-cargas não utilizadasCada recurso não utilizado obstrui a linha. Removo os pré-carregamentos que não são utilizados com segurança no above-the-fold.
• Origem cruzada esquecidaCom fontes ou CDNs externas, isso leva a problemas de CORS e perda de cache.
• Ordem HTMLAs dicas devem ser colocadas no início do cabeçalho. Pré-carrega antes de estilos, depois renderiza CSS, depois JS crítico.
• Imagesrcset sem tamanhosAcrescento tamanhos das imagens, para que o navegador selecione corretamente e as transferências permaneçam magras.

<link rel="preload" as="image" href="/assets/img/hero.webp"
      imagesrcset="/assets/img/hero.webp 1x, /assets/img/[email protected] 2x"
      imagesizes="(min-width: 1024px) 1200px, 100vw">

Estabelecer prioridades bem fundamentadas

Decido com base em algumas questões: 1) O anfitrião/ativo é garantido antecipadamente necessário? 2) Quão elevado é a latência (móvel, global, CDN fria)? 3) Existem alternativas (subconjunto CSS em linha, auto-hospedagem de tipos de letra)? 4) A ligação é reutilizável? (coalescência, H3, retoma)? 5) Deficiente as descobertas do analisador de medidas? É o seguinte: Prefetch para ganhos amplos e favoráveis; preconnect seletivamente para warmups; preload apenas para garantido ficheiros necessários com uma dactilografia limpa e uma definição correta das prioridades.

Resumo em poucas palavras

Eu uso DNS A pré-busca para ganhos de latência amplos e favoráveis, a pré-conexão para alguns hosts centrais e o pré-carregamento para ficheiros cuja necessidade é garantida. A sequência na cabeça e uma seleção parcimoniosa produzem os maiores efeitos. Meço todas as alterações, verifico as cascatas e ajusto a lista de sugestões regularmente. Em combinação com HTTP/3, uma CDN próxima e uma priorização inteligente de recursos, aumento visivelmente o FCP e o LCP. É assim que utilizo os dns de otimização do browser de forma eficaz e sustentável para aumentar o Velocidade do sítio Web.