React & Next.js — aplicações web de alto desempenho
Usamos React 18 e Next.js 15 (App Router) em todos os projetos de frontend: desde sites de apresentação até SaaS complexos com dezenas de milhares de utilizadores. O código é TypeScript estrito, os testes são automatizados e a implementação faz-se através de um pipeline.
Porquê Next.js nos nossos projetos
O Next.js 15 com App Router oferece um modelo híbrido único: as páginas estáticas (SSG) são servidas a partir do CDN, as páginas dinâmicas correm como Server Components que não enviam JavaScript desnecessário para o browser, e as páginas com dados em tempo real usam Client Components isolados.
As imagens são otimizadas automaticamente pelo componente `<Image>` (WebP/AVIF, srcSet responsivo, carregamento diferido), os tipos de letra ficam embutidos no CSS crítico com `next/font` e os scripts de terceiros carregam com estratégias de prioridade. Em conjunto, estas otimizações visam reduzir o tempo de carregamento da página.
- Server Components para as páginas de marketing — zero JS no cliente, rastreio direto
- Streaming SSR com Suspense para dashboards com dados em direto
- Incremental Static Regeneration (ISR) para conteúdo semidinâmico
- Route Groups e Parallel Routes para layouts complexos sem re-render
TypeScript estrito — sem bugs silenciosos
Todos os nossos projetos usam TypeScript com `strict: true`, `noImplicitAny`, `exactOptionalPropertyTypes` e `noUncheckedIndexedAccess`. Estas definições bloqueiam em tempo de compilação categorias inteiras de bugs de runtime: acesso a undefined, tipos incompletos nas respostas de API, comparações erradas. Um projeto típico chega ao CI com 0 erros de TypeScript, antes sequer de qualquer teste.
Para a gestão de estado usamos Zustand (leve, sem boilerplate) ou React Context para o estado local. A obtenção de dados é gerida com TanStack Query (cache automática, invalidação inteligente, stale-while-revalidate). Formulários com React Hook Form e validação por esquema Zod — validação síncrona e assíncrona sem código duplicado.
- ESLint com regras próprias para padrões proibidos (any, console.log, strings mágicas)
- Prettier com configuração uniforme — nenhum PR é rejeitado por formatação
- Zod para validar em runtime os dados vindos de APIs externas
- Aliases de caminho (`@/components/...`) — importações claras sem `../../..`
Testes automatizados e CI/CD
Testes unitários com Vitest (rápido, compatível com a API do Jest), testes de componentes com React Testing Library e E2E com Playwright em 3 browsers (Chromium, Firefox, WebKit). O pipeline do GitHub Actions corre todos os testes em cada PR; o merge fica bloqueado se algum falhar. Cobertura mínima de 80% sobre a lógica de negócio.
- Lighthouse CI — uma pontuação inferior a 90 bloqueia a implementação em staging
- Analisador de bundle automático — alerta se o bundle crescer mais de 5% face ao main
- Storybook para os componentes de interface — documentação visual viva
Vantagens e limitações
Vantagens
- Lighthouse CI como portão: uma pontuação inferior a 90 bloqueia a implementação em staging.
- SSR e SSG nativos — HTML completo para o Google e para os motores de IA.
- O TypeScript estrito apanha os bugs na compilação, não em produção.
- Ecossistema maduro: Vercel, milhares de pacotes, uma comunidade enorme.
Limitações
- A curva de aprendizagem do App Router e dos Server Components é acentuada.
- Mudanças frequentes entre versões principais — exige manutenção.
- Para um site estático simples, o Next.js pode ser excessivo face a HTML puro.
- Builds grandes aumentam o tempo de compilação e o custo de CI.
Veredicto breve
Escolhe React e Next.js para sites e aplicações web que tenham de ser rápidos, indexáveis e escaláveis. Para uma única landing page estática sem interatividade, uma solução mais simples é suficiente.
Tabela de especificações
| Capacidade | Limite / limiar | Utilização típica | |
|---|---|---|---|
| Renderização | SSR, SSG, ISR, CSR | Os Server Components limitam as APIs do browser | Marketing estático + dashboard dinâmico |
| Desempenho | Portão Lighthouse CI: pontuação inferior a 90 bloqueia a implementação | O JS de hidratação cresce com a interatividade | Sites com muito tráfego, SEO crítico |
| Escalabilidade | Dezenas de milhares de utilizadores, CDN na edge | Requer alojamento Node ou serverless | SaaS, portais, comércio eletrónico |
| Custo típico | Open-source, alojamento a partir de ~0 € | Funções serverless faturadas conforme o uso | De projetos pequenos até à escala empresarial |
Next.js vs alternativas
| Critério | Next.js | Nuxt / Astro / Vite |
|---|---|---|
| SSR + SSG num único framework | Sim, de forma nativa | Parcial (Nuxt sim, Vite não) |
| Ecossistema React | Completo | Vue (Nuxt) ou multiframework (Astro) |
| Ótimo para site puramente estático | Bom | O Astro é mais leve |
Perguntas frequentes
Porquê Next.js e não React simples (Vite)?
O React com Vite só renderiza no cliente, por isso o HTML inicial chega vazio — fraco para SEO e GEO. O Next.js acrescenta SSR e SSG, entregando HTML completo que o Google e os motores de IA leem.
O Next.js é bom para SEO?
Sim. SSR/SSG entregam HTML indexável, os metadados e o JSON-LD são gerados no servidor e as Core Web Vitals são consideradas desde a construção — todos eles sinais que os motores de pesquisa avaliam.
Posso migrar um site existente para Next.js?
Sim, de forma incremental: as páginas mudam uma a uma, mantendo os URL e os redirecionamentos 301 para preservar, na medida do possível, as posições existentes.
De que alojamento precisa o Next.js?
As páginas estáticas funcionam em qualquer CDN. As funções dinâmicas (SSR, rotas de API) precisam de Node.js ou de um runtime serverless como o Vercel, o Netlify ou um contentor Docker.