---
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‑файлу на кожну локаль.
