NEXT.JS, ASTRO, OU WORDPRESS EM 2026

Next.js, Astro, ou WordPress é a pergunta que recebo mais frequentemente de founders e clientes de agências. A resposta quase nunca é a que eles esperam. A decisão não é framework versus framework. A decisão é intenção: o que você está realmente construindo, quem vai manter depois do launch, e qual é o modo de falha que você menos pode se dar ao luxo de ter. Uma vez que essas três coisas ficam claras, a escolha do framework geralmente se faz sozinha.

O que se segue é a visão do operador de doze anos entregando os três. Rodamos WordPress, Next.js, e Astro toda semana na Seahawk Media, frequentemente no mesmo cliente em diferentes estágios de ciclo de vida. Cada um é software genuinamente bom. Cada um é a resposta errada para situações específicas. Este guia é a árvore de decisão que eu realmente uso, não o passeio da página de marketing.

Next.js

Next.js é um framework React com uma camada de renderização no servidor, roteamento baseado em sistema de arquivos e um sistema de build que produz HTML estático, HTML renderizado no servidor, ou qualquer coisa no meio do caminho. O modelo App Router se estabilizou a partir da versão 15, React Server Components são o padrão, e o framework é a escolha dominante para projetos React greenfield. Vercel o desenvolve, Netlify e Cloudflare o executam, e o ecossistema é vasto.

Astro

Astro é um framework focado em conteúdo que não envia JavaScript por padrão e permite que você coloque componentes React, Vue, Svelte ou Solid apenas onde precisa de interatividade. Seu forte é em sites de conteúdo: páginas de marketing, blogs, documentação, sites institucionais. O modelo mental é "HTML por padrão, JS onde necessário", que inverte a suposição React de que tudo é JavaScript até comprovado o contrário.

WordPress (clássico e headless)

WordPress roda em PHP, vive em um banco de dados MySQL e tem o maior ecossistema de plugins da web. Em 2026 ele tem dois modos de operação: clássico (WordPress renderiza tanto backend quanto frontend) e headless (WordPress é a API e CMS, enquanto Next.js, Astro ou Nuxt lidam com a renderização). WordPress headless é o que faz a ponte entre o mundo do WordPress-com-editores e o mundo do Next.js-com-engenheiros.

Next.js vence em sites com formato de produto. Especificamente: o time é fluente em React, o produto tem interatividade com estado além de um site de marketing típico, o modelo de dados é customizado (não um blog genérico ou CMS), e o time de engenharia vai manter o codebase por anos.

Exemplos concretos do trabalho que entreguei: um dashboard SaaS com uma porta de entrada de marketing, um marketplace com login e conteúdo personalizado, um site de empresa de developer tools com demos profundamente customizadas, uma plataforma de diretório multi-tenant como HostList.io. Cada um desses beneficia de React Server Components, dos primitivos de busca de dados do Next.js, e da transição sem emendas entre páginas de marketing estáticas e superfícies de app autenticadas no mesmo framework.

Onde Next.js fica caro rápido é em sites densos em conteúdo com editores não-técnicos. A integração de CMS é sempre customizada, o workflow editorial é sempre reconstruído, e o time que o mantém tem que ser permanentemente staffado por engenheiros. Se seu time editorial são três redatores e você quer que eles publiquem sem envolvimento de engenharia, Next.js está lutando a batalha errada.

Astro vence para sites orientados a conteúdo com linguagem de design forte e capacidade de engenharia para entregar componentes limpos. Especificamente: um site de marketing, um hub de documentação, um site de brochura, um portfólio, um site de agência, um blog onde performance é parte da marca. O tipo de site onde a experiência do visitante é ler ou escanear conteúdo, não interagir com fluxos com estado.

Este site, gautamkhorana.com, é construído em Astro. O mesmo vale para o site de marketing de muitas agências orientadas a design e lançamentos de produtos indie em 2026. O argumento é simples: zero JavaScript padrão significa que as pontuações do Lighthouse chegam a 100 sem esforço, o modelo de conteúdo é markdown simples ou Sanity ou Supabase, e o pipeline de build produz HTML estático que sobrevive a tráfego infinito em qualquer CDN. Os sites que entreguei em Astro tiveram coletivamente zero regressões de performance desde o lançamento. Não poucos. Zero.

Onde Astro é a escolha errada: qualquer coisa com estado de usuário autenticado significativo, qualquer coisa onde a complexidade do frontend supera a complexidade do conteúdo, qualquer coisa onde o time precisa se mover em idiomas React em toda a base de código. Astro é excelente em ser leve; é a ferramenta errada para construir um produto pesado.

