WooCommerce clássico vs. headless
A versão curta: mantenha o WooCommerce clássico quando um servidor PHP com bom cache consegue servir uma loja única, e avance para headless quando a velocidade em dispositivos móveis limita a receita, o catálogo é grande, ou um catálogo tem de alimentar vários front-ends. O headless não é automaticamente melhor. É melhor em condições específicas, e uma reconstrução fora dessas condições só acrescenta custo.
WooCommerce headless significa que o WordPress e o WooCommerce permanecem como backend, expostos através da Store API ou do WPGraphQL, enquanto o tema PHP é substituído por um front-end desacoplado em Next.js ou Astro que renderiza HTML em cache na edge.
A matriz de decisão
| Critério | WooCommerce clássico | WooCommerce headless |
|---|---|---|
| Tamanho do catálogo | Até alguns milhares de SKU | Catálogos grandes, navegação facetada |
| Core Web Vitals em dispositivos móveis | Bom com cache de página completa | Melhor, zero PHP por pedido na edge |
| Custo de construção e operação | Mais baixo, uma stack | Mais alto, duas stacks a manter |
| Experiência editorial | WordPress nativo | WordPress nativo, pré-visualização num domínio à parte |
| Vários front-ends | Uma loja | Um catálogo, muitos front-ends |
| Complexidade da finalização da compra | Nativa, a mais simples | Com autoridade no servidor, mais ligações |
| Tempo até ao lançamento | Mais rápido | Cerca de seis semanas para uma loja de média dimensão |
Quando o clássico ainda vence
Para uma loja única abaixo de alguns milhares de produtos, um WooCommerce clássico em alojamento de qualidade na UE, com cache de página completa, base de dados limpa e ativos otimizados, atinge um LCP móvel abaixo de dois segundos sem reconstrução. Uma loja portuguesa com algumas centenas de artigos e um tema limpo não precisa de uma segunda base de código para ser rápida. Se a sua loja está lenta hoje, a causa é quase sempre a infraestrutura e a dívida técnica, não o modelo de renderização. Resolva isso primeiro. O guia de otimização de desempenho do WooCommerce mostra exatamente como, e fica muito mais barato do que partir para headless.
Uma loja à escala de cartão de visita, uma loja com catálogo pequeno, ou uma equipa sem capacidade de front-end para manter uma segunda stack deve manter-se clássica. O custo de manutenção de duas stacks é real e recorrente.
Quando o headless vence
O headless paga o seu custo em três situações. Primeiro, quando os Core Web Vitals em dispositivos móveis moldam diretamente a receita e um monólito afinado em cache ainda não consegue manter o LCP abaixo de dois segundos sob carga. Segundo, quando o catálogo é grande e a navegação facetada torna a renderização em PHP o estrangulamento. Terceiro, quando um catálogo tem de alimentar várias superfícies, como uma loja web, uma aplicação nativa e um quiosque em loja física, a partir de uma única fonte de verdade. Um retalhista português que enfrenta picos de tráfego em campanhas como a Black Friday no telemóvel é precisamente o caso em que a renderização na edge compensa.
Nesses casos, o front-end renderiza HTML pré-construído na edge sem PHP por pedido, o que elimina os piores casos de latência de cauda, enquanto o WooCommerce continua dono do catálogo, das encomendas, do imposto e do stock.
A parte que todos subestimam: a finalização da compra
A finalização da compra é onde as migrações de WooCommerce headless têm êxito ou falham. O pagamento, o imposto e a criação da encomenda têm de permanecer com autoridade no servidor, dentro do WooCommerce. O front-end orquestra os passos, mas o backend é dono do dinheiro. Reimplementar a lógica de finalização da compra no front-end é como as lojas acabam com encomendas mal cotadas e o IVA partido. Mantemos a finalização da compra no servidor e deixamos o front-end conduzir a experiência à volta dela.
Como decorre a migração
O calendário é dominado por duas coisas: manter a finalização da compra correta e transferir o SEO sem perdas. Congelamos primeiro o contrato de dados, construímos o front-end face à Store API, mantemos a finalização da compra no WooCommerce, preservamos cada URL e cada bloco de dados estruturados, e depois fazemos a transição por trás de uma CDN, com a loja antiga ainda acessível até a nova estar comprovada. Um diff de rastreio antes do lançamento é o que evita as quedas de posição que dão má fama ao headless.
Não sabe de que lado está?
Decompomos o compromisso face ao seu catálogo real, ao tráfego e à equipa antes de recomendar o que quer que seja. Muitas vezes a resposta honesta é otimizar primeiro a loja clássica e voltar ao headless mais tarde.
A pesar o clássico contra o headless?
Peça uma avaliação de migração. Avaliamos a sua loja face à matriz de decisão, modelamos o custo nas duas direções e dizemos-lhe com clareza qual se ajusta, mesmo quando a resposta é manter o clássico.
Pedir uma avaliação →Recursos relacionados
- Otimização de desempenho do WooCommerce - experimente isto antes de uma reconstrução
- Programador de WooCommerce - como trabalhamos nas lojas
- Shopify Plus vs. WooCommerce headless - se também está a pesar o Shopify
- Headless WordPress: Next.js vs. Astro - a escolha da framework de front-end
- Estudo de caso de migração: PageSpeed 18 para 99 - uma reconstrução real para uma stack moderna, tempo de carregamento 12 s para 0,3 s, com métricas completas
