O debate ACF vs blocos Gutenberg tem dividido a comunidade WordPress há anos. Há quem defenda que o Gutenberg é o futuro e que o ACF é legacy. Outros mantêm-se fiéis ao ACF e consideram o Gutenberg imaturo para trabalho sério em produção. A verdade, como habitualmente, está algures no meio — e depende do contexto do projeto.
Neste artigo partilho a minha posição técnica, baseada em projetos reais dos últimos anos. Na grande maioria dos meus projetos, ainda uso ACF. Mas não por nostalgia — por razões concretas que explicarei abaixo.
O debate ACF vs Gutenberg, sem ideologia
Deixem-me enquadrar este debate em termos práticos. O ACF (Advanced Custom Fields) é um plugin que permite criar campos personalizados para CPTs, páginas e taxonomias, com uma UX cuidadosamente desenhada para editores. O Gutenberg é o editor nativo do WordPress, que utiliza um sistema baseado em blocos e inclui o FSE (Full Site Editing).
Não são exatamente a mesma coisa. O ACF destina-se principalmente à estruturação de conteúdo (campos repetíveis, relações, galerias, dados específicos). O Gutenberg destina-se principalmente à composição visual do layout. Sobrepõem-se na gestão de conteúdo dinâmico em páginas com layouts flexíveis.
Quando o ACF vence (e porquê ainda o uso na maioria dos projetos)
1. Conteúdo estruturado e repetível
Para CPTs com dados bem definidos (projetos, produtos, membros de equipa, eventos), o ACF é incomparavelmente superior. Os campos são explícitos, validados, e a UX para editores é clara. No Gutenberg, isto teria de ser implementado como blocos personalizados, o que representa trabalho desnecessário para dados estruturados.
2. Relações entre conteúdos
Os campos Relationship e Post Object no ACF permitem construir facilmente relações complexas entre tipos de conteúdo (um projeto pertence a um cliente, tem vários membros de equipa, está relacionado com outros projetos). No Gutenberg, esta lógica é muito mais difícil de modelar de forma limpa.
3. UX para clientes não técnicos
Este é o argumento decisivo. Um cliente que acede ao backoffice para alterar o preço de um serviço, o número de colaboradores ou a data de um evento quer um único campo claro. Não quer navegar por blocos — quer clicar num campo “Preço” e escrever o valor.
O Gutenberg, por mais que tenha melhorado, ainda oferece uma experiência confusa para utilizadores não técnicos em conteúdo estruturado. O ACF é, por comparação, brutalmente mais simples.
4. Performance e controlo
Com ACF, o developer escreve o HTML que quiser no template, com controlo total sobre a estrutura e a performance. Com Gutenberg, o HTML é gerado pelo sistema de blocos, e o controlo fino é mais difícil de alcançar.
5. Maturidade e ecossistema
O ACF existe há mais de uma década, tem um ecossistema maduro, documentação sólida e um modelo de negócio sustentável (atualmente pertencente à WP Engine). Os blocos Gutenberg continuam a ter breaking changes entre versões, documentação dispersa e o ecossistema de blocos de terceiros é inconsistente.
Quando o Gutenberg faz sentido
Não sou dogmático. Há cenários em que o Gutenberg é a escolha certa.
Páginas de conteúdo editorial com layouts variáveis
Artigos de blog de formato longo, landing pages experimentais, páginas de campanha, onde o editor precisa de compor visualmente uma sequência de secções diferentes em cada peça. Para isto, o editor Gutenberg com um conjunto bem curado de blocos personalizados é excelente.
Projetos pequenos com cliente autónomo
Se o cliente vai gerir o site sozinho, tem alguma literacia digital e precisa de flexibilidade para criar novas páginas sem recorrer a um developer, o Gutenberg com um tema preparado para FSE pode fazer sentido.
Blocos reutilizáveis em múltiplos contextos
Se a mesma unidade de conteúdo (testemunho, CTA, card de funcionalidade) precisa de aparecer em dezenas de locais diferentes no site, um bloco Gutenberg reutilizável é mais elegante do que repetir campos ACF em múltiplas páginas.
O cenário híbrido que uso na maioria dos projetos
Na prática, os meus projetos raramente são 100% ACF ou 100% Gutenberg. A arquitetura que utilizo é:
- CPTs com dados estruturados: ACF (projetos, produtos, equipa, eventos)
- Páginas institucionais fixas (homepage, sobre, contacto): ACF Flexible Content ou um template rígido com ACF
- Posts de blog: Gutenberg, com um conjunto limitado de blocos personalizados (pullquote, citação, imagem com legenda, CTA)
- Landing pages: Gutenberg com blocos personalizados específicos
Esta abordagem oferece ao cliente a UX adequada para cada tipo de conteúdo: campos claros para dados estruturados, flexibilidade visual para conteúdo editorial.
O que a Automattic não vos conta
A narrativa oficial é que o Gutenberg e o FSE são o futuro inevitável do WordPress. Isso é parcialmente verdade. Mas há realidades que não constam dessa narrativa:
- O Gutenberg tem breaking changes frequentes, o que aumenta o custo de manutenção a longo prazo
- O FSE (Full Site Editing) ainda tem limitações sérias para sites corporativos com requisitos complexos
- Muitos developers experientes continuam a usar ACF porque a produtividade real é superior
- A curva de aprendizagem para criar blocos Gutenberg personalizados é significativamente mais acentuada do que criar grupos de campos ACF
- A compatibilidade com temas mais antigos e as migrações são mais complexas com Gutenberg
E os ACF Blocks?
Uma solução intermédia que uso cada vez mais são os ACF Blocks. Permitem criar blocos Gutenberg usando a sintaxe e a UX do ACF. Obtém-se a flexibilidade de composição do Gutenberg com a simplicidade de implementação do ACF.
Não é perfeito — a performance pode ser ligeiramente inferior à dos blocos React nativos, e existem limitações em alguns casos de uso avançados. Mas para a maioria dos cenários em que preciso de um bloco personalizado, é a opção mais produtiva.
Conclusão: não é Gutenberg vs ACF, é o contexto do projeto
A pergunta certa não é «qual é o melhor». É «o que é que este projeto específico precisa, e quem vai gerir o conteúdo». A resposta varia de projeto para projeto.
Se está a ponderar reconstruir o seu site e não tem a certeza de qual abordagem escolher, vamos conversar. Posso ajudá-lo a mapear os requisitos e a propor a arquitetura mais adequada ao seu caso.
