Programador Next.js

O que entregamos

Next.js 15 com App Router e React 19 Server Components como frontend. WordPress 6.7+ como back end editorial, a comunicar por REST ou GraphQL. Cloudflare Workers e Pages como runtime e cache na edge. TypeScript em toda a stack. Tailwind CSS como sistema de design. Anthropic Claude e Model Context Protocol quando as funcionalidades de IA realmente compensam.

Isto não é uma lista de tecnologias tirada de um anúncio de emprego, é a stack que mantemos na nossa própria produção. Cada elemento tem justificação: o App Router permite renderização por rota, os RSC cortam o JavaScript enviado ao cliente, os Workers eliminam os cold starts e mantêm os dados ao alcance da regulação europeia. Quando um elemento deixa de se justificar na prática, sai da stack, e documentamos isso trimestralmente no Tech Radar.

Quando o Next.js é a escolha certa

Páginas personalizadas, fluxos de sessão, experiências com testes A/B, checkout transacional, dashboards em tempo real e espaços de trabalho autenticados beneficiam todos do modelo streaming SSR + RSC. O modelo mental é: "renderizar perto dos dados, fazer streaming do que está pronto, hidratar o que é interativo". Para páginas que se enquadram, o Next.js entrega um UX que SSR clássico ou estático não alcançam.

Para páginas que não se enquadram, dizemo-lo. Sites de marketing com forte componente de conteúdo, blogues e documentação costumam ganhar com Astro em estático + ISR a custo mais baixo. A decisão de framework faz parte do scoping, não é um padrão. Se depois do discovery ficar claro que o seu site não precisa de Next.js, é isso que vai ouvir, juntamente com uma recomendação mais económica.

Arquitetura: WordPress como back end, Next.js como frontend

Numa arquitetura headless, o WordPress deixa de renderizar páginas e fica com aquilo em que é realmente bom: ser o sistema editorial. A equipa de conteúdo trabalha no painel que conhece, com os mesmos papéis, workflows e plugins editoriais. O Next.js obtém o conteúdo por REST ou WPGraphQL e renderiza-o segundo a estratégia adequada a cada rota: página inicial e landings como estático com revalidação, catálogo de produtos como ISR com invalidação por webhooks, checkout e área de cliente como SSR com sessão completa.

Três elementos decidem se esta arquitetura funciona na prática, e os três fazem parte da implementação. Pré-visualização editorial: o editor tem de ver o rascunho antes de publicar, por isso configuramos o draft mode ligado ao WordPress, em vez de explicar à equipa que "agora já não dá". Invalidação de cache: uma publicação no WordPress dispara um webhook que revalida exatamente as rotas afetadas pela alteração, em vez de limpar todo o cache. Gestão de media: as imagens passam pelo pipeline do Next.js com AVIF automático e tamanhos responsivos, independentemente do que o editor carregou.

Desempenho e Core Web Vitals

O desempenho em Next.js não vem do framework, vem das decisões de arquitetura que o framework torna possíveis. O streaming SSR envia o primeiro byte antes de o servidor terminar de renderizar tudo, o que baixa diretamente o TTFB e o LCP. Os Server Components mantêm a lógica de obtenção de dados no servidor, pelo que o cliente recebe menos JavaScript e o INP deixa de sofrer com a hidratação de tudo ao mesmo tempo. O cache na edge da Cloudflare responde ao utilizador a partir do ponto de rede mais próximo, em vez de um único servidor origin.

Cada projeto começa com um baseline: TTFB, LCP, INP e CLS medidos em utilizadores reais antes da mudança, não em laboratório. Depois da implementação, as mesmas métricas são recolhidas por RUM e comparadas numa janela de medição lado a lado. O resultado do projeto é a diferença nos dados de campo, não uma captura de ecrã do Lighthouse. O protocolo público de medição Astro vs Next.js em WooCommerce, com metodologia consultável, está na secção de referência no fundo da página.

WooCommerce headless em Next.js

Uma loja é a variante mais exigente de headless, porque junta conteúdo estático com transação ao vivo. Renderizamos fichas de produto e categorias como ISR: rápidas como estático, atualizadas por webhook quando o preço ou o stock mudam. Carrinho, checkout e conta de cliente correm como SSR com sessão, ligados à Store API do WooCommerce. Preços por cliente, escalões de desconto B2B e catálogos atrás de login, requisitos típicos de grossistas, deixam de obrigar a desistir do cache em toda a loja, porque a decisão de renderização é tomada ao nível da rota.

A isto soma-se uma camada sobre a qual as lojas perguntam cada vez mais: a preparação para agentes de compra com IA. HTML limpo, renderizado no servidor, com schema Product e Offer corretos, é a condição de entrada para que um agente sequer veja o catálogo. É a mesma arquitetura que serve páginas rápidas às pessoas, por isso não a paga duas vezes.

SEO, GEO e AEO em Next.js

A renderização no servidor é a base de visibilidade que o React do lado do cliente nunca garante: crawlers de IA como o GPTBot, o ClaudeBot ou o PerplexityBot não executam JavaScript, e o Googlebot executa-o com atraso e com orçamento limitado. O Next.js com SSR e RSC devolve o conteúdo completo logo na primeira resposta HTML, pelo que aquilo que o utilizador vê é também aquilo que o bot vê.

Sobre essa base construímos a camada técnica: metadata API por rota, canonical e hreflang via metadata.alternates, sitemap via generateSitemaps, dados estruturados em JSON-LD ajustados ao tipo de página (Product, Article, FAQPage, HowTo), Open Graph com imagens geradas por página. Para a visibilidade nos motores de pesquisa generativos acrescentamos elementos de GEO: secções de resposta direta, FAQ com dados estruturados, llms.txt e negociação de conteúdo para agentes. Cada projeto passa por uma checklist de SEO de 30 pontos antes da mudança de DNS.

Segurança e jurisdição da UE

O headless reduz a superfície de ataque de uma forma que se explica à administração numa frase: o WordPress desaparece da internet pública. O ecrã de login, o XML-RPC e os ficheiros de plugins deixam de estar ao alcance dos scanners, porque o frontend é servido pelo Next.js e o origin só está acessível a ele. A isto somam-se cabeçalhos de segurança configurados centralmente, validação dos dados de entrada no servidor e segredos guardados fora do repositório.

Para empresas abrangidas pelo RGPD, pela NIS2 ou pelo DORA conta também a geografia dos dados: runtime na Cloudflare com processamento na UE, contratos de subcontratação em inglês ou polaco, documentação dos fluxos de dados para o registo de atividades de tratamento. Um contrato B2B em jurisdição europeia, não os termos de uma plataforma fora dela.

A quem se destina

• Lojas WooCommerce com processo de compra personalizado ou preços por utilizador
• Dashboards SaaS e espaços de trabalho autenticados com WordPress como camada de conteúdo
• Marcas multi-região que precisam de ISR com invalidação por webhook
• Editoras editoriais com feeds de dados ao vivo, comentários ou superfícies de analítica em tempo real
• Grossistas B2B com catálogos atrás de login e tabelas de preços negociadas por cliente

Modelo de colaboração

Contratos senior B2B em jurisdição da UE. Quatro fases: discovery com auditoria de conteúdo e baseline de desempenho, scoping com decisões de renderização rota a rota, construção iterativa com demos semanais e janela de medição lado a lado, e por fim afinação e retainer com observability e revisões trimestrais da stack. Âmbito fixo ou time-and-materials. Tarifação individual, cronograma por etapa com pontos de decisão.