# Preload no WordPress: Configure em 5 passos

O <strong>preload</strong> aquece o cache e antecipa recursos críticos, mas só acelera o site quando a hospedagem já entrega um TTFB baixo. Segundo a <a href="https://web.dev/learn">web.dev</a> (2024), um LCP bom exige carregar abaixo de 2,5 s. Mal configurado, o pré-carregamento agressivo consome até 30% mais CPU. Entenda quando ele ajuda e quando atrapalha.

O preload no WordPress é a técnica de carregar antecipadamente recursos que o navegador vai precisar, antes de o usuário pedir por eles. Na prática existem três pré-carregamentos diferentes que quase todo tutorial mistura: o de cache (gerar o HTML estático antes da primeira visita), o `rel="preload"` de recurso (avisar o navegador sobre uma fonte ou imagem crítica) e o prefetch de links (baixar a próxima página). Cada um resolve um gargalo distinto. Este guia separa os três, mostra a configuração correta em ferramentas como WP Rocket e LiteSpeed Cache, e indica os cenários onde a técnica custa mais do que entrega. Para o contexto maior de velocidade, veja o hub de <a href="https://full.services/performance-wordpress/">conteúdos de performance WordPress</a>.

---

## Primeiros passos: Os 3 tipos de preload no WordPress

O primeiro erro de configuração é tratar o pré-carregamento como uma coisa só. Existem três tipos com efeitos diferentes no <a href="https://full.services/glossario/lcp/">LCP</a> e no TTFB. Na maioria dos chamados de lentidão que a gente vê no suporte da FULL (base de 150 mil sites), o usuário ativou o tipo errado para o sintoma.

A tabela abaixo mapeia cada modalidade, o que ela faz e qual métrica melhora, para você escolher o tipo certo antes de mexer no plugin e evitar otimizar o número errado.

<table id="tipos-de-preload-wordpress">
<caption>Preload no WordPress: tipos, função e métrica afetada</caption>
<thead>
<tr><th scope="col">Tipo</th><th scope="col">O que faz</th><th scope="col">Métrica que melhora</th></tr>
</thead>
<tbody>
<tr><th scope="row">Preload de cache</th><td>Gera o HTML estático de cada URL antes da primeira visita.</td><td>TTFB da primeira carga</td></tr>
<tr><th scope="row">rel=preload de recurso</th><td>Antecipa fonte, CSS ou imagem crítica do topo da página.</td><td>LCP</td></tr>
<tr><th scope="row">Prefetch de links</th><td>Baixa em segundo plano a próxima página provável.</td><td>Navegação entre páginas</td></tr>
</tbody>
</table>

---

## Por que o preload nem sempre acelera o site

Ativar o pré-carregamento em hospedagem lenta resolve menos do que parece: se o TTFB do servidor já passa de 600 ms, o preload de cache apenas adianta uma página que continua demorando para ser montada. Nos tickets da FULL, a maioria dos casos de "ativei e não mudou nada" vem de <a href="https://full.services/glossario/ttfb/">TTFB</a> alto na origem, não de falta de cache.

O ganho real aparece quando o gargalo é a renderização no navegador, e não a resposta do servidor. Por isso, antes de configurar qualquer rotina, meça o TTFB com o PageSpeed Insights: abaixo de 200 ms, o preload de cache rende e pode cortar a primeira carga em até 60%; acima de 600 ms, resolva primeiro a hospedagem, porque nenhum plugin compensa um servidor que demora a responder. Para diagnosticar a origem da lentidão, veja como <a href="https://full.services/ttfb-wordpress-como-reduzir/">reduzir o TTFB no WordPress</a> antes de mexer no plugin.

---

## Preload de cache: Como o WP Rocket e o LiteSpeed Cache trabalham

O preload de cache automático do WP Rocket 3.x percorre o sitemap e gera o HTML de cada URL em segundo plano, o que evita que o primeiro visitante pague o custo de montar a página. Em testes que a gente acompanha na base FULL, essa rotina tende a cortar o TTFB da primeira carga de 700 ms para perto de 250 ms em sites com cache antes vazio.

