Preload, prefetch e preconnect: quando cada um realmente ajuda
Resource hints são úteis quando correspondem a gargalos reais do navegador. Usados às cegas, adicionam ruído de prioridade e, às vezes, tornam as páginas mais lentas.
Tabela de conteúdos
- Resource hints não são mágica
- O que o navegador já faz bem
- Preload: para recursos da página atual descobertos tarde demais
- Preload e imagens LCP
- Prefetch: para a próxima página, não para esta
- Preconnect: para conexões caras com origens importantes
- DNS-prefetch: o primo mais leve
- Como decidir: um fluxo de trabalho prático
- 1. Identifique o gargalo
- 2. Adicione um hint por vez
- 3. Verifique efeitos colaterais de prioridade
- 4. Verifique cabeçalhos e cache
- Erros comuns
- Fazer preload de coisas demais
- Usar prefetch para recursos obrigatórios
- Fazer preconnect para todos os terceiros
- Esquecer as condições móveis
- Uma tabela de decisão simples
- A regra calma
Resource hints não são mágica
preload, prefetch e preconnect muitas vezes são tratados como uma lista de verificação de performance. Adicione algumas tags ao <head>, rode o Lighthouse de novo, sinta-se melhor. Não é assim que eles funcionam.
Esses hints são instruções para o pipeline de carregamento do navegador. Eles podem ajudar quando você sabe algo que o navegador não consegue descobrir cedo o suficiente. Eles podem atrapalhar quando você adivinha, prioriza demais trabalho não crítico ou aquece conexões de que os usuários nunca precisarão.
A versão curta:
- Use
preloadpara recursos necessários à página atual, mas descobertos tarde demais. - Use
prefetchpara recursos de navegação futura provável, não para itens essenciais da página atual. - Use
preconnectpara origens importantes de terceiros em que a configuração da conexão é um atraso real.
A pergunta prática não é “qual hint é mais rápido?” É “pelo que o navegador está esperando, e este hint pode remover essa espera?”
O que o navegador já faz bem
Navegadores modernos não são baixadores passivos de arquivos. Eles analisam HTML, varrem adiante em busca de recursos, atribuem prioridades, reutilizam conexões, adiam trabalho que não está visível e se adaptam às condições de rede.
Isso significa que resource hints devem ser seletivos. Se uma folha de estilo, script, imagem ou fonte já é descoberta cedo e recebe a prioridade correta, adicionar um hint pode não fazer nada. Pior, pode competir com recursos mais importantes.
Antes de adicionar hints, observe um traçado em cascata no DevTools ou um relatório de laboratório. Se você estiver usando Lighthouse, comece pelos diagnósticos em vez da pontuação; temos um guia separado sobre como ler um relatório do Lighthouse sem entrar em pânico — mas observe que a URL correta diferencia maiúsculas de minúsculas, então use o artigo vinculado na navegação do seu site, se necessário.
A evidência real geralmente aparece em três lugares:
- Um recurso crítico começa tarde porque o navegador o descobre tarde.
- Uma conexão com uma origem importante leva tempo perceptível antes da primeira requisição.
- Um recurso da próxima página é altamente previsível e barato de buscar em tempo ocioso.
Se nada disso for verdade, um hint provavelmente é decoração.
Preload: para recursos da página atual descobertos tarde demais
preload diz ao navegador: “Busque este recurso agora porque a página atual vai precisar dele.”
Um exemplo típico é uma web font referenciada dentro do CSS. O navegador precisa baixar o HTML, descobrir o CSS, baixar o CSS, analisá-lo, descobrir a fonte e então solicitar a fonte. Se essa fonte é importante para o texto acima da dobra, a descoberta pode ser tardia o suficiente para causar shifts de layout ou atraso na renderização do texto.
Um preload pode antecipar essa requisição:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>O atributo as importa. Ele informa ao navegador que tipo de recurso é esse, o que afeta prioridade, cache, política de segurança de conteúdo e cabeçalhos da requisição. Fontes também geralmente precisam de crossorigin, mesmo quando servidas pelo mesmo site, porque a busca de fontes usa o modo CORS.
Bons candidatos a preload incluem:
- A web font principal usada para texto visível.
- Uma hero image que é o elemento de Largest Contentful Paint e não é descoberta cedo.
- Um arquivo CSS crítico carregado indiretamente.
- Um módulo ou script necessário muito cedo, mas oculto atrás de outro script.
Maus candidatos a preload incluem:
- Todos os pesos de fonte no design system.
- Imagens abaixo da dobra.
- Scripts que não são necessários para a renderização inicial.
- Recursos que o navegador já descobre no primeiro bloco de HTML.
Preload é poderoso porque afeta a prioridade da página atual. Também é por isso que é fácil usá-lo mal. Se você faz preload de cinco assets grandes, já não está ajudando o navegador. Está discutindo com ele.
Fontes são o caso clássico. Fazer preload de um arquivo de fonte principal pode ajudar. Fazer preload de seis pesos e itálicos geralmente piora as coisas. Se fontes são seu gargalo, corrija primeiro o conjunto de fontes; nosso guia sobre por que web fonts ainda são o ganho de performance mais fácil na maioria dos sites aborda essa limpeza em mais detalhes.
Preload e imagens LCP
Fazer preload de uma imagem LCP pode ser útil quando a imagem não está visível no HTML inicial. Causas comuns incluem imagens de fundo em CSS, componentes renderizados no cliente ou lógica de imagem responsiva que aparece tarde.
Mas, se sua hero image já está no HTML como um <img> com srcset, sizes, dimensões sensatas e sem lazy loading, o navegador provavelmente consegue encontrá-la rapidamente. Nesse caso, adicionar fetchpriority='high' pode ser mais apropriado do que preload, dependendo da página.
Um bom teste: se a requisição da imagem começa tarde na cascata e se torna o elemento LCP, considere preload. Se ela começa cedo, mas baixa lentamente, o problema é tamanho, formato, comportamento da CDN ou latência do servidor — não descoberta. Para decisões sobre formato de imagem, veja quando AVIF supera WebP e quando não supera.
Prefetch: para a próxima página, não para esta
prefetch diz ao navegador: “Este recurso pode ser necessário em breve, mas não é obrigatório agora.”
Essa distinção é importante. Prefetch é intencionalmente de baixa prioridade. O navegador pode buscá-lo durante tempo ocioso e armazená-lo para uso posterior. Também pode ignorá-lo em conexões ruins, modos de economia de dados ou sob pressão de memória.
Use prefetch quando a intenção do usuário for forte o suficiente para tornar provável o próximo recurso.
Bons candidatos a prefetch incluem:
- A próxima etapa em um checkout de várias páginas.
- Resultados de busca depois que um usuário começa a digitar uma consulta, se a próxima rota for previsível.
- Páginas de documentação vinculadas a partir de uma tabela de conteúdos quando o usuário está lendo ativamente conteúdo próximo.
- Chunks de rota em uma single-page app depois que um usuário passa o mouse ou foca um item de navegação.
Maus candidatos a prefetch incluem:
- Toda a sua árvore de navegação.
- Vídeos grandes ou galerias de imagens.
- Scripts de terceiros “só por precaução”.
- Páginas que os usuários raramente visitam em seguida.
Prefetch é onde a moderação compensa. Um recurso buscado e nunca usado não é gratuito. Ele consome largura de banda, capacidade do servidor, energia e possivelmente dados do usuário. Em redes móveis, a busca especulativa pode ser ativamente hostil.
Para muitos sites, a melhor estratégia de prefetch é baseada em intenção. Não faça prefetch da página de preços assim que a home page carrega. Faça prefetch quando o usuário abre o menu de preços, passa o mouse sobre o link de preços ou rola até perto de uma chamada para ação que prevê fortemente a navegação.
Lembre também que o comportamento do navegador varia. Alguns navegadores são conservadores com prefetch; algumas configurações de privacidade reduzem ou desativam o carregamento especulativo. Trate prefetch como uma melhoria oportunista, não como um mecanismo de correção.
Preconnect: para conexões caras com origens importantes
preconnect diz ao navegador: “Comece a configurar uma conexão com esta origem agora.”
Isso pode incluir consulta DNS, conexão TCP e negociação TLS. Para origens de terceiros, essa configuração pode levar centenas de milissegundos, especialmente em redes de alta latência. Se a página em breve precisar de uma requisição crítica dessa origem, preconnect pode tornar a requisição posterior mais rápida.
Exemplo:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Bons candidatos a preconnect incluem:
- Uma origem de fontes usada para texto que bloqueia a renderização.
- Uma origem de API crítica necessária durante a interação inicial.
- Uma origem de CDN servindo assets acima da dobra.
- Um provedor de pagamentos ou identidade necessário imediatamente após uma ação do usuário.
Maus candidatos a preconnect incluem:
- Endpoints de analytics e publicidade que não são críticos para o usuário.
- Origens usadas apenas em algumas sessões.
- Longas listas de terceiros.
- Recursos da mesma origem, em que o navegador já tem ou em breve abrirá a conexão.
Preconnect tem um custo de manutenção. Sockets abertos consomem memória e recursos de rede. Navegadores fecham conexões não usadas, mas isso não torna preconnects desnecessários inofensivos.
Uma regra útil: faça preconnect para, no máximo, uma ou duas origens de terceiros de alta confiança em uma página. Se você sentir vontade de adicionar mais, sua arquitetura de terceiros provavelmente precisa mais de revisão do que seus hints precisam de expansão.
DNS-prefetch: o primo mais leve
Você também pode ver dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Isso apenas resolve o nome de domínio. Não abre uma conexão TCP ou TLS. É mais barato que preconnect, mas também menos útil.
DNS-prefetch pode ser razoável para origens de terceiros de menor confiança, em que preconnect completo parece agressivo demais. Na prática, se uma origem é crítica e definitivamente será usada em breve, prefira preconnect. Se for apenas possível, use DNS-prefetch ou não faça nada.
Como decidir: um fluxo de trabalho prático
Comece com medição, não com tags.
1. Identifique o gargalo
Abra um traçado de performance e procure descoberta tardia. A requisição da fonte, hero image ou script começou apenas depois que outro arquivo foi baixado e analisado? Esse é um candidato a preload.
Se uma requisição começa apenas depois de uma longa configuração DNS/TCP/TLS para uma origem de terceiros, esse é um candidato a preconnect.
Se a página atual está bem, mas a próxima navegação é previsivelmente lenta, prefetch pode ajudar.
2. Adicione um hint por vez
Resource hints interagem. Adicione um, teste e mantenha apenas se a cascata melhorar e as métricas voltadas ao usuário não regredirem.
Para preload, observe se o recurso indicado é realmente usado em breve. O Chrome pode avisar quando um recurso em preload não é usado pouco depois do carregamento. Leve esse aviso a sério.
3. Verifique efeitos colaterais de prioridade
Um preload pode desviar largura de banda de CSS, JavaScript ou imagens mais importantes. Um preconnect pode ocupar um slot de conexão. Um prefetch pode adicionar tráfego em segundo plano.
O resultado correto não é “o arquivo indicado começa mais cedo”. O resultado correto é “a página se torna significativamente melhor para os usuários”. Observe LCP, INP, CLS e monitoramento de usuários reais sempre que possível.
4. Verifique cabeçalhos e cache
Hints podem ser enviados no HTML ou em cabeçalhos HTTP Link. Cabeçalhos são úteis quando o servidor sabe cedo do que a página precisará, mas são mais difíceis de inspecionar casualmente. Se você está depurando se um hint realmente está presente em produção, cabeçalhos brutos importam; esse é exatamente o tipo de situação abordado em nosso guia para depurar redirecionamentos e cabeçalhos HTTP.
Cache também importa. Fazer preload de um recurso com credenciais incompatíveis, as errado ou parâmetros de URL diferentes pode causar downloads duplicados. Essa é uma das formas mais comuns de um preload bem-intencionado virar um bug de performance.
Erros comuns
Fazer preload de coisas demais
Se tudo é crítico, nada é. Limite preload aos recursos necessários para a renderização inicial ou interatividade imediata. Uma página típica deve ter de zero a três preloads, não vinte.
Usar prefetch para recursos obrigatórios
Prefetch é de baixa prioridade e opcional. Não o use para assets exigidos pela página atual. Se a página precisa disso agora, considere preload ou a descoberta normal pelo HTML.
Fazer preconnect para todos os terceiros
Páginas pesadas em terceiros muitas vezes têm dez ou mais origens externas. Fazer preconnect para todas elas cria ruído. Escolha uma ou duas que sejam críticas e previsivelmente usadas.
Esquecer as condições móveis
Resource hints são mais valiosos em conexões mais lentas, mas também são mais perigosos nelas. Um prefetch desperdiçado em uma conexão desktop rápida é um erro de arredondamento. Em um plano móvel limitado, é uma troca ruim.
Uma tabela de decisão simples
| Situação | Melhor hint | Por quê | |---|---:|---| | Fonte crítica descoberta por meio do CSS | preload | A página atual precisa dela, a descoberta é tardia | | Hero image oculta atrás de CSS ou renderização no cliente | preload | Pode melhorar LCP se a imagem começar tarde | | Próxima rota provável após intenção do usuário | prefetch | Ajuda a navegação futura sem bloquear a página atual | | Origem crítica de fonte/API de terceiros | preconnect | Remove a configuração da conexão do caminho crítico | | Origem de terceiros possível, mas incerta | dns-prefetch ou nenhum | Menor custo, menor confiança | | Imagem abaixo da dobra | nenhum | Deixe o lazy loading e a prioridade do navegador trabalharem |
A regra calma
Resource hints funcionam melhor quando são monótonos e específicos. Uma fonte. Uma imagem LCP. Uma origem importante de terceiros. Uma próxima rota provável após intenção.
Funcionam mal quando usados como otimismo: talvez o usuário precise disso, talvez o navegador deva buscar aquilo, talvez mais hints signifiquem mais velocidade.
Navegadores já otimizam agressivamente. Seu trabalho não é microgerenciar cada requisição. Seu trabalho é corrigir os poucos casos em que o navegador não tem informação no momento certo.
Perguntas frequentes
Devo fazer preload de todas as minhas fontes?
É seguro usar prefetch para todos os links internos?
Qual é a diferença entre preconnect e dns-prefetch?
Resource hints podem melhorar Core Web Vitals?
Resource hints devem ser adicionados no HTML ou em cabeçalhos HTTP?
Fontes e leituras adicionais