WordPress vence para sites orientados a conteúdo onde a experiência do editor importa mais que a performance de renderização, onde o ecossistema de plugins resolve um problema real, e onde o time não terá capacidade de engenharia contínua. O pilar /guides/wordpress/ cobre isso em detalhe completo; a versão curta: se você tem editores não-técnicos, alavancagem de plugins importa, e custo total de propriedade ao longo de três anos é a métrica decisória, WordPress permanece a resposta certa para a maioria dos sites orientados a conteúdo.

Especificamente: sites de brochura com atualizações editoriais regulares, sites de ecommerce onde WooCommerce resolve complexidade real de impostos regionais, sites de associação onde MemberPress ou Restrict Content Pro fornece o fluxo de trabalho pronto, sites imobiliários ou de quadros de empregos onde um plugin de nicho lidar noventa por cento do modelo, sites onde o cliente explicitamente não quer alocar um desenvolvedor para mudanças contínuas.

Headless WordPress é a arquitetura ponte: mantenha WordPress para a experiência do editor e ecossistema de plugins, mas renderize o frontend com Next.js ou Astro para performance e controle de design. Compensa em um conjunto estreito mas real de casos.

Compensa quando: o time editorial está comprometido com WordPress e não vai sair, mas o site de marketing é crítico em performance (tráfego alto, anúncios caros, pontuações de Lighthouse sensíveis à marca). Compensa quando a linguagem de design é incomum o suficiente para que a camada de tema WordPress não consiga entregar, mas o modelo de conteúdo é genuinamente em formato WordPress (posts, páginas, tipos de post customizados, campos ACF). Compensa quando a empresa tem maturidade editorial e maturidade de engenharia e pode alocar ambas.

Não compensa quando: o time não tem nem maturidade editorial nem capacidade de engenharia (você acaba pagando duas vezes), o projeto é genuinamente um site de brochura que é editado mensalmente, o orçamento é pequeno o suficiente para que manutenção de stack duplo seja inviável. O custo honesto de rodar headless WordPress em 2026 é aproximadamente 1.5x a 2x o custo de rodar WordPress clássico ao longo de doze meses. Certifique-se de que as vitórias de performance e design justificam isso.

Dentro do Next.js especificamente, a escolha da estratégia de renderização tem implicações de custo maiores do que a escolha do framework em si. As quatro opções:

Static Site Generation (SSG)

Todas as páginas são construídas no momento da build, servidas como HTML puro a partir do CDN. Mais barato, mais rápido, mais seguro. O padrão certo para sites de marketing e blogs. A limitação é que mudanças de conteúdo exigem uma rebuild completa e redeploy. Para sites com alguns milhares de páginas, isso funciona bem. Para sites com dezenas de milhares de páginas, os tempos de build se tornam o gargalo.

Incremental Static Regeneration (ISR)

As páginas são geradas estaticamente no momento da build, depois revalidadas sob demanda ou em um cronograma. O meio termo para sites de conteúdo em escala. O problema que a maioria dos times enfrenta: a cobrança de ISR no Vercel é por invocação, e com 91.000 páginas e revalidação frequente já vimos meses com eventos em múltiplos milhões. Temos uma regra explícita de "dois merges em produção por semana" no site Deluxe Astrology precisamente porque cada merge dispara aproximadamente seis milhões de eventos de escrita ISR. ISR é uma tecnologia excelente com uma curva de custo real em escala.

Server-Side Rendering (SSR)

Páginas renderizadas a cada requisição. A resposta certa para dashboards autenticados, conteúdo personalizado e qualquer coisa onde o conteúdo da página dependa do usuário que a requisita. O modelo de custo é por CPU por requisição, o que fica caro rapidamente em páginas públicas com alto tráfego. Evite SSR para páginas de marketing.

React Server Components (RSC)

O padrão do Next.js 15, frequentemente usado em combinação com os anteriores. RSC move o fetching de dados para o servidor e envia menos JavaScript para o cliente. O modelo mental requer algum ajuste, mas os ganhos de performance e DX são reais. A maioria do trabalho novo com Next.js em 2026 deve usar RSC por padrão.

Se você está indo headless em Next.js ou Astro, a decisão da camada CMS é a segunda mais consequente depois do framework. As cinco opções viáveis que avalio em cada projeto:

Sanity

