WordPress headless para WooCommerce: quando compensa e o que evitar
A pergunta “o WordPress headless é adequado para WooCommerce” raramente é sobre tecnologia. É sobre se a loja continua a funcionar durante a migração, se as extensões existentes sobrevivem e se a nova arquitetura se paga dentro do ciclo orçamental. A resposta honesta: depende da loja.
Este artigo torna a decisão concreta. Complementa a nossa página de serviço de WordPress headless e o nosso texto sobre a economia do headless, onde está descrito o modelo de custos.
Para que lojas serve o WooCommerce headless
- Boa opção para lojas onde as Core Web Vitals em mobile limitam a conversão.
- Boa opção para lojas com catálogos estáveis que ficam bem em cache no edge.
- Má opção para lojas pequenas onde o custo de orquestração supera a poupança.
- Má opção para lojas com extensões pesadas do WooCommerce que pressupõem um front-end renderizado em PHP.
- Runtime de edge: o Cloudflare Workers serve tanto Astro como Next.js, com uma origem WordPress por trás.
O que significa, na prática, WooCommerce headless
O WordPress com WooCommerce mantém o fluxo editorial, a gestão de encomendas, o inventário e o processamento de pagamentos. O front-end headless (Astro ou Next.js) apresenta o catálogo público, as páginas de produto e a interface do carrinho e do checkout. Os dois comunicam através da Store API do WooCommerce, da REST API ou de GraphQL.
Três peças da arquitetura são decisivas:
A origem. Continua a ser WordPress. Continua a ser WooCommerce. O mesmo painel, os mesmos plugins, os mesmos fluxos de pagamento. Os editores não mudam de ferramentas.
O front-end. Astro ou Next.js a correr em Cloudflare Workers. Serve HTML pré-gerado para o catálogo e as páginas de produto e recorre a SSR para o carrinho e o checkout. Lê da origem WordPress.
A fronteira. REST ou GraphQL entre os dois. Cookies e cabeçalhos preservados através da fronteira para que a sessão mantenha a continuidade. É a peça que sustenta tudo, e a primeira a partir quando quem entrega é um programador júnior.
Quando é que o WooCommerce headless compensa
Cenários concretos em que o balanço é positivo:
- Uma loja de moda com 200 produtos, 70 por cento de tráfego mobile e um LCP mobile abaixo de 2 segundos diretamente ligado à conversão.
- Um catálogo B2B com 5000 SKU estáveis, em que a maioria das páginas fica horas em cache no edge.
- Uma loja WooCommerce que serve também de fonte de catálogo para uma aplicação mobile ou um agente de compras com IA (Universal Commerce Protocol).
- Um site que já serve o seu próprio bundle JS com muita interatividade, em que WordPress editorial mais Next.js não custa muito mais do que a configuração atual.
Nos quatro casos, o ganho é uma combinação de Core Web Vitals renderizadas no edge (efeito na receita) e de um custo previsível de Cloudflare Workers (efeito de poupança).
Quando é que o WooCommerce headless não compensa
Cenários concretos em que não compensa:
- Lojas de um só produto ou com menos de 20 SKU e pouco tráfego. O custo da migração supera largamente a poupança.
- Lojas com mais de 10 extensões ativas do WooCommerce que mexem no front-end. Cada uma precisa de auditoria, muitas vezes de reimplementação ou de um build híbrido.
- Inventário muito volátil (leilões ao vivo, vendas relâmpago, reservas em tempo real). O custo de invalidação da cache sobe mais depressa do que a poupança no front-end.
- Preços fortemente personalizados por cliente. A cache no edge perde eficácia e a arquitetura perde grande parte da vantagem.
A versão polémica: o headless não é a opção por defeito. Por defeito, mantém-se o monólito até o estrangulamento passar para o front-end. Quando o estrangulamento são as Core Web Vitals em mobile, a troca começa a compensar.
O que auditar antes de avançar para WooCommerce headless
A auditoria que um engenheiro sénior faz antes de qualquer compromisso de migração:
- Liste todas as extensões ativas do WooCommerce. Marque cada uma como “suporta headless”, “precisa de reimplementação” ou “bloqueia headless”.
- Registe as Core Web Vitals em mobile das 50 principais páginas de produto. Se o LCP e o INP já estiverem saudáveis, a poupança do headless é menor.
- Analise o perfil de tráfego: volume de visitas, proporção de visitantes recorrentes, proporção mobile, distribuição geográfica. Muito mobile e geografia diversa favorecem headless em Cloudflare Workers.
- Mapeie o histórico de redirecionamentos. Os sites WooCommerce acumulam redirecionamentos de produtos renomeados e de reestruturações de categorias. A migração tem de os preservar.
- Identifique preços por cliente e conteúdo dependente da sessão. Quanto mais houver, menor a vantagem do headless.
O resultado é um sim ou um não. Já desaconselhámos migrações para headless tantas vezes quanto as recomendámos.
O que inclui um build de WooCommerce headless
Quando a auditoria é favorável, o build de uma equipa experiente fica assim:
- WordPress com WooCommerce num pequeno alojamento gerido, como origem.
- Front-end em Astro ou Next.js (segundo a matriz de decisão Next.js vs Astro).
- Cloudflare Workers + Pages para entrega no edge.
- Redis na origem WordPress para object cache e armazenamento de sessões.
- WooCommerce Store API ativa, com limitação de pedidos no Worker.
- Os sete padrões de SEO para WordPress headless, todos preservados.
As decisões seguem esta ordem. O modelo de TCO do texto sobre a economia do headless fecha o ciclo.
Artigos relacionados sobre WordPress headless
Este artigo de cauda longa está ancorado na nossa página de serviço de WordPress headless e em três textos de apoio. Para os riscos da migração, a lista de sete pontos do artigo sobre padrões de SEO é a referência. Para enquadrar a decisão, a matriz Next.js vs Astro e o texto sobre a economia do headless fazem o trabalho pesado.
Para comparar plataformas, veja Shopify Plus vs WooCommerce headless.
