Sites estáticos têm ganhado destaque nos últimos anos — e com razão. Eles são rápidos, seguros, exigem pouco do servidor e evitam muita dor de cabeça com plugins, bancos de dados ou picos de tráfego. O problema é que, para a maioria das pessoas que usam WordPress no dia a dia, essa promessa vem acompanhada de uma série de dificuldades: workflows complexos, ferramentas externas, limitações editoriais.
Mas e se fosse possível ter a maior parte dos benefícios de um site estático, sem abandonar o WordPress?
Seções desta página
Por Que Sites Estáticos São Desejáveis
Sites que entregam apenas HTML, CSS e JS direto do disco dispensam processamento PHP, conexões com banco de dados e consumo elevado de CPU ou memória. Isso se traduz em:
- Mais velocidade de carregamento
- Redução da carga no servidor (ideal para hospedagens com muitos sites)
- Menos superfície de ataque (nada sendo executado do lado do servidor)
Para a grande maioria dos sites de conteúdo (blogs, portais, sites institucionais), isso é tudo o que se precisa.
A Abordagem JAMstack
JAMstack é um modelo arquitetônico que propõe separar a camada de exibição do backend tradicional, servindo tudo como arquivos estáticos. O acrônimo vem de JavaScript, APIs e Markup. Em vez de renderizar as páginas no servidor a cada requisição, elas são pré-construídas e entregues por um CDN, como se fossem simples arquivos HTML.
Para isso, ferramentas como Hugo, Eleventy, Next.js, Nuxt, entre outras, são usadas para gerar os arquivos do site a partir de fontes dinâmicas — geralmente conteúdo em Markdown ou APIs externas. O deploy acontece por pipelines automatizados, com integração com Git, staging e builds progressivos.
A promessa do JAMstack é: mais velocidade, mais segurança, menos dependência de servidores PHP e bancos de dados. E, de fato, funciona.
O problema com JAMstack no mundo real
Na prática, esse modelo exige uma mudança radical na forma como se trabalha com conteúdo. O painel do WordPress, onde autores e editores estão habituados a escrever, revisar e agendar posts, precisa ser substituído por outros meios — seja por CMS headless, seja por arquivos versionados em repositórios Git.
Isso significa que o time editorial precisa entender conceitos como branchs, merge requests, builds, preview environments, além de conviver com um ciclo de publicação menos imediato.
Para desenvolvedores, esse fluxo pode ser natural. Mas para redatores, jornalistas e equipes de conteúdo que só querem “clicar em Publicar”, o JAMstack é uma barreira. Isso gera atrito, erros, e uma dependência maior da equipe técnica para tarefas simples do dia a dia.
Além disso, nem todo conteúdo precisa ser tão estático assim — e nem todo time pode se dar ao luxo de reestruturar completamente sua operação para isso.
WP Super Cache: Uma Solução que Já Estava Aí
O plugin WP Super Cache existe há anos e é amplamente utilizado para acelerar o carregamento de páginas no WordPress. Seu modo mais poderoso, porém, ainda é pouco explorado: o cache estático via .html, servido diretamente pelo Nginx ou Apache, sem passar pelo PHP.
Essa funcionalidade permite transformar o WordPress em um site quase-estático, mantendo todo o painel de administração e os plugins funcionando normalmente.
Cache Dinâmico ≠ Cache Estático
Muitos plugins de cache dizem oferecer “cache total”, mas na prática apenas armazenam o HTML em memória ou disco para ser entregue por PHP. Isso reduz o custo da renderização da página, mas ainda executa o WordPress a cada requisição.
No modo estático, o servidor web lê diretamente o arquivo .html no disco, sem chamar o PHP nem conectar ao MySQL. É isso que nos aproxima da performance de um site estático de verdade.
Transformando o WordPress em um Site Quase-Estático
Para isso, você precisa:
- Instalar e ativar o WP Super Cache
- Configurá-lo para usar o modo mod_rewrite (recomendado) ou Serve static html files
- Habilitar o cache para visitantes anônimos
- Ativar a opção de pré-carregamento (preload) para que todas as páginas sejam geradas
Só que… o preload do plugin tem limitações.
Como Garantir que Todas as Páginas Estejam Sempre Pré-Geradas
O preload do WP Super Cache roda em intervalos longos, não cobre taxonomias, CPTs ou paginações, e às vezes simplesmente deixa de funcionar.
Para resolver isso de forma profissional, criamos um script Bash que:
- Detecta o domínio automaticamente
- Gera a lista completa de URLs públicas (posts, páginas, categorias, tags, arquivos, paginações)
- Faz requisições diretas ao Nginx (bypassa Cloudflare)
- Evita hits repetidos verificando se o arquivo
.htmljá existe
#!/usr/bin/env bash
info() { echo -e "\033[1;36m[·] $*\033[0m"; }
ok() { echo -e "\033[1;32m[✓] $*\033[0m"; }
skip() { echo -e "\033[1;33m[↷] $*\033[0m"; }
fail() { echo -e "\033[1;31m[✗] $*\033[0m"; }
section() { echo -e "\n\033[1;34m==> $*\033[0m"; }
detect_wp_root() {
DIR="$(dirname "$(readlink -f "$0")")"
while [[ "$DIR" != "/" ]]; do
if [[ -f "$DIR/wp-load.php" || -f "$DIR/wp-config.php" ]]; then
echo "$DIR"
return
fi
DIR="$(dirname "$DIR")"
done
fail "WordPress root not found."
exit 1
}
WP_ROOT="$(detect_wp_root)"
cd "$WP_ROOT" || exit 1
USER_AGENT="Cache-PriMer/1.0"
SLEEP_SECONDS=1
CACHE_DIR="wp-content/cache/supercache"
BASE_URL=$(wp option get home --allow-root)
DOMAIN=$(echo "$BASE_URL" | awk -F/ '{print $3}')
section "Starting cache priming for: $DOMAIN"
URLS=$(wp eval --allow-root '
$urls = [];
$posts = get_posts(["post_type" => ["post", "page"], "post_status" => "publish", "numberposts" => -1]);
foreach ($posts as $p) { $urls[] = get_permalink($p); }
$cats = get_terms(["taxonomy" => "category", "hide_empty" => true]);
foreach ($cats as $c) { $urls[] = get_term_link($c); }
$tags = get_terms(["taxonomy" => "post_tag", "hide_empty" => true]);
foreach ($tags as $t) { $urls[] = get_term_link($t); }
$post_types = get_post_types(["public" => true, "_builtin" => false], "names");
foreach ($post_types as $cpt) {
$url = get_post_type_archive_link($cpt);
if ($url) $urls[] = $url;
}
$page_for_posts = get_option("page_for_posts");
$base = "";
if ($page_for_posts) {
$slug = get_post_field("post_name", $page_for_posts);
$base = "/$slug";
}
$total_posts = wp_count_posts("post")->publish;
$pages = ceil($total_posts / get_option("posts_per_page"));
for ($i = 2; $i <= $pages; $i++) {
$urls[] = home_url("$base/page/$i/");
}
echo implode("\n", array_filter($urls));
')
COUNT_SKIP=0
COUNT_PRIMED=0
TOTAL=$(echo "$URLS" | grep -c '^')
N=0
while IFS= read -r URL; do
((N++))
RELATIVE_PATH=$(echo "$URL" | awk -F"$DOMAIN" '{print $2}')
RELATIVE_PATH_CLEAN=$(echo "$RELATIVE_PATH" | sed 's#/$##')
CACHE_FILE="$WP_ROOT/$CACHE_DIR/$DOMAIN$RELATIVE_PATH_CLEAN/index-https.html"
if [[ -f "$CACHE_FILE" ]]; then
skip "($N/$TOTAL) Already cached: $RELATIVE_PATH"
((COUNT_SKIP++))
continue
fi
info "($N/$TOTAL) Priming: $URL"
HTTP_CODE=$(curl -sSL --resolve "$DOMAIN:443:127.0.0.1" \
-A "$USER_AGENT" -o /dev/null -w "%{http_code}" "$URL")
if [[ "$HTTP_CODE" =~ ^2 ]]; then
ok "Cached: $RELATIVE_PATH ($HTTP_CODE)"
((COUNT_PRIMED++))
else
fail "Failed: $RELATIVE_PATH ($HTTP_CODE)"
fi
sleep "$SLEEP_SECONDS"
done <<< "$URLS"
section "Finished"
echo -e "Total: $TOTAL | \033[1;33mSkipped: $COUNT_SKIP\033[0m | \033[1;32mPrimed: $COUNT_PRIMED\033[0m"
Code language: Bash (bash)Esse script pode ser executado manualmente ou agendado como um cron ou systemd timer. Ele garante que as páginas mais visitadas já estejam no cache antes mesmo do primeiro visitante do dia chegar.
Vantagens Dessa Abordagem Híbrida
- O painel do WordPress continua funcionando normalmente
- Plugins, shortcodes e editores visuais seguem operantes
- Nada precisa ser enviado para GitHub, Netlify ou S3
- O tempo de carregamento das páginas é igual ao de um site HTML puro
- Pode ser utilizado com o plugin WP Cloudflare Super Cache, para elevar a eficiência do cache ao nível máximo.
Limitações (Spoiler: Ainda Vale a Pena)
Nem tudo será cacheado: páginas administrativas, áreas com login, formulários e requisições AJAX continuarão dinâmicas. Mas para o público visitante, especialmente em portais, blogs e sites institucionais, essa abordagem entrega os mesmos benefícios de um site estático — sem abrir mão da conveniência do WordPress.
Conclusão: um Meio-Termo Eficaz
Se você precisa da performance de um site estático mas não quer (ou não pode) abandonar o WordPress, usar o WP Super Cache com priming controlado é a alternativa realista e sustentável.
Sem modismos, sem dependências externas, sem quebrar fluxos de trabalho editoriais.
Para clientes da PortoFácil, esse equilíbrio entre desempenho e praticidade já está ao alcance: basta solicitar ao suporte a ativação do cache estático com pré-carregamento. Nossa equipe cuida de todos os ajustes — desde a configuração do WP Super Cache até a instalação do script de priming automatizado — garantindo que seu site ofereça a performance de um site estático, sem abrir mão do conforto do painel do WordPress. Tudo pronto para uso, sem necessidade de tocar em linha de código.
Importante: essa técnica é ideal para blogs, portais e sites institucionais. Em sites de e-commerce — especialmente aqueles que usam WooCommerce — o cache estático completo pode não ser adequado, já que páginas como carrinho, checkout e área do cliente precisam permanecer dinâmicas para funcionar corretamente. Nesses casos, nossa equipe poderá orientar a melhor configuração personalizada.