Headless WordPress: quando faz sentido e quando é engenharia a mais

Há uns meses, um cliente pediu-nos “um site headless com WordPress e Next.js”. Quando perguntámos porquê headless, a resposta foi: “porque é mais moderno e escala melhor”. Explicámos que o projeto dele, um site empresarial informativo com 50 páginas e um blog, não precisava de headless, e que a “escalabilidade” que ganhava era insignificante. Já a complexidade que acrescentava era enorme.

No fim, fizemos um WordPress tradicional com Elementor. O projeto foi entregue em 6 semanas, não em 14. Custou metade. O cliente edita o conteúdo sozinho. Não nos liga para mudar uma vírgula.

O headless WordPress é uma ferramenta poderosa para casos específicos. Mas tornou-se uma palavra da moda que vende projetos desnecessariamente complexos. Saber quando sim e quando não poupa-te dinheiro. E dores de cabeça.

O que é “headless”

O WordPress tradicional é “monolítico”: o backend (onde geres o conteúdo) e o frontend (o que os utilizadores veem) estão acoplados. Usas temas PHP que geram o HTML diretamente.

O headless separa-os:

• O WordPress é só o CMS. Gere o conteúdo.
• O frontend é outra aplicação (React, Vue, Next.js). Pede o conteúdo por API.
• O frontend gera o HTML. O WordPress não o vê.

A vantagem teórica: flexibilidade total no frontend. Desempenho otimizado. O mesmo conteúdo para o site, a app móvel e os ecrãs digitais.

O custo real: 2 sistemas para manter. Implementações mais complexas. Quem edita conteúdo sofre. Uma dependência técnica enorme.

Quando é que o headless compensa?

Depois de anos a ver projetos headless bem-sucedidos e falhados, estes são os casos em que realmente brilha:

Experiência multicanal complexa

Precisas do mesmo conteúdo no site, numa app móvel nativa, numa aplicação de desktop e sabe-se lá onde mais. O WordPress funciona como fonte única de verdade e distribui o conteúdo por API a todos os frontends.

Exemplo: uma editora que publica no site, numa app iOS, numa app Android, numa newsletter e em sindicação para parceiros. Aqui o headless justifica o custo. O conteúdo é mesmo reutilizado.

Frontend altamente interativo

Aplicações em que a experiência do utilizador se parece mais com uma app do que com um site tradicional: transições complexas, estado da aplicação persistente, interações em tempo real.

Exemplo: um configurador de produto em 3D com estado complexo, em que o utilizador passa 10 minutos a interagir sem recarregar a página.

Desempenho extremo

Quando cada milissegundo conta e precisas de otimizações agressivas: geração estática, cache no edge, pré-carregamento de rotas. Um frontend moderno (Next.js, Astro) consegue fazer isto melhor do que um WordPress PHP tradicional.

Exemplo: uma loja online de grande volume, onde a velocidade de carregamento tem impacto direto na conversão e cada décima de segundo conta.

Equipa técnica especializada

Tens programadores frontend com experiência em React ou Vue que querem aproveitar esse conhecimento. Pô-los a aprender PHP e temas WordPress custaria mais do que manter um frontend separado.

Quando o headless é engenharia a mais

Pelo contrário, estes são os casos em que vemos o headless a ser vendido de forma inadequada:

“Quero que o site seja mais rápido”

Um WordPress bem otimizado (cache, bom alojamento, imagens leves) carrega em menos de 1 segundo. O problema quase nunca é o PHP. É conteúdo pesado ou má configuração. Antes de pensares em headless, faz uma auditoria ao teu site lento. Provavelmente a culpa não é da arquitetura.

“Quero usar tecnologia moderna”

O React não é melhor do que o PHP. É diferente. Para um site informativo, PHP a gerar HTML estático funciona. É testado, simples, e qualquer programador WordPress o mantém.

“Quero que a minha equipa de marketing possa editar”

A ironia: o headless costuma tornar a edição de conteúdo mais difícil. Os construtores visuais de páginas do WordPress (Elementor, WPBakery) não funcionam em headless. O conteúdo é editado em campos estruturados e é o frontend que o apresenta.

Se a tua equipa de marketing quer “arrastar e largar” elementos nas páginas, o headless impede-o.

Sites pequenos e médios

Se tens menos de 500 páginas, menos de 10 000 visitas por dia e conteúdo sobretudo estático, o headless é usar um canhão para matar uma mosca.

Os custos escondidos do headless (que ninguém te conta)

Quem vende headless realça os benefícios e minimiza os custos. Sejamos honestos sobre eles:

Custo de desenvolvimento. Na nossa experiência, o headless custa 2 ou 3 vezes mais do que um WordPress tradicional. 2 sistemas para integrar. Mais complexidade. Mais pontos de falha.

Custo de manutenção. Atualizações de segurança: 2 sistemas. Alterações no frontend: precisas de um programador. O marketing não consegue mexer no design a partir do WordPress.

Custo de alojamento. Precisas de infraestrutura para o frontend (Node.js) e também para o backend WordPress. Mais complexo. Mais caro.

Custo de dependência técnica. Qualquer alteração, por mais pequena que seja, precisa de um programador que perceba toda a stack. Não podes contratar um freelancer de WordPress qualquer.

Custo de tempo. O headless demora mais. A desenvolver, a depurar, a lançar.

Alternativas híbridas

Nem tudo é preto ou branco. Há arquiteturas intermédias:

WordPress com frontend estático. Usas o WordPress como CMS e geras um site estático (com plugins como o Simply Static). Tens a facilidade de edição do WordPress com a velocidade de um site estático. Não é headless puro, mas apanha muitos dos benefícios sem a complexidade.

Next.js com WordPress parcial. Usas Next.js só onde precisas (por exemplo, numa aplicação interativa). O resto fica em WordPress tradicional. O melhor dos dois mundos.

Headless com construtor visual de páginas. Alguns frameworks pensados para WordPress headless, como o Faust.js, tentam recuperar parte da experiência visual (apresentação de blocos, pré-visualizações). Funcionam, mas acrescentam ainda mais complexidade.

Perguntas frequentes

O headless é mais seguro?

Em parte. Separar backend e frontend reduz a superfície de ataque. Mas acrescenta complexidade e novas vulnerabilidades. Não é mais seguro por si só. Depende de como o implementas.

Posso migrar facilmente de um WordPress tradicional para headless?

Não. Estás a reconstruir o frontend de raiz. O conteúdo migra. O tema, os construtores de páginas e a personalização visual, não.

O headless melhora o SEO?

Se for mal feito, piora. O Google executa JavaScript, mas um frontend mal construído pode ficar invisível. O Next.js ajuda com SSR, mas acrescenta complexidade.

Devo usar GraphQL ou a API REST?

O GraphQL é mais flexível, ideal para dados complexos. O REST é mais simples e chega para casos simples. Depende da complexidade das tuas consultas.

Conclusão

O headless WordPress é uma ferramenta legítima e poderosa para casos específicos. Mas foi vendido em excesso como solução universal. A maioria dos sites empresariais funciona melhor com WordPress tradicional.

A pergunta certa não é “devo usar headless?”, mas sim “que problema estou a resolver, e o headless é a forma mais eficiente de o resolver?”

Se estás a pensar em headless, podemos avaliá-lo juntos. Às vezes faz sentido. Às vezes não. Às vezes uma solução híbrida é melhor. O importante é decidir com informação, não com palavras da moda.