Minha recomendação padrão para novos projetos headless. A abordagem schema-as-code oferece o modelo de conteúdo mais limpo do mercado, a experiência do editor é genuinamente boa para editores não-técnicos, e a linguagem de query GROQ é mais flexível que GraphQL para a maioria das formas de conteúdo. O preço escala razoavelmente. Trade-off: ecossistema de plugins menor que WordPress, atrito ocasional em workflows editoriais customizados.

WordPress Headless (via WPGraphQL ou REST)

A resposta certa quando a familiaridade do editor com WordPress é a restrição principal. WPGraphQL está maduro em 2026 e a stack Faust.js torna a integração com Next.js simples. Custo: você mantém WordPress E o frontend, que é o overhead inerente de fazer a ponte entre os dois mundos.

Supabase

Minha escolha quando o modelo de conteúdo é dados estruturados mais que prosa longa: diretórios, listagens, sites de SEO programático, qualquer coisa com forma de tabela. HostList.io roda em Supabase. Custo: Supabase é um banco de dados com affordances de camada de conteúdo, não um CMS no sentido editorial. Editores não gostam.

Contentful

Escolha enterprise com features fortes de workflow e suporte a locales. O preço escala rápido nos tiers mais altos. Certo quando o time tem governança formal de conteúdo e orçamento para acompanhar.

Payload, Strapi

Opções self-hosted quando residência de dados ou controle de custos é a preocupação principal. Ambas amadureceram significativamente em 2025. Ideais para times com capacidade de engenharia que querem ser donos da camada CMS.

Onde você faz deploy é a terceira decisão que se compõe ao longo do tempo. Os três hosts viáveis:

Vercel

Host Next.js de primeira parte, experiência de desenvolvedor mais suave, tier de preço mais alto. Bandwidth e invocações ISR são os alavancadores de custo que a maioria dos times não vê até a conta chegar. Realmente rodamos sites na Vercel porque as vitórias de DX compensam, mas a curva de custo é mais acentuada do que as pessoas esperam. Orçamento para pelo menos o dobro da sua estimativa inicial em qualquer escala onde ISR está em uso intenso.

Netlify

Excelente para Astro e Next.js renderizado estaticamente, um pouco menos polido para Next.js App Router com RSC completo. Preço é mais previsível que Vercel. O modelo de preço por minuto de build é o alavancador a observar. Este site roda na Netlify.

Cloudflare Pages and Workers

Melhor relação preço-performance em 2026, materialmente mais barato que os outros dois em escala, a rede subjacente é inigualável para entrega global. Trade-off: o modelo de deployment e integração Next.js é menos polido que Vercel. Vale a pena escolher para projetos sensíveis a custo com capacidade de engenharia para navegar as arestas mais ásperas.

Escolha o framework que corresponda ao time que vai mantê-lo. Parece óbvio. É a regra mais violada que vejo em decisões de framework aqui na Seahawk.

Um time de três engenheiros React não deve construir sobre WordPress. Um time de um engenheiro PHP mais três redatores não deve construir sobre Next.js. Um time de zero engenheiros e um designer freelancer não deve construir sobre nenhum desses: Webflow, Framer, ou WordPress hospedado é a resposta certa.

O custo de um framework e time desalinhados não é pago no primeiro dia. É pago pelos anos seguintes enquanto o time trabalha contra o framework em vez de com ele. Alinhe a tecnologia à realidade operacional.

Números reais de sites que enviei ou auditei em 2026, todos medidos no percentil 75 de dados de campo:

Astro renderizado estaticamente

LCP consistentemente abaixo de 1.0 segundo. JavaScript inicial abaixo de 30KB na maioria das páginas. Lighthouse 100 em todos os aspectos é o resultado padrão, não o alvo de otimização. O nível mais difícil de bater para sites de conteúdo.

Next.js renderizado estaticamente (App Router, RSC)

LCP de 1.0 a 1.5 segundos em sites otimizados. JavaScript inicial de 80 a 150KB dependendo de quantos client components são entregues. Lighthouse 90+ é alcançável mas exige trabalho de otimização deliberado.

ISR ou SSR Next.js

LCP de 1,5 a 2,5 segundos dependendo da taxa de acerto de cache e do tempo de resposta da origem. Performance cai drasticamente em cache misses frios. Tecnologia excelente para o caso de uso certo, mas requer monitoramento ativo.

WordPress em hospedagem gerenciada (Kinsta, WP Engine) mais Cloudflare

