Headless CMS ou CMS tradicional: a comparação honesta
Um CMS tradicional guarda o conteúdo e apresenta as páginas. Um CMS headless guarda o conteúdo e entrega-o por API, cabendo-lhe a si decidir como é apresentado. É essa a diferença inteira, e todos os compromissos decorrem dela.
Este guia cobre o que ganha com headless, o que custa, e quando essa troca compensa.
O que muda de facto#
A diferença é arquitetural, não de funcionalidades. Ambos editam conteúdo; distinguem-se em quem constrói a apresentação.
| Aspeto | Tradicional | Headless |
|---|---|---|
| Apresentação | O CMS apresenta as páginas | Você constrói o front-end |
| Pré-visualização | Integrada e fiel | Constrói-a você, ou é aproximada |
| Liberdade de desenho | Dentro do sistema de modelos | Total |
| Vários canais | Difícil — o site é a saída | É o centro do desenho |
| Velocidade de arranque | Rápida — os temas existem | Mais lenta — constrói tudo |
| Competência exigida | Média | Desenvolvimento front-end obrigatório |
| Manutenção | Um sistema | Dois sistemas, dois processos de publicação |
O que headless dá realmente#
Os benefícios são reais, mas aplicam-se a situações específicas em vez de em geral.
- Vários canais a partir de uma fonte: site, aplicação, quiosque, newsletter — mesmo conteúdo, apresentações diferentes.
- Liberdade total de desenho e desempenho: sem herança de tema, sem CSS por usar.
- Geração estática: construir páginas antecipadamente e servi-las como ficheiros, o que é muito rápido e muito seguro.
- Substituir o front-end sem migrar: o conteúdo fica onde está.
- Modelo de conteúdo mais limpo: campos em vez de páginas com marcação embutida.
- Superfície de ataque menor: o painel de gestão não está no mesmo endereço público do site.
Note que a maioria destes benefícios só conta se tiver vários canais ou uma limitação de desempenho ou desenho que um tema não resolva.
O que custa#
Estes custos são sistematicamente subestimados nas comparações, e explicam porque projetos headless encalham mais.
| Rubrica | O que significa |
|---|---|
| Dois sistemas | Duas bases de código, dois processos, duas fontes de erro |
| Pré-visualização | Os editores esperam-na; tem de a construir |
| Tudo é à medida | Formulários, pesquisa, paginação, redirecionamentos — tudo seu |
| Necessidade contínua de programador | Não há tema para instalar quando algo muda |
| Conforto dos editores | Campos sem contexto são mais abstratos que editar uma página |
| Componentes de SEO | Mapa do site, canónicos, hreflang — sua responsabilidade |
| Custo inicial mais alto | Nitidamente mais caro de arrancar que um site com tema |
«Tudo é à medida» é a rubrica que mais surpreende. Funcionalidade que um CMS tradicional oferece de graça torna-se, em headless, uma série de pequenas tarefas de construção.
Quem deve escolher headless#
Uma regra de decisão curta que evita a maioria das escolhas erradas.
- Publica para mais do que um canal? Se sim, headless é provavelmente acertado.
- Tem equipa ou agência de front-end permanente? Sem isso, a necessidade contínua é um problema.
- Um tema consegue fazer o seu desenho? Se consegue, está a comprar liberdade que não usa.
- Tem uma exigência de desempenho que cache num CMS tradicional não cumpre? Normalmente não tem.
- Prevê substituir o front-end nos próximos anos? Aí a separação vale.
- Os seus editores estão confortáveis com campos estruturados sem página visual? Teste, não adivinhe.
- Se hesitar em mais de duas destas, escolha tradicional — é a opção de recurso por bons motivos.
Perguntas frequentes
Headless é melhor para SEO?
Não inerentemente, e pode ser pior se construir sem cuidado. Páginas geradas estaticamente são excelentes para SEO; páginas apresentadas só no navegador não são. Além disso, tem de construir mapa do site, canónicos, hreflang e redirecionamentos, que um CMS tradicional já traz. A arquitetura não decide — a execução decide.
Posso passar de tradicional para headless?
Sim, e é das migrações mais favoráveis porque o conteúdo continua estruturado. Alguns CMS tradicionais, incluindo o WordPress, podem servir como fonte headless através da sua API. Isso dá-lhe um meio-termo: edição familiar para a redação, front-end próprio para a apresentação.
Headless é mais caro?
Para arrancar, quase sempre, porque constrói o que um tema já traz. Ao longo de vários anos depende: se tem vários canais ou substitui o front-end com regularidade, pode sair mais barato. Para um site que vai durar cinco anos, tradicional costuma ser mais barato no total.
Os editores gostam de headless?
Depende inteiramente de quão bem construiu o modelo de conteúdo e a pré-visualização. Campos sem contexto são mais abstratos do que editar uma página que se parece com a página. Com boa pré-visualização e grupos de campos lógicos, funciona bem. Sem isso, é a fonte mais comum de insatisfação.
headless cmscms tradicionalheadless ou tradicionalcms apijamstackgeração estática
