Um cliente me ligou em 2021 — imobiliária, orçamento decente, tinha acabado de demitir a agência anterior. O briefing era simples: reconstruir seu portal de listagens. O dev anterior deles havia gasto oito meses estruturando uma aplicação Next.js customizada. Parecia brilhante nas demos. Não podia ser atualizado por uma única pessoa do time deles sem um pull request e um pipeline de deployment. O agente imobiliário gerenciando as listagens estava usando uma Planilha Google como workaround.
Reconstruí em WordPress com Advanced Custom Fields Pro em cerca de seis semanas. Eles têm gerenciado por conta própria desde então.Advanced Custom Fields Proin about six weeks. They've been managing it themselves ever since.
Essa história não é um argumento contra Next.js. É um argumento contra escolher uma ferramenta antes de ter entendido o problema. Fiz o inverso também — passei um WordPress multisite para um cliente quando eles precisavam de uma aplicação React de verdade, e a vi rangendo sob pressão dezoito meses depois.
Depois de construir 5.000+ sites na Seahawk Media, parei de me importar com qual framework "vence". Me importo com qual entrega, perfoma, e não volta para assombrar você à 23h de um domingo.Seahawk Media, I've stopped caring about which framework "wins." I care about which one ships, performs, and doesn't come back to haunt you at 11pm on a Sunday.
---
O Estado Honesto de Ambas as Tecnologias Agora
WordPress alimenta algo em torno de 43% da web inteira. Esse número é jogado por aí com tanta frequência que perdeu o significado, mas pense nele por um segundo. Quarenta e três porcento. Isso não é inércia legada — isso é efeito de rede, ecossistema de plugins, infraestrutura de hospedagem, e duas décadas de conhecimento institucional embutido em cada servidor compartilhado do planeta.
Next.js, enquanto isso, tornou-se o framework React dominante para aplicações em produção. Os dados de uso de 2023 da Vercel mostraram ele processando centenas de bilhões de requisições por mês. O App Router introduzido no Next.js 13 mudou como as pessoas pensam sobre componentes de servidor — e sim, também quebrou muitos tutoriais publicados antes de 2023, o que ainda está causando confusão em servidores Discord por toda parte.
Mas aqui está a coisa: essas duas tecnologias não são realmente competidoras da forma como os argumentos no Twitter as fazem parecer. WordPress é um CMS com uma camada de tema. Next.js é um framework React com integração CMS opcional. O diagrama de Venn do que elas são realmente boas em fazer tem muito pouca sobreposição uma vez que você fica específico sobre os requisitos.
---
Onde WordPress É Genuinamente Imbatível
Sites com Muito Conteúdo Gerenciados por Não-Desenvolvedores
Serei direto. Se seu cliente tem um time de marketing, um gerente de conteúdo, ou alguém que precisa publicar sem tocar em código — WordPress é quase sempre a resposta correta. O editor Gutenberg, goste ou não (tenho tido um relacionamento complicado com ele desde 2018), oferece aos usuários não-técnicos uma experiência de edição baseada em blocos que realmente funciona.anyonewho needs to publish without touching code — WordPress is almost always the correct answer. The Gutenberg editor, love it or loathe it (I've had a complicated relationship with it since 2018), gives non-technical users a block-based editing experience that actually works.
Nada no ecossistema React chega perto da experiência editorial do WordPress pronto para usar. Sanity.io tem um estúdio bonito, Contentful é sólido para conteúdo estruturado — mas nenhum dos dois tem o ecossistema de plugins ou a familiaridade com mecanismos de busca que WordPress tem. O contratado de marketing médio já usou WordPress antes. Eles não usaram um CMS headless.
Profundidade do Ecossistema de Plugins
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Estes não são apenas plugins — são plataformas inteiras com seus próprios ecossistemas. Quando a Seahawk realiza um projeto de e-commerce para um cliente com catálogo modesto (digamos, menos de 5.000 SKUs), WooCommerce combinado com uma boa infraestrutura de hospedagem em Kinsta ou WP Engine funciona bem. Estamos falando de tempos de carregamento inferiores a 2 segundos após cache, gerenciamento completo de estoque, recuperação de carrinho abandonado, integração com Stripe — tudo configurado em uma tarde.Kinstaor WP Engine handles it fine. We're talking sub-2-second load times after caching, full stock management, abandoned cart recovery, Stripe integration — all configured in an afternoon.
Replicar essa funcionalidade em um build customizado em Next.js com Shopify ou uma camada de comércio headless? Você está olhando para semanas de tempo de desenvolvimento e custos de manutenção contínua que a maioria dos clientes PMEs não conseguem justificar.
Realidades de Orçamento e Cronograma
Honestamente, a maioria dos projetos não tem orçamento para uma aplicação React bespoke. Um site WordPress bem construído com um tema premium como Kadence ou Blocksy, ACF para estruturas de dados customizadas e WP Rocket para performance pode ser entregue em duas a quatro semanas e mantido por quase qualquer pessoa. Isso não é uma limitação — é pragmatismo.
---
Onde Next.js Realmente Justifica Sua Complexidade
Interatividade e Lógica de Aplicação
Lá em 2022, a Seahawk teve um projeto fintech — um dashboard para uma empresa de análise de crédito. Feeds de dados em tempo real, filtragem complexa, controle de acesso baseado em funções, integrações de API com três provedores de dados diferentes. Olhei para WordPress headless por cerca de duas horas antes de admitir que era a ferramenta errada completamente. Construímos em Next.js com NextAuth.js para autenticação e React Query para busca de dados. Ainda está rodando, ainda está rápido, e a base de código é algo com o qual o time interno do cliente consegue realmente contribuir.
WordPress consegue tecnicamente fazer coisas como aplicações. Mas todas as vezes que tentei empurrá-lo para território genuinamente dinâmico — pense em formulários multi-etapa com lógica condicional alimentando APIs externas, dashboards em tempo real, qualquer coisa que exija estado cliente granular — terminei lutando contra a arquitetura em vez de trabalhar com ela.
Performance em Escala Sem Dependência de Plugin
Next.js com Static Site Generation (SSG) ou Incremental Static Regeneration (ISR) consegue produzir páginas que são quase vergonhosamente rápidas. Sem plugins de cache necessários. Sem dials de configuração do WP Rocket. As páginas são apenas... HTML estático com hidratação onde você precisa.
A documentação do Vercel sobre ISR explica bem o mecanismo, mas a implicação prática é esta: um site Next.js para uma publicação de notícias com 50.000 artigos pode revalidar páginas individuais em um cronograma sem reconstruir o site inteiro. Isso é genuinamente poderoso e algo que WordPress consegue apenas aproximar através de fragment caching.explains the mechanism well, but the practical implication is this: a Next.js site for a news publication with 50,000 articles can revalidate individual pages on a schedule without rebuilding the entire site. That's genuinely powerful and something WordPress can only approximate through fragment caching.
Experiência do Desenvolvedor e Composição da Equipe
Se você é uma agência com uma equipe de desenvolvimento React-native, o desenvolvimento WordPress tem uma curva de aprendizado real que frequentemente é subestimada. PHP, a hierarquia de templates do WordPress, a arquitetura de hooks, o coelho de buraco do functions.php — não é difícil, mas é diferente. Já contratei desenvolvedores JS talentosos que olharam para uma base de código de tema WordPress e se sentiram perdidos nas primeiras duas semanas.functions.phprabbit hole — it's not hard, but itisdifferent. I've hired talented JS developers who looked at a WordPress theme codebase and felt lost for the first two weeks.
Inversamente, se sua equipe vive em TypeScript e React, um projeto Next.js com um headless CMS como Contentful ou Sanity é um ambiente mais confortável. O código é testável, os tipos são explícitos, e o workflow de deployment via Vercel ou Netlify é genuinamente bom.
---
O Meio-termo do WordPress Headless (E Seus Problemas Reais)
Muitas agências desembarcaram no "WordPress headless" como um compromisso — WordPress como backend CMS, Next.js como frontend. O pitch soa perfeito. A equipe editorial mantém sua interface familiar; desenvolvedores ganham uma stack de frontend moderna.
Na prática? É genuinamente útil em situações específicas e uma dor de cabeça genuína em outras.
Os bons casos:goodcases:
- Grandes plataformas de publicação onde o fluxo editorial é inegociável, mas o desempenho do frontend também é um requisito crítico
- Organizações já investidas em infraestrutura WordPress que querem modernizar o frontend sem retreinar os times de conteúdo
- Sites com relacionamentos de conteúdo complexos que se beneficiam da modelagem de dados do ACF, mas precisam de React para a camada de apresentação
Os problemas reais:actual problems:
- WPGraphQL é excelente, mas debugar o desempenho de queries GraphQL em um contexto WordPress é doloroso. Você está adicionando uma camada de complexidade que pode te prejudicar.is excellent, but debugging GraphQL query performance in a WordPress context is painful. You're adding a layer of complexity that can bite you.
- Funcionalidade de preview para editores — ver um post em rascunho no frontend Next.js — é uma fonte constante de bugs. Perdi dias com isso em múltiplos projetos.
- Hospedar dois sistemas separados significa dois pontos de falha separados, dois conjuntos de custos de infraestrutura e dois pipelines de deploy para manter.
- Recursos em tempo real ainda são desconfortáveis. Você não consegue WebSockets de uma REST API do WordPress sem trabalho adicional significativo.
WordPress headless não é um meio termo mágico. É uma terceira opção com seus próprios trade-offs, e só faz sentido quando os requisitos específicos genuinamente justificam a complexidade.
---
Como eu realmente tomo a decisão (meu checklist real)
Depois de projetos suficientes, reduzi isso a um conjunto rápido de perguntas que faço antes da segunda ligação do cliente.
Prefira WordPress quando:
- O cliente ou sua equipe precisa gerenciar conteúdo de forma independente
- O projeto é principalmente páginas de conteúdo e marketing (mesmo as complexas)
- O orçamento é inferior a £20K e o cronograma é inferior a oito semanas
- E-commerce é necessário, mas o catálogo tem menos de ~10.000 produtos
- O cliente já está no WordPress e a migração não serve a nenhum propósito real
Prefira Next.js quando:
- O projeto tem requisitos significativos de interatividade ou semelhantes aos de uma aplicação
- O time é composto principalmente por desenvolvedores JS/React
- Você precisa de controle granular sobre a estratégia de renderização (SSG, SSR, ISR por rota)
- O sistema de design do frontend é customizado e orientado a componentes React
- Há uma razão genuína para integrar um headless CMS moderno como Sanity ou Contentful
- A longo prazo, o cliente quer ser dono e estender o frontend com seus próprios desenvolvedores JS in-house
E alguns sinais de alerta que devem te fazer pausar independentemente de qual direção você está inclinado:red flagsthat should make you pause regardless of which direction you're leaning:
- Um cliente exigindo Next.js porque leu que é "mais moderno" — isso não é um requisito
- Escolher WordPress porque "é mais fácil" quando o projeto genuinamente precisa de lógica de aplicação
- Qualquer um usando a frase "à prova do futuro" como justificativa sem articular o que o futuro realmente exige
---
Performance: Vamos Usar Números Reais
É aqui que a conversa costuma dar errado. As pessoas jogam scores do Lighthouse por aí como se fossem a história inteira.
Um site WordPress bem otimizado — hosting decente, WP Rocket ou FlyingPress, imagens WebP, um tema construído corretamente — rotineiramente marca 90+ no PageSpeed Insights. A Seahawk entregou sites WordPress com 95+ consistentemente. Não é magia; é só configuração apropriada.
Uma app Next.js mal configurada com data fetching no lado do cliente em todos os lugares, imagens não otimizadas e nenhuma estratégia de caching apropriada vai marcar nos 50s. Eu já vi.
A lacuna entre um "site WordPress rápido" e um "site Next.js rápido" é muito mais estreita do que os evangelistas de framework sugerem. A própria pesquisa de Core Web Vitals do Google mostra que a tecnologia de origem importa muito menos do que a qualidade da implementação. Os gargalos na maioria dos sites com baixo desempenho são imagens, recursos que bloqueiam a renderização e tempos de resposta do servidor — nenhum dos quais são problemas inerentes do WordPress ou Next.js.Google's own Core Web Vitals researchshows that origin technology matters far less than implementation quality. The bottlenecks in most poorly performing sites are images, render-blocking resources, and server response times — none of which are inherently WordPress or Next.js problems.
O que Next.js oferece, genuinamente, é mais controle sobre performance. Você pode tomar decisões precisas por rota sobre como os dados são buscados e quando as páginas são renderizadas. Mas controle só ajuda você se você o exercer corretamente.more controlover performance. You can make precise decisions per-route about how data is fetched and when pages are rendered. But control only helps you if you exercise it correctly.
---
SEO: WordPress Tem a Vantagem do Ecossistema, Não a Vantagem Inerente
Aqui está um conceito errado que tenho que corrigir regularmente: WordPress não é inerentemente melhor para SEO. Apps Next.js com server-side rendering apropriado são totalmente rastreáveis pelo Google. O componente <Head>, geração de sitemap via next-sitemap, dados estruturados via JSON-LD — tudo é alcançável.<Head>component, sitemap generation vianext-sitemap, structured data via JSON-LD — it's all achievable.
O que WordPress tem é Yoast SEO ou Rank Math, que dão aos usuários não-técnicos uma interface visual para gerenciar títulos meta, descrições, URLs canônicas e schema markup. Isso é uma vantagem de fluxo editorial, não uma vantagem técnica.
Se o site será gerenciado por desenvolvedores que entendem meta tags e structured data, SEO em Next.js não é mais difícil de implementar. Se o site precisa de um consultor de SEO ou gerente de marketing para ajustar títulos de página sem abrir um ticket — use WordPress.
---
FAQ
WordPress não é antigo e está sendo substituído por frameworks modernos?
WordPress tem estado "sendo substituído" desde pelo menos 2014, quando comecei a ouvir esse argumento seriamente. Isso não aconteceu e não espero que aconteça. A questão não é se WordPress é moderno — é se ele resolve o problema que você tem. Para uma enorme porcentagem de sites, resolve. A Automattic continua investindo pesadamente em Gutenberg e na experiência de Full Site Editing. Está evoluindo, apenas não de formas que deixam as redes sociais empolgadas.
Você pode usar WordPress como backend com um frontend React?
Sim, isso é WordPress headless, e cobri os trade-offs acima. A versão curta: use WPGraphQL ou a REST API para servir conteúdo, construa seu frontend em Next.js. Funciona. Também adiciona complexidade. Faça isso apenas se os requisitos realmente exigirem, não porque soa arquitetonicamente interessante.
Quanto tempo leva para construir um site em Next.js comparado com WordPress?
Genuinamente depende do escopo, mas para um site de marketing comparável, Next.js típicamente leva 40–60% mais tempo para construir para a entrega inicial. Você está escrevendo componentes do zero, configurando um design system, integrando um CMS, configurando deployment. WordPress com um tema premium e ACF te leva muito mais longe, mais rápido. Onde Next.js compensa o investimento de tempo é na escalabilidade de longo prazo e ergonomia do desenvolvedor — desde que a composição do time justifique.
E quanto a Astro, Remix ou outros frameworks?
Vale a pena conhecer. Astro em particular é interessante para sites estáticos com muito conteúdo e venho experimentando com ele em projetos menores na Seahawk. Remix tem um modelo de carregamento de dados atraente. Mas nenhum dos dois tem a maturidade de ecossistema ou familiaridade do cliente que WordPress tem, nem a adoção empresarial de Next.js. Para a maioria das decisões de agência agora, ainda é uma escolha entre WordPress ou Next.js, com todo o resto como uma consideração de nicho.
Devo sempre recomendar a escolha técnica "melhor" aos meus clientes?
Não. A melhor escolha técnica que o time de um cliente não consegue manter é pior que a segunda melhor escolha que eles realmente conseguem usar. Aprendi isso da forma difícil mais de uma vez. Entregue a coisa que funciona para os humanos envolvidos, não apenas para o diagrama de arquitetura.
---
A habilidade real não é conhecer WordPress ou conhecer Next.js. É saber quando usar cada um — e ser honesto o suficiente consigo mesmo e com seus clientes para fazer essa escolha baseada na realidade deles, não nas suas preferências.
Aquele cliente do setor imobiliário de 2021? Ainda está no WordPress. Ainda gerencia seus próprios anúncios. Sem ligações de domingo à noite da minha parte.