Um cliente me ligou em 2021 -- imobiliária, orçamento decente, tinha acabado de desligar a agência anterior. O briefing era simples: reconstruir o portal de anúncios deles. O dev que saía tinha passado oito meses scaffolding uma aplicação Next.js sob medida. Parecia brilhante em demos. Não conseguia ser atualizada por uma única pessoa do time deles sem um pull request e um pipeline de deployment. O corretor imobiliário gerenciando os anúncios estava usando uma Google Sheet como workaround.
Conclusão-chave: WordPress vence quando editores precisam de autonomia e conteúdo muda diariamente; Next.js vence quando o site é um produto com engenharia por trás. O time decide, não o framework.WordPress wins when editors need autonomy and content changes daily; Next.js wins when the site is a product with engineering behind it. The team decides, not the framework.
Reconstruí isso em WordPress com Advanced Custom Fields Pro em aproximadamente seis semanas. Eles têm gerenciado por conta própria desde então.WordPress with Advanced Custom Fields Pro in 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. Eu já fiz o reverso também -- entreguei a um cliente um WordPress multisite quando precisava de uma aplicação React-driven apropriada, e assisti ela reclamar sob pressão dezoito meses depois.
Depois de construir mais de 12.000 sites na Seahawk Media, parei de me importar com qual framework "vence". Me importo com qual é entregue, performático e não volta para assombrar você às 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 na volta de 43% da web inteira. Esse número é repetido tão frequentemente que perdeu o significado, mas senta com ele por um segundo. Quarenta e três por cento. Isso não é inércia legada -- é efeito de rede, ecossistema de plugins, infraestrutura de hosting, e duas décadas de conhecimento institucional baked em cada servidor compartilhado do planeta.
Next.js, enquanto isso, virou o framework React dominante para aplicações de 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 server components -- e sim, também quebrou muito tutorial publicado antes de 2023, o que ainda está causando confusão em Discord servers em todo lugar.Vercel's 2023 usage data showed it processing hundreds of billions of requests a month. The App Router introduced in Next.js 13 changed how people think about server components -- and yes, it also broke a lot of tutorials published before 2023, which is still causing confusion in Discord servers everywhere.
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
Vou ser direto. Se seu cliente tem um time de marketing, um content manager, ou alguém que precisa publicar sem mexer em código -- WordPress é quase sempre a resposta correta. O editor Gutenberg, ame-o ou odeie-o (tive um relacionamento complicado com ele desde 2018), dá aos usuários não-técnicos uma experiência de edição baseada em blocos que realmente funciona.anyone who 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 fora da caixa. Sanity.io tem um studio lindo, Contentful é sólido para conteúdo estruturado -- mas nenhum tem o ecossistema de plugins ou a familiaridade com mecanismos de busca que WordPress tem. O hire médio de marketing usou WordPress antes. Não usou um headless CMS.Sanity.io has a beautiful studio, Contentful is solid for structured content -- but neither has the plugin ecosystem or the search-engine familiarity that WordPress has. Your average marketing hire has used WordPress before. They haven't used a headless CMS.
Profundidade do Ecossistema de Plugins
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Esses não são só plugins -- são plataformas inteiras com seus próprios ecossistemas. Quando Seahawk faz um projeto de e-commerce para um cliente com um catálogo modesto (digamos, sob 5.000 SKUs), WooCommerce paired com um setup de hosting decente em Kinsta ou WP Engine lida com isso bem. Estamos falando de tempos de carregamento sub-2-segundo após caching, gerenciamento completo de estoque, abandoned cart recovery, integração Stripe -- tudo configurado numa tarde.Kinsta or 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 sob medida. 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 -- isso é pragmatismo.
---
Onde Next.js Realmente Justifica Sua Complexidade
Interatividade e Lógica de Aplicação
Em 2022, 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 papel, 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 totalmente a ferramenta errada. Construímos em Next.js com NextAuth.js para autenticação e React Query para busca de dados. Ainda está rodando, ainda é rápido, e a base de código é algo que o time interno do cliente pode realmente contribuir.
WordPress pode tecnicamente fazer coisas tipo aplicação. Mas toda vez 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 requeira estado client-side refinado -- terminei lutando contra a arquitetura ao invés 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 agendamento sem reconstruir o site inteiro. É genuinamente poderoso e algo que WordPress só consegue 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 um time de desenvolvimento React-native, desenvolvimento WordPress tem uma curva de aprendizado real que frequentemente é subestimada. PHP, a hierarquia de templates do WordPress, arquitetura de hooks, o buraco de coelho 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.php rabbit hole -- it's not hard, but it is different. 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 chegaram em "WordPress headless" como um compromisso -- WordPress como backend de CMS, Next.js como frontend. O pitch soa perfeito. Time 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:good cases:
- 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 a performance de query GraphQL em um contexto WordPress é doloroso. Você está adicionando uma camada de complexidade que pode morder você. 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. Já perdi dias nisso 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 algumas bandeiras vermelhas que devem fazer você pausar independentemente de qual direção você está inclinado:red flags that 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 propriamente construído -- regularmente marca 90+ no PageSpeed Insights. Seahawk entregou sites WordPress em 95+ consistentemente. Não é mágica; é 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 diferença 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 de implementação. Os gargalos na maioria dos sites com performance ruim são imagens, recursos render-blocking, e tempos de resposta do servidor -- nenhum dos quais são problemas inerentemente WordPress ou Next.js.Google's own Core Web Vitals research shows 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 o desempenho. 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 exercê-lo corretamente.more control over 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 proper server-side rendering 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 via next-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 dados estruturados, SEO em Next.js não é mais difícil de implementar. Se o site precisa que um consultor de SEO ou gerente de marketing ajuste 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 vem sendo "substituído" desde pelo menos 2014, quando comecei a ouvir esse argumento com seriedade. Nunca 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 porcentagem enorme de websites, resolve. A Automattic continua investindo pesadamente em Gutenberg e na experiência Full Site Editing. Está evoluindo, apenas não de formas que deixam feeds do Twitter animados.
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?
Depende genuinamente do escopo, mas para um site de marketing comparável, Next.js tipicamente leva 40-60% mais tempo para construir na entrega inicial. Você está escrevendo componentes do zero, configurando um design system, integrando um CMS, configurando deployment. WordPress com um tema premium e ACF avança muito mais, e rápido. Onde Next.js compensa o investimento de tempo é em escalabilidade a 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 recorrer a cada um -- e ser honesto o suficiente com você mesmo e seus clientes para fazer essa escolha baseado 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.