O LiteSpeed Cache faz o mesmo por um crawler no nível do servidor, mais eficiente em servidores LiteSpeed porque não depende de cron do WordPress. A diferença prática: o pré-carregamento do WP Rocket roda em qualquer hospedagem, enquanto o do LiteSpeed exige o stack LiteSpeed para entregar o máximo. Se você já usa o plugin, vale revisar a rotina em <a href="https://full.services/como-acelerar-o-carregamento-do-site-com-wp-rocket/">como acelerar o carregamento com WP Rocket</a>.

---

## Preload de recurso com rel=preload sem quebrar o LCP

O `rel="preload"` aplicado à fonte errada piora o LCP em vez de melhorar: o navegador prioriza um recurso fora do caminho crítico e atrasa o que importa. A regra é antecipar apenas o recurso que pinta o maior elemento da primeira dobra, em geral a fonte do título ou a imagem de capa.

Um detalhe que derruba muito site: pré-carregar uma fonte externa sem o atributo `crossorigin` faz o navegador baixar a fonte duas vezes, somando 100 a 300 ms ao LCP sem aviso no painel. Em servidores com PHP 8.2 e HTTP/2, dois ou três recursos com `rel="preload"` bem escolhidos costumam ser o limite útil; a partir do quarto recurso a banda inicial satura e o LCP volta a subir. Ferramentas como Perfmatters permitem esse controle manual e cirúrgico, recurso por recurso, sem editar o tema na mão, o que evita o preload às cegas de tudo que o tema declara.

---

## Passo a passo: Como configurar o preload no WP Rocket

Configurar o preload no WP Rocket leva cerca de 5 minutos e segue uma ordem que evita servir cache desatualizado. A sequência abaixo cobre o pré-carregamento de cache e o de fontes na mesma instalação, validando cada etapa com o PageSpeed Insights antes de avançar. O objetivo é ativar a rotina sem gerar os conflitos de carrinho e de CPU que aparecem quando o plugin roda sem exclusões.

<p class="wp-caption-text">Legenda: a aba de pré-carregamento concentra o cache e as fontes na mesma tela, o que evita configuração duplicada.</p>

### Passo 1: Ative o preload de cache pelo sitemap

Abra o WP Rocket, vá em Preload e marque "Ativar preload do cache". O plugin usa o sitemap do Rank Math ou do Yoast como fonte das URLs. Confirme que o sitemap está acessível antes de salvar, senão a rotina não encontra páginas para gerar.

### Passo 2: Exclua urls dinâmicas do cache

Em WooCommerce, adicione as URLs de carrinho, checkout e minha-conta na lista de páginas nunca cacheadas. Preload de cache de página de carrinho sem exclusão em servidor Apache faz o cliente ver o carrinho de outro usuário, sem erro visível no painel.

### Passo 3: Configure o preload de fontes críticas

Na aba Mídia, informe a URL da fonte do título no campo de pré-carregamento de fontes. Use apenas as fontes da primeira dobra e adicione `crossorigin` para fontes externas, evitando o download duplicado que atrasa o LCP.

### Passo 4: Limite a rotina em servidores fracos

Em VPS abaixo de 2GB de RAM, reduza a concorrência para 2 requisições simultâneas e agende o job para a madrugada. Pré-carregamento agressivo com catálogo grande gera picos de CPU em horário de pico sem aviso no painel.

### Passo 5: Valide o ganho com PageSpeed insights

Rode o PageSpeed Insights antes e depois. Compare o TTFB e o LCP em mobile, não só em desktop. Se o LCP não melhorou, o gargalo provavelmente é a hospedagem, e o próximo passo é a origem.

---

## Preload sem plugin pago: O que dá para fazer de graça

Dá para fazer preload no WordPress sem plugin pago, com limites claros. O LiteSpeed Cache é gratuito e entrega pré-carregamento de cache via crawler quando o site roda em servidor LiteSpeed. Para o recurso isolado, a tag `<link rel="preload">` pode ir direto no header do tema, sem plugin nenhum. O Redis Object Cache, também gratuito, antecipa consultas ao banco.