LCP de 1,8 a 3,0 segundos típico. Lighthouse 70 a 85 com esforço. Aceitável para a maioria dos sites de conteúdo, mas materialmente pior do que as opções estáticas. O teto de performance é real.

WordPress em hospedagem compartilhada

LCP de 3,5 segundos ou pior. Evite para qualquer site onde performance seja parte do escopo.

Os três podem rankear no mais alto nível. A conversa de SEO em 2026 não é mais sobre qual framework é "mais amigável para SEO". É sobre qualidade de implementação.

Renderização estática em Astro ou Next.js te dá o HTML indexável mais limpo e os Core Web Vitals mais rápidos, ambos sendo fatores de ranking. WordPress com Yoast ou Rank Math te dá a ferramenta de SEO no editor mais abrangente, o que ajuda materialmente editores não-técnicos a entregar meta limpa. WordPress headless te dá ambos, ao custo de manutenção double-stack.

Onde vejo desastres de SEO: sites Next.js heavy em JavaScript do cliente que renderizam conteúdo principal no navegador em vez do servidor. Google tecnicamente consegue indexar conteúdo renderizado em JavaScript, mas a latência, completude e consistência são todas piores do que conteúdo renderizado em HTML. Se SEO importa, renderize no servidor ou estaticamente. Sempre.

A maioria dos clientes faz a pergunta errada sobre migração. A certa não é "conseguimos migrar de WordPress para Next.js" mas "qual é o custo total de três anos de cada opção, incluindo o time necessário para mantê-la, e qual entrega as métricas que realmente nos importam".

Uma migração típica de WordPress para Next.js headless que fazemos na Seahawk é de 25.000 a 90.000 USD dependendo do escopo. Essa migração geralmente se paga em doze meses em tráfego onde os scores do Lighthouse influenciam custos de anúncios ou taxas de conversão. Não se paga em um site institucional que recebe dois mil visitantes mensais.

A migração que mais frequentemente faz sentido é de WordPress em shared hosting para WordPress em Kinsta, mais uma camada Cloudflare, mais uma dieta mais rigorosa de plugins. Mesma plataforma, realidade operacional diferente, performance e segurança materialmente melhores a um décimo do custo de uma re-plataformização. A resposta certa para a maioria dos clientes não é "reconstruir em Next.js" mas "corrigir a instalação de WordPress que você já tem".

Aqui está a árvore de decisão real que uso em toda conversa com novo cliente em 2026:

Se o time tem zero capacidade de engenharia e editorial é a única função: Webflow ou WordPress hospedado.

Se o time é liderado por editorial com suporte técnico leve, conteúdo abundante com necessidades do ecossistema de plugins: WordPress clássico em hospedagem gerenciada. Resposta padrão.

Se o time é liderado por editorial mas performance e design fazem parte do brief: WordPress headless com um frontend Astro ou Next.js.

Se o time é liderado por engenharia, o produto é rico em conteúdo, a linguagem de design é inusitada, e há pouco estado de usuário: Astro com Sanity ou Supabase.

Se o time é liderado por engenheiros, o produto tem estado de usuário autenticado e interatividade com estado: Next.js com Sanity ou Supabase, deployado em Vercel ou Cloudflare Pages dependendo da sensibilidade a custos.

Se o modelo de dados é genuinamente table-shaped em escala (diretórios, listagens, SEO programático): Next.js ou Astro com Supabase. HostList.io é o caso de estudo aqui.

Não existe um único framework "melhor" em 2026. Existe um melhor framework para cada combinação de time, forma de conteúdo e realidade operacional. Os times que entregam bem são aqueles que combinam essas três coisas com honestidade. Os times que enfrentam dificuldades são aqueles que escolheram o framework primeiro e tentaram fazer sua realidade se adequar a ele.

Três sinais honestos de que você está prestes a escolher o framework errado: você está escolhendo porque é o que seus amigos usam, você está escolhendo porque está na lista de tendências este trimestre, você está escolhendo porque o demo na página de marketing te fez sentir algo. Nenhuma dessas é uma boa razão. A razão certa é: isso combina com meu time, isso combina com meu conteúdo, isso combina com meu orçamento nos próximos três anos.

Se você quer uma segunda opinião sobre qual é a certa para o que você está construindo, fazemos consultas na Seahawk Media. A conversa é gratuita, a recomendação é honesta, e às vezes diremos que a resposta certa é manter seu site WordPress atual e corrigir a camada de hosting porque é isso que a matemática realmente diz.