Headless WordPress, ISR ou SSR: escolher o modo de renderização pelo ritmo do conteúdo
A pergunta “ISR ou SSR” só faz sentido rota a rota. Não existe uma resposta para o site inteiro. O Astro e o Next.js permitem escolher o modo ao nível da página ou do layout, e a abordagem de engenharia madura é decidir de forma deliberada, rota a rota, com base num modelo de quantas vezes o conteúdo muda.
Este artigo faz parte do pilar do serviço headless WordPress e complementa a matriz de decisão Next.js ou Astro, que trata da escolha ao nível do framework.
Em resumo
- O ISR (ou estático com revalidação) ganha quando o ritmo de alteração do conteúdo é previsível e o tráfego é elevado.
- O SSR ganha quando a página é personalizada, depende da sessão ou contém dados em tempo real.
- A correção do ISR depende da invalidação da cache; os webhooks são melhores do que a revalidação temporal.
- O Cloudflare Workers executa os dois; o ISR quase não gasta CPU, o SSR paga a renderização completa.
- O ponto de partida é o modo mais barato que garante um resultado correto; passe para SSR apenas quando for necessário.
SSG, ISR e SSR explicados para WordPress
Geração estática de sites (SSG). A página é construída uma vez, no momento do build, e servida como HTML simples. A mais barata no momento do pedido, a mais lenta a atualizar.
Incremental Static Regeneration (ISR). A página é construída uma vez, mas pode ser regenerada perante um gatilho, normalmente um webhook na publicação ou um intervalo de revalidação temporal. Barata no momento do pedido, com consistência eventual nas atualizações.
Server-Side Rendering (SSR). A página é renderizada a cada pedido. Sempre atual, mas o custo de execução cresce com o tráfego. Personalização, autenticação e dados em tempo real encaixam aqui de forma natural.
No WordPress headless, os três modos leem da origem WordPress através de REST ou GraphQL. A diferença está no momento em que leem.
Quando usar ISR e quando usar SSR no WordPress headless
Contam dois fatores:
Ritmo de alteração do conteúdo. Com que frequência esta página muda? Uma vez por trimestre, uma vez por dia, a cada minuto, em tempo real?
Superfície de personalização. A página muda consoante o visitante? Estado de sessão iniciada, preços consoante a localização, variante de um teste A/B.
A regra: escolha o modo mais barato que garante um resultado correto. O estático é o mais barato. O SSR é o mais caro. Avance para SSR apenas quando um modo mais barato não der um resultado correto.
| Tipo de página | Modo por omissão | Porquê |
|---|---|---|
| Páginas de marketing, artigos do blogue | Estático (reconstrução na publicação) | Poucas alterações, sem personalização |
| Arquivos de categorias e etiquetas | ISR com webhook de publicação | Ritmo ligado à publicação de conteúdo |
| Páginas de produto, catálogo estável | ISR com webhook de stock | Invalidação previsível |
| Páginas de produto, stock em tempo real | SSR com cache na edge | O stock muda em segundos |
| Carrinho e checkout | SSR | Dependem da sessão por definição |
| Painel com sessão iniciada | SSR | Estado por utilizador |
| Página inicial editorial | ISR com webhook de publicação | Ritmo ligado aos eventos de publicação |
Invalidação de cache ISR com webhooks do WordPress
O ISR parece gratuito até servir um URL canónico desatualizado depois de uma alteração de slug. O padrão que o evita:
Invalidação orientada por webhooks. O WordPress dispara um webhook na publicação, na alteração de slug ou na eliminação de um artigo. O framework de front-end recebe o webhook e dispara a regeneração das páginas afetadas. O custo é uma integração de webhook na origem WordPress, paga uma vez.
Revalidação temporal apenas como rede de segurança. Um intervalo de revalidação de 60 segundos cobre falhas na entrega de webhooks, mas não deve ser o gatilho principal. Uma página que revalida a cada 60 segundos também é reconstruída 60 vezes por hora; num site com 5000 páginas, isso é insustentável.
Etiquetas de cache, não URLs. Cada página em cache recebe etiquetas com o ID do artigo no WordPress, os IDs dos termos que referencia e etiquetas transversais (página inicial, sitemap). Quando chega um webhook, o front-end limpa a cache por etiqueta, não por URL. É a diferença entre “regenerar a página do produto” (frágil) e “regenerar tudo o que referencia o produto 8421” (correto).
Custo de ISR e SSR no Cloudflare Workers
O Astro e o Next.js compilam ambos para um runtime compatível com o Workers. O custo modo a modo:
- Estático na edge. O Cloudflare Pages serve HTML simples com quase nenhum CPU por pedido. O modo mais barato.
- ISR. O primeiro pedido após a invalidação paga o custo total de renderização; os pedidos em cache quase nada. O Workers trata dos dois casos.
- SSR. Cada pedido paga o custo total de renderização no Workers. Previsível por pedido, caro em escala.
A diferença de custo pesa com tráfego elevado. Com pouco tráfego, decide a correção, não o custo.
Exemplos de ISR e SSR em rotas reais do WordPress
Página inicial de marketing. Estática, reconstruída por webhook a cada publicação editorial. Cache de 24 horas na edge com possibilidade de limpeza manual. SSR como alternativa apenas se for acrescentado um banner específico por país.
Página de produto no WooCommerce. ISR com o ID do produto como chave. Webhook do WooCommerce em alterações de stock, de preço ou de conteúdo. Janela de cache: 1 hora como rede de segurança. SSR apenas se mostrar o stock em tempo real for um requisito de UX.
Histórico de encomendas do cliente. SSR. Por utilizador, dependente da sessão, sem cache na edge.
A mesma arquitetura, três modos de renderização diferentes, uma regra de decisão.
Guias relacionados sobre WordPress headless
Este artigo faz parte do pilar do serviço headless WordPress. Para a escolha ao nível do framework, consulte a matriz de decisão Next.js ou Astro.
A parte de implementação deste tema está a nosso cargo no âmbito da auditoria Core Web Vitals.
