LOG 04 · FRAMEWORK
Next.js e Exportação Estática
Next.js App Router compilado para um site totalmente estático — output: 'export' — sem processo de servidor, sem arranques a frio e sem nada para corrigir às 2 da manhã.
Publicado · Atualizado
Um build, não um servidor
Este site — e a maioria dos sites que entrego — compilam com `output: 'export'`: cada rota é gerada como HTML/CSS/JS estático em tempo de build, sem nada a correr no servidor depois. Isso exclui as server actions e a renderização sob demanda, mas um site de portefólio ou marketing raramente precisa deles, e em troca ganha-se algo melhor — não há processo de servidor que possa cair, ficar sobrecarregado ou precisar de uma correção de segurança.
As rotas de aparência dinâmica continuam a funcionar sob exportação estática através do `generateStaticParams` — cada caminho possível é enumerado e pré-renderizado em tempo de build em vez de calculado por pedido, que é exatamente como as entradas individuais deste diário são geradas.
Metadados como código, não um acrescento tardio
As APIs de metadados tipadas do Next.js — o export `Metadata`, `generateMetadata`, `sitemap.ts`, `robots.ts` — fazem com que a configuração de SEO viva nos mesmos ficheiros TypeScript que a própria página, verificada pelo compilador, em vez de um campo de CMS separado que silenciosamente se desalinha do que a página realmente diz.
App Router, TypeScript do princípio ao fim
Cada componente deste site é um componente React tipado sob o App Router — componentes de servidor por defeito, componentes de cliente apenas onde a interatividade (um canvas WebGL, um efeito guiado por GSAP, um pedaço de estado partilhado subscrito) realmente o exige. Essa distinção é deliberada: menos JavaScript enviado ao navegador para as partes da página que nunca precisaram de hidratar.
A armadilha do que só existe no cliente
A exportação estática torna muito fácil deixar passar uma falha específica: tudo o que um componente monta a partir de um efeito não aparece no HTML exportado. As secções da página inicial deste site são montadas por portais numa cena CSS3D assim que o palco 3D arranca, o que funciona perfeitamente num browser — e significava que o <h1> da página só existia depois da hidratação. Qualquer rastreador que lesse o ficheiro estático via uma página inicial sem qualquer cabeçalho.
A correção não é engenhosa, apenas deliberada: tudo o que tem de estar no HTML — cabeçalhos, texto, links, dados estruturados — é renderizado fora da árvore que só vive no cliente, e deixa-se à camada interativa a parte para que ela existe. Vale a pena abrir o resultado compilado e lê-lo em vez de confiar no servidor de desenvolvimento, porque não são o mesmo documento.