Arquitetura headless separa o back-end onde o conteúdo é gerenciado do front-end onde ele é exibido, e a ponte entre os dois é uma API. Num CMS tradicional como o WordPress padrão, essas duas camadas vivem no mesmo lugar. Num setup headless, o CMS não tem opinião nenhuma sobre como o site vai parecer: ele só entrega os dados.
Comparação direta entre um CMS monolítico e uma arquitetura headless nos pontos que decidem a compra:
| Critério | CMS monolítico | Headless |
|---|---|---|
| Camadas | Back e front acoplados | Back e front separados via API |
| Front-end | Tema PHP fixo | React, Vue, ou outro à escolha |
| Canais de entrega | 1 (o site) | Vários (site, app, totem) |
| Tempo de setup inicial | 1 a 2 semanas | 4 a 8 semanas |
| Custo de manutenção mensal | Menor | Maior |
O Google usa o LCP como fator de ranqueamento desde 2021, e sites com LCP acima de 2,5 segundos perdem posição em consultas competitivas. Front-ends desacoplados bem construídos entregam LCP abaixo de 1,5 segundo com regularidade, o que em e-commerce se traduz em taxa de conversão mensurável, não em métrica de vaidade.
O que a palavra headless quer dizer na prática
Headless é literal: sem cabeça. A cabeça é o front-end, a camada que o visitante enxerga. Você decapita o CMS quando remove dele a responsabilidade de renderizar páginas.
No WordPress clássico, quando alguém acessa o site, o servidor pega o conteúdo do banco de dados, aplica o tema PHP e devolve o HTML pronto. Tudo acontece na mesma instalação. Num modelo headless, o CMS guarda o conteúdo e expõe esse conteúdo por uma API, geralmente REST ou GraphQL. Um segundo sistema, construído em React ou outra biblioteca de interface, consome essa API e monta a tela do jeito que os desenvolvedores quiserem.
A vantagem que aparece primeiro é a liberdade no front-end. Você não fica preso ao ecossistema de temas e ao PHP. A vantagem que aparece depois, e costuma ser a que sustenta a decisão, é a reutilização do mesmo conteúdo em vários lugares. O mesmo texto de um produto pode alimentar o site, um aplicativo iOS e um painel interno sem ninguém copiar e colar nada.
A diferença que importa entre monolítico e desacoplado
Um CMS monolítico junta banco de dados, lógica de administração e renderização visual num pacote só. WordPress, Joomla e Drupal nasceram assim. É um modelo que funciona há vinte anos porque resolve o caso mais comum com o menor esforço.
O problema começa quando o negócio quer entregar conteúdo em canais que o tema PHP não alcança. Um app mobile nativo não consegue consumir um tema WordPress. Uma smart TV também não. Nesses casos o monolítico vira um gargalo, e a saída é expor o conteúdo por API, que é exatamente o que o headless faz por construção.
Vale uma distinção que muita gente confunde. Existe o WordPress headless, onde você mantém o painel do WordPress mas troca o tema por um front-end externo que consome a API REST. E existem os CMSs headless de nascença, que nunca tiveram tema nenhum. Os dois caminhos chegam num resultado parecido, mas o WordPress headless carrega o peso de um back-end que não foi desenhado para isso.
Quando o desacoplamento vira dívida técnica
Separar as camadas cobra um preço. Você passa a ter dois sistemas para manter, dois deploys, duas superfícies de erro. Um front-end React precisa de build, precisa de hospedagem própria, precisa de alguém que saiba mexer nele quando quebra.
Em projeto pequeno, com um site institucional de dez páginas e um blog, isso é peso morto. O cliente que só quer trocar o telefone no rodapé não deveria precisar de um pipeline de deploy para isso. Já vi empresa gastar em três meses de infraestrutura headless o que gastaria em dois anos de um WordPress bem configurado, e o site continuava sendo o único canal.
Os três CMSs headless que valem a conversa
O mercado tem dezenas de opções, mas na prática a decisão quase sempre cai entre Sanity, Contentful e Strapi. Cada um resolve um perfil diferente de projeto.
| CMS | Modelo | Melhor para |
|---|---|---|
| Sanity | SaaS, esquema em código | Times de dev que querem controle total |
| Contentful | SaaS enterprise | Empresas grandes, multi-idioma, budget alto |
| Strapi | Open source, self-hosted | Quem quer dado na própria infraestrutura |
Sanity
O Sanity define o esquema de conteúdo em JavaScript, versionado no mesmo repositório do projeto. Para quem programa, isso é ótimo. O editor de conteúdo, o Sanity Studio, é uma aplicação React que você pode customizar campo por campo. A tier gratuita cobre até três usuários e 10 mil documentos, o que segura a maioria dos projetos de porte médio sem custo de licença.
A parte que costuma incomodar é a curva. Um redator sem contato com o time técnico se perde no começo, porque o Studio reflete decisões de estrutura que foram tomadas no código.
Contentful
Contentful é a escolha de empresa grande. Interface polida, suporte a dezenas de idiomas, controles de permissão granulares. O preço acompanha: os planos pagos partem de algumas centenas de dólares por mês e escalam rápido conforme entram mais spaces e mais chamadas de API.
Se o projeto não tem operação de conteúdo internacional nem múltiplos times editoriais, Contentful é caro demais para o que entrega. Vejo muita gente contratando Contentful por reputação e usando dez por cento do que paga.
Strapi
Strapi é open source e você hospeda onde quiser, o que muda o jogo para empresas com exigência de soberania de dados ou compliance mais rígido. Roda em Node.js, gera a API automaticamente a partir dos content types que você define no painel, e não cobra licença.
O custo se desloca para a infraestrutura e para quem vai administrar o servidor. Não existe almoço grátis: o que você economiza em licença gasta em DevOps.
Qual eu escolheria
Para a maioria dos projetos que passam pelo estúdio, o Sanity ganha. A combinação de esquema em código, tier gratuita generosa e Studio customizável cobre o caso comum sem prender o cliente num contrato caro. Escolho Contentful quando existe operação editorial em três ou mais idiomas com times separados, e escolho Strapi quando o dado não pode sair da infraestrutura do cliente por regra de compliance. Fora desses dois recortes, Sanity resolve.
Quando arquitetura headless faz sentido de verdade
Headless justifica o investimento quando existe mais de um canal de entrega, ou a promessa concreta de um segundo canal no horizonte próximo. Site mais aplicativo. Site mais totem de autoatendimento. Site mais integração com um ERP que também consome o conteúdo.
O segundo caso forte é performance sob tráfego alto. Um front-end estático gerado a partir de uma API, servido por CDN, aguenta picos que derrubariam um WordPress compartilhado. Um cliente de e-commerce nosso saiu de um LCP de 4,1 segundos num WordPress com trinta plugins para 1,2 segundo num front-end desacoplado servido por CDN, e a taxa de rejeição em mobile caiu de 58 para 41 por cento em oito semanas.
O terceiro caso é time de desenvolvimento maduro. Headless assume que existe alguém para manter o front-end. Sem esse pré-requisito, a arquitetura vira uma armadilha bonita.
Quando headless é overkill
Site institucional de página única, blog corporativo, landing page de campanha. Nesses casos o WordPress monolítico bem otimizado entrega o mesmo resultado de negócio por uma fração do custo e do prazo.
A pergunta honesta antes de migrar é uma só: existe um segundo canal de entrega real, ou a decisão está sendo movida por moda técnica. Se a resposta é moda, o headless vai adicionar complexidade sem devolver retorno. Já recusei projetos de migração headless porque o cliente tinha um site de doze páginas e nenhum plano de app, e o correto ali era otimizar o que já existia.
O ponto que raramente aparece nas apresentações comerciais: headless não deixa o site mais rápido por mágica. Um front-end React mal construído pode ser mais lento que um WordPress enxuto. A velocidade vem da engenharia, não da arquitetura em si.
Perguntas frequentes sobre arquitetura headless
Não. A velocidade vem de um front-end bem construído servido por CDN, não da separação de camadas. Um React mal feito pode ser mais lento que um WordPress enxuto.
Pode. Você mantém o painel do WordPress e troca o tema por um front-end externo que consome a API REST. Funciona, mas carrega o peso de um back-end que não foi desenhado para isso.
Um setup monolítico fica pronto em uma a duas semanas. Um headless leva de quatro a oito semanas, porque são dois sistemas para configurar, com deploy e hospedagem próprios para o front-end.
Sanity para a maioria dos projetos, pela tier gratuita e pelo Studio customizável. Contentful quando há operação editorial em três ou mais idiomas. Strapi quando o dado precisa ficar na infraestrutura própria por compliance.
Em site institucional de poucas páginas ou blog sem plano de segundo canal. Se não existe app, totem ou integração no horizonte, otimizar o WordPress atual entrega o mesmo resultado por muito menos.
