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.
Critérios para escolher WooCommerce clássico ou headless
| 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 manter o WooCommerce clássico?
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 compensa o WooCommerce headless?
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.
Como funciona a finalização da compra no WooCommerce headless?
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.
Etapas de uma migração para WooCommerce headless
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.
Deve otimizar primeiro o WooCommerce clássico?
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
