---
createdAt: 2025-05-20
updatedAt: 2025-06-29
title: Статичний vs динамічний рендеринг з i18n у Next.js
description: Дізнайтеся, як використовувати статичний та динамічний рендеринг з i18n у Next.js.
keywords:
- статичний
- динамічний
- рендеринг
- i18n
- next.js
- next-intl
- intlayer
- фреймворк
- middleware
- конфігурація
slugs:
- frequent-questions
- static-rendering
---
# Статичний vs динамічний рендеринг з i18n у Next.js
## Проблема з **next-intl**
- **Що відбувається?**
Коли ви використовуєте `useTranslations`, `getTranslations`, або будь-який хелпер next-intl _всередині Server Component_ в застосунку з i18n-маршрутизацією (`/en/…`, `/fr/…`), Next.js позначає весь маршрут як **dynamic**. ([Next Intl][1])
- **Чому?**
next-intl визначає поточну локаль з заголовка, доступного лише в запиті (`x-next-intl-locale`) через `headers()`. Оскільки `headers()` — це **динамічний API**, будь-який компонент, який до нього звертається, втрачає статичну оптимізацію. ([Next Intl][1], [Next.js][2])
- **Офіційне рішення (boilerplate)**
1. Експортуйте `generateStaticParams` для кожної підтримуваної локалі.
2. Викликайте `setRequestLocale(locale)` у **кожному** layout/page _перед_ тим, як викликати `useTranslations`. ([Next Intl][1])
Це усуває залежність від заголовка, але додає додатковий код для підтримки та використовує нестабільний API у продакшені.
## Як **intlayer** обходить проблему
**Дизайн-рішення**
1. **Тільки параметр маршруту (route-param only)** – локаль береться з сегмента URL `[locale]`, який Next.js вже передає кожній сторінці.
2. **Бандли на етапі компіляції** – Переклади імпортуються як звичайні ES-модулі, тож вони піддаються tree-shaking і вбудовуються під час збірки.
3. **Без динамічних API** – `useT()` читає з React context, а не з `headers()` або `cookies()`.
4. **Жодної додаткової конфігурації** – Як тільки ваші сторінки розміщені під `app/[locale]/`, Next.js автоматично генерує по одному HTML‑файлу на кожну локаль.
