Arquitetura Web: Escolha a Estratégia de Renderização Antecipadamente
Dois padrões que Claude adota e que geralmente estão errados: renderizar tudo no navegador e construir uma aplicação multi-página manualmente com HTML/JS vanilla. Ambos devem ser uma escolha deliberada e antecipada; para a maioria dos sites reais, a melhor resposta é HTML renderizado no servidor e um framework. Levante essas questões mesmo quando o usuário não perguntou, da mesma forma que você levantaria a necessidade de um WAF antes da produção.
Prefira HTML renderizado no servidor, não no cliente
Para qualquer coisa onde conteúdo, SEO ou primeira pintura importa, o conteúdo deve estar na resposta HTML inicial, não pintado posteriormente por JavaScript do lado do cliente. Renderização client-side (uma casca vazia que busca e renderiza no navegador) significa uma tela em branco até o bundle carregar e executar, um LCP lento e conteúdo que muitos rastreadores e recuperadores de LLM nunca veem porque não executam JavaScript de forma confiável. Em vez disso, renderize no servidor:
- SSG (geração estática): renderize no momento da build, sirva estático de um CDN. Mais rápido, mais barato, mais cacheável. O padrão para conteúdo que não muda por requisição, marketing, documentação, blog, páginas de listagem e categoria que podem ser reconstruídas.
- SSR (renderização no servidor): renderize por requisição no servidor. Para conteúdo dinâmico, personalizado ou com acesso autenticado que não pode ser gerado no momento da build.
- CSR / ilhas: renderize no navegador apenas para as partes genuinamente interativas, ou para superfícies do tipo aplicativo atrás de um login onde SEO é irrelevante (um dashboard). Com uma abordagem de ilhas (Astro) a página é enviada como HTML estático e apenas os componentes interativos hidratam.
Escolha por página, você pode misturar: uma página de marketing estática (SSG), uma página de conta personalizada (SSR) e um widget interativo (uma ilha) no mesmo site.
Várias páginas significa usar um framework
Se o projeto tem múltiplas páginas, um layout compartilhado, roteamento ou busca de dados real, construir manualmente em JS vanilla é uma armadilha de manutenção e desempenho, e é o padrão do Claude a menos que indicado o contrário. Use um framework (Next.js, Astro, SvelteKit, Nuxt, Remix). Eles fornecem roteamento, SSR e SSG, code-splitting, carregamento de dados e otimização de imagem prontos para uso, e crucialmente eles oferecem navegação client-side no estilo SPA sobre o HTML inicial renderizado no servidor, proporcionando a experiência suave de aplicativo multi-página sem enviar um SPA puro client-side que quebra a primeira pintura e o SEO.
Observe a distinção: um SPA puro renderizado no cliente é o que se deve evitar para sites de conteúdo. Um framework que faz SSR/SSG com navegação client-side oferece a experiência de aplicativo e mantém o conteúdo no HTML.
Mas combine a ferramenta com o projeto
Não exagere na correção. Uma única página estática, uma landing page ou um widget incorporável pequeno não precisa de Next.js; HTML e CSS puros são a escolha certa e mais leve, e usar um framework pesado aí é seu próprio erro. O problema ocorre nos dois sentidos; o mais comum é subdimensionar (tudo vanilla, renderizado no navegador), mas super-engenhar uma página trivial também é real. A decisão é: quantas páginas, o conteúdo precisa ser rastreável e rápido, e quão interativo é; então escolha a coisa mais leve que satisfaça esses requisitos.
Esta skill foi projetada para crescer. Adicione uma regra quando uma decisão arquitetural real tiver uma resposta estável e defensável.