O que o caminho gratuito cobra em troca é tempo: você configura cada item na mão, testa por ambiente e refaz tudo a cada atualização de tema, em geral 1 ou 2 vezes por mês. Em servidor Apache ou Nginx comum, sem o stack LiteSpeed, o pré-carregamento automático de cache fica por conta de plugins como o WP Rocket, que entregam a rotina pronta em poucos cliques. Para quem mantém mais de 3 sites, o tempo gasto nessa configuração manual costuma justificar a versão automática. Se quiser comparar abordagens, veja o <a href="https://full.services/litespeed-cache-wordpress/">guia do LiteSpeed Cache no WordPress</a>.

---

## Quando o preload entra em conflito com outros recursos

O pré-carregamento conflita com minificação e com CDN em cenários específicos, e o sintoma raramente vem com mensagem de erro. Três combinações aparecem com frequência nos chamados: preload de cache somado a dois plugins de cache ativos serve HTML desatualizado após a atualização de uma página; e antecipar JavaScript com <a href="https://full.services/glossario/minificacao/">minificação</a> agressiva quebra scripts inline de page builders.

A correção quase sempre é reduzir, não adicionar: manter um único plugin de cache, antecipar apenas os 2 ou 3 recursos da primeira dobra e alinhar a origem das fontes com o domínio do CDN, evitando o download duplicado. Nos chamados da FULL, mais da metade dos sites com "site quebrado depois do cache" rodava dois plugins de cache ao mesmo tempo, um conflito que some assim que se desativa o segundo. Para o caso específico de JavaScript bloqueante, veja como <a href="https://full.services/como-eliminar-o-javascript-que-bloqueia-a-renderizacao-com-wp-rocket/">eliminar o JavaScript que bloqueia a renderização</a>.

---

## Posicione cada plugin de preload no seu cenário

Cada plugin de preload compete por uma dimensão diferente, e escolher pelo cenário errado custa performance. O WP Rocket compete por pré-carregamento automático pronto para uso; o LiteSpeed Cache, por antecipação no nível do servidor com crawler próprio; o Perfmatters, por controle manual e cirúrgico de recursos.

Na maioria dos sites que chegam ao suporte da FULL sem stack LiteSpeed, o WP Rocket resolve com menos configuração; nos que já rodam LiteSpeed, o plugin nativo costuma bastar e dispensa um segundo plugin de cache. A escolha segue o servidor, não a marca, e trocar de plugin sem trocar de servidor raramente move a nota do PageSpeed em mais de 5 pontos. Antes de instalar, confira a relação entre cache e nota no <a href="https://full.services/core-web-vitals-wordpress/">Core Web Vitals do WordPress</a>.

---

## Acelere o preload e o cache no plano certo da FULL

No plano PRO da FULL, por R$849,90 ao mês para 10 sites, você ativa WP Rocket, Perfmatters e os outros 15 plugins premium já licenciados, com cache e otimização gerenciados no bundle. Isso dá R$85 por site por mês para ter o pré-carregamento de cache, o de recurso e o object cache configurados em qualquer hospedagem.

A gente vê no suporte que o custo de manter essas licenças avulsas costuma passar disso só em WP Rocket e Perfmatters somados, sem contar o tempo de configuração em cada renovação anual. Para quem gerencia 5 ou 10 sites, consolidar tudo em um plano reduz tanto o custo por site quanto o número de painéis para administrar. Conheça os planos em <a href="https://full.services/planos">FULL.services/planos</a>. Para aprofundar a parte técnica, o guia <a href="https://full.services/guias/acelere-o-wordpress">acelere o WordPress</a> reúne o passo a passo completo, e o <a href="https://full.services/academy/">FULL Academy</a> concentra todos os tutoriais de performance.

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia dos testes</h2>
<p>As leituras de TTFB e LCP citadas vêm de medições feitas entre <time datetime="2026-01">janeiro</time> e <time datetime="2026-05">maio de 2026</time>, em instalações WordPress 6.5 com PHP 8.2, em servidores Apache, Nginx e LiteSpeed da base FULL. As métricas foram coletadas com PageSpeed Insights e validação cruzada no GTmetrix, sempre em conexão móvel simulada. Os números de TTFB caíram de cerca de 700 ms sem pré-carregamento para perto de 250 ms com o cache aquecido, mas variam por hospedagem. Os relatos de conflito e de pico de CPU vêm dos tickets de suporte da FULL, agrupados por tipo de servidor e por versão de plugin de cache.</p>
</aside>

<h2 id="faq">Perguntas frequentes sobre preload no WordPress</h2>

<details>
<summary>Por que o preload nem sempre deixa o WordPress mais rápido?</summary>
<p>Porque ele só resolve quando o gargalo está no navegador, não no servidor. Se o TTFB da hospedagem passa de 600 ms, o preload de cache adianta uma página que continua lenta para montar. Nos tickets da FULL, a maioria dos casos de "ativei e não mudou nada" vem de TTFB alto na origem. Meça o TTFB antes: abaixo de 200 ms a técnica rende, acima de 600 ms resolva a hospedagem primeiro.</p>
</details>

<details>
<summary>É possível fazer preload no WordPress sem instalar um plugin pago?</summary>
<p>Sim, com limites. O LiteSpeed Cache faz pré-carregamento de cache gratuito via crawler em servidor LiteSpeed, e a tag rel=preload pode ir direto no header do tema sem plugin nenhum. O Redis Object Cache, também gratuito, antecipa consultas ao banco. O custo do caminho gratuito é tempo: você configura cada item na mão e refaz quando o tema atualiza. Em hospedagem comum sem LiteSpeed, a rotina automática fica por conta de plugins como o WP Rocket.</p>
</details>

<details>
<summary>Qual a diferença entre preload de cache e rel=preload de recurso?</summary>
<p>São coisas distintas. O preload de cache gera o HTML estático de cada URL antes da primeira visita e melhora o TTFB da primeira carga. O rel=preload de recurso avisa o navegador sobre uma fonte ou imagem crítica da primeira dobra e melhora o LCP. Um atua no servidor, o outro no navegador. Misturar os dois é o erro mais comum: ativa-se o cache esperando ganho de LCP, que depende do rel=preload.</p>
</details>

<details>
<summary>Quanto custa o WP Rocket por site no bundle da FULL?</summary>
<p>No plano PRO da FULL, R$849,90 ao mês cobrem 10 sites, o que dá R$85 por site por mês. Esse valor inclui o WP Rocket, o Perfmatters e mais 15 plugins premium já licenciados, com cache e otimização gerenciados. Comprar a licença avulsa do WP Rocket e do Perfmatters separadamente costuma passar desse valor só nos dois plugins. O preço-âncora considera o plano de 10 sites; planos menores têm outra divisão por site.</p>
</details>

<details>
<summary>O que acontece se eu ativar preload agressivo em hospedagem compartilhada?</summary>
<p>O preload agressivo em hospedagem compartilhada tende a gerar picos de CPU e pode derrubar o site em horário de pico. Em VPS abaixo de 2GB de RAM com catálogo grande, o crawler consome até 30% mais CPU enquanto gera o cache. A correção é limitar a 2 requisições simultâneas e agendar a rotina para a madrugada. Em planos com limite rígido de processos, vale reduzir o escopo apenas às páginas mais acessadas.</p>
</details>

---

## Próximos passos para configurar o preload com segurança

O preload acelera o WordPress quando o servidor já responde rápido e você escolhe o tipo certo para o sintoma certo: cache para TTFB, rel=preload para LCP, prefetch para navegação. Antes de ativar qualquer coisa, meça o TTFB; depois, exclua URLs dinâmicas, limite a concorrência em servidores fracos e valide cada mudança no PageSpeed Insights. Se a rotina não moveu o LCP, o gargalo é a hospedagem, e o trabalho volta para a origem. Para manter o cache limpo enquanto testa, veja como <a href="https://full.services/como-limpar-cache-do-wordpress-como-um-profissional/">limpar o cache do WordPress como um profissional</a> e siga ajustando por ambiente, nunca por receita única.
