---
createdAt: 2025-05-20
updatedAt: 2025-06-29
title: Renderização Estática vs Dinâmica com i18n no Next.js
description: Aprenda como usar renderização estática vs dinâmica com i18n no Next.js.
keywords:
- estático
- dinâmico
- renderização
- i18n
- next.js
- next-intl
- intlayer
- framework
- middleware
- configuração
slugs:
- frequent-questions
- static-rendering
---
# Renderização Estática vs Dinâmica com i18n no Next.js
## O problema com o **next-intl**
- **O que acontece?**
Quando você usa `useTranslations`, `getTranslations` ou qualquer helper do next-intl _dentro de um Componente de Servidor_ em um app com rotas i18n (`/en/…`, `/fr/…`), o Next.js marca toda a rota como **dinâmica**. ([Next Intl][1])
- **Por quê?**
next-intl busca a localidade atual a partir de um cabeçalho disponível apenas na requisição (`x-next-intl-locale`) via `headers()`. Como `headers()` é uma **API dinâmica**, qualquer componente que a utilize perde a otimização estática. ([Next Intl][1], [Next.js][2])
- **Solução oficial (boilerplate)**
1. Exporte `generateStaticParams` com todas as localidades suportadas.
2. Chame `setRequestLocale(locale)` em **todos** os layouts/páginas _antes_ de chamar `useTranslations`. ([Next Intl][1])
Isso remove a dependência do cabeçalho, mas agora você tem código extra para manter e uma API instável em produção.
## Como o **intlayer** evita o problema
**Escolhas de design**
1. **Apenas parâmetro de rota** – A localidade vem do segmento de URL `[locale]` que o Next.js já passa para cada página.
2. **Pacotes em tempo de compilação** – As traduções são importadas como módulos ES regulares, portanto são otimizadas (tree-shaken) e incorporadas no momento da compilação.
3. **Sem APIs dinâmicas** – `useT()` lê do contexto React, não de `headers()` ou `cookies()`.
4. **Configuração zero** – Uma vez que suas páginas estejam sob `app/[locale]/`, o Next.js pré-renderiza automaticamente um arquivo HTML por localidade.