Preload

Preload WordPress é a técnica que avisa o navegador, ainda no início do carregamento da página, quais recursos críticos ele deve baixar com prioridade alta. Em vez de esperar o navegador descobrir sozinho que precisa de uma fonte específica ou de um script principal, o site fala isso de forma explícita via tag link com atributo rel=”preload”. O ganho aparece no Largest Contentful Paint e na percepção de velocidade da primeira tela.

O que é preload

Quando o navegador começa a carregar uma página, ele lê o HTML de cima para baixo, descobrindo recursos à medida que aparecem: o CSS no head, os scripts antes do body, as imagens dentro do conteúdo, as fontes referenciadas dentro do CSS. Esse processo é sequencial e cria uma cadeia de dependências.

O problema é que recursos críticos para a primeira tela podem estar escondidos no fim dessa cadeia. Uma fonte web referenciada dentro de um arquivo CSS, por exemplo, só começa a baixar depois que o CSS termina de baixar e ser parseado. O resultado é que texto fica invisível por meio segundo enquanto o navegador busca a fonte.

O preload resolve isso colocando uma tag link rel=”preload” diretamente no head do HTML. O navegador vê essa instrução logo no início, dispara o download em paralelo e tem o recurso pronto quando o CSS pedir. Quem busca o que é preload geralmente está tentando entender como ferramentas como PageSpeed Insights apontam “preload key requests” como sugestão.

O escopo do preload é limitado. Não é uma bala de prata: usar em recursos errados desperdiça banda e pode até piorar performance. A ideia é cobrir apenas recursos que o navegador realmente precisa cedo e que ele descobriria tarde sem ajuda.

Diferença entre preload, prefetch e preconnect

Preload é para a página atual: “baixe esse recurso agora porque vou usar nesta página em segundos”. Prioridade alta. Bloqueia se necessário. Usado para fontes, scripts críticos e CSS principal.

Prefetch é para a próxima página: “baixe quando estiver ocioso porque o usuário provavelmente vai precisar em seguida”. Prioridade baixa. Não bloqueia nada. Usado para pré-carregar a próxima página de uma sequência ou recursos comuns de áreas para onde o visitante costuma ir.

Preconnect é diferente dos dois: não baixa recurso, apenas estabelece a conexão. “Faça o handshake TCP, TLS e DNS com esse servidor agora porque vou pedir alguma coisa dele logo”. Útil para domínios externos como Google Fonts, CDN de imagens, Google Tag Manager. Quando o pedido real vier, a conexão já está pronta e economiza 100-300 ms.

A confusão entre os três é comum, e usar o errado vira anti-otimização. Preload links de páginas inteiras é prefetch travestido. Preconnect em domínio que você só usa uma vez é desperdício. A regra prática: preload para recursos da página atual que o navegador descobre tarde, prefetch para a próxima navegação, preconnect para domínios externos críticos.

Como implementar preload no WordPress

O caminho mais limpo é via plugin de cache moderno. WP Rocket, Perfmatter, FlyingPress e LiteSpeed Cache têm seções dedicadas para preload de fontes, preload de scripts críticos e preconnect a domínios externos. Você adiciona a URL do recurso e o plugin injeta a tag correta no head.

Para preload fontes, identifique qual fonte aparece na primeira tela do site. Geralmente é a fonte do título principal e a do corpo do texto. Adicione cada uma como preload, com o atributo as=”font” e crossorigin. Sem o crossorigin, o navegador baixa a fonte duas vezes porque a requisição original tem cabeçalhos diferentes da requisição original do CSS.

Para preload de scripts críticos, escolha apenas os que controlam a renderização da primeira tela. Bibliotecas de animação, sliders do hero ou scripts inline grandes são candidatos. Plugins de analytics, pixels de remarketing e scripts de chat não devem entrar em preload nunca, porque não são críticos para o LCP.

Para preconnect, liste os domínios externos que carregam recursos da primeira tela: Google Fonts, CDN de imagens próprio, gravatar para avatares, e similares. Combine isso com cache WordPress bem configurado e lazy loading de imagens fora da primeira tela para fechar o ciclo de otimização de LCP.

Cuidados ao usar preload

O erro mais comum é abusar. Sites com 15 preloads simultâneos saturam a banda do navegador e atrasam recursos que realmente importam. A regra prática: 2 a 4 preloads por página, no máximo. Cada um precisa ter justificativa clara dentro da primeira tela.

Outro erro é fazer preload de recurso que o navegador já descobre cedo. Se a fonte está referenciada em um @font-face inline no head e o navegador já vê isso na primeira leitura, preload é redundante e desperdiça uma posição na fila de prioridades.

Crossorigin esquecido é o terceiro erro clássico. Em fontes, scripts CORS e qualquer recurso de domínio externo, o atributo crossorigin precisa estar presente e bater com a requisição original. Sem isso, o preload baixa o recurso, mas o navegador ignora o cache e baixa de novo.

Por fim, preload em páginas dinâmicas precisa de cuidado. Se o recurso usado na primeira tela varia por categoria, por idioma, por tipo de usuário logado, o preload precisa ser condicional. Plugins permitem regras por tipo de página exatamente para isso. Combine com tuning fino do Lighthouse e meça antes e depois para confirmar ganho real.

Para sites onde performance é métrica crítica, a FULL Services entrega o Perfmatter já licenciado e configurado dentro da stack profissional, com regras de preload pré-tunadas para temas populares, controle granular de scripts críticos e integração nativa com CDN. Em vez de testar preload por preload em PageSpeed e ver o que melhora, você roda em uma stack já validada em produção desde o primeiro deploy.