@intlayer/docs 9.5.6 → 9.5.7

package/blog/uk/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl: Один API, різні Bundle"
 description: Що змінюється, коли імпорти next-intl додатку Next.js обслуговуються адаптером сумісності @intlayer/next-intl. Розмір bundle, витік, розмір компонента та гідрація вимірюються на одному коді, а також те, що адаптер зберігає, ігнорує та не може замінити.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | Один API, різні Bundle
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` - це адаптер сумісності: він надає API `next-intl` (`useTranslations`, `getTranslations`, `useLocale`, `t.rich()`, ICU plurals, `NextIntlClientProvider`...) та обслуговує його з словників, скомпільованих Intlayer. Код застосунку не змінюється. Змінюється bundle.
 
 У цій статті порівнюються обидва на одному й тому ж Next.js застосунку, побудованому один раз з `next-intl` та один раз з адаптером. Цифри взяті з [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), open-source набору, який записує, що насправді завантажує браузер. Якщо вам потрібне порівняння `next-intl` та Intlayer як бібліотек, прочитайте [next-intl vs Intlayer](https://intlayer.org/uk/blog/next-intl-vs-intlayer). Ця стаття про те, як адаптер змінює все, коли ви зберігаєте компоненти як вони є.
@@ -109,6 +111,10 @@ const AboutPage = () => {
 
 ### Результати на Next.js
 
+Виберіть метрики та бібліотеки, які вас цікавлять:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Setup                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)        | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,6 +135,15 @@ const AboutPage = () => {
 - **Гідрація на 2 мс швидша** (12.8 vs 14.7 мс): немає об'єкта повідомлень для десеріалізації з RSC payload перед тим, як React може гідрувати.
 - **Адаптер - це не native runtime.** `next-intlayer` займає **141.3 KB**, +0.3 KB понад базову програму, з 5.5 KB runtime. Адаптер несе поверхню API `next-intl` (`useFormatter`, `t.rich`, ICU resolver) поверх ядра Intlayer, звідси 8.0 KB і +6 KB за сторінку. Це міст, а не пункт призначення.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Повна таблиця, кожна бібліотека та стратегія у [звіті про бенчмарк Next.js](https://intlayer.org/uk/doc/benchmark/nextjs).
+
 ### Результати на TanStack Start (`use-intl`)
 
 `use-intl` - це framework-агностичне ядро `next-intl`. Його адаптер `@intlayer/use-intl` слідує тому ж дизайну з Vite плагіном (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ const AboutPage = () => {
 - **Переключення локалі працює швидше.** Оптимізовані налаштування `use-intl` потребують **13-21 мс** для оновлення `html[lang]`; адаптер потребує **4-9 мс**. Менше компонентів перерендерюється, і ніщо не переважається із дерева повідомлень.
 - **`static` зберігає кожну локаль.** Рядок адаптера `static` показує витік локалі 49.7%, той же, що й у нативному Intlayer у режимі `static`: усі локалі bundled, але лише словники сторінки. Один рядок конфігурації (`importMode: 'dynamic'`) видаляє його.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Повна таблиця у [звіті про бенчмарк TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack).
+
 ## Чому змінюються цифри
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Ніщо в компоненті не змінилось, тому виграш повністю походить від того, до чого привʹязаний `useTranslations`.
 
-**З `next-intl`**, binding це провайдер. `NextIntlClientProvider` отримує весь об'єкт `messages` для локалі; кожен `useTranslations("about")` читає з нього. Bundler бачить один компонент, що імпортує один hook, який читає один контекст, і не може знати, що використовується тільки гілка `about`. Маршрути нижче всі ділять один і той же об'єкт messages, тому колонка page-leak читає ~90%, доки ви самі не розділите файл.
+**З `next-intl`**, binding це провайдер. `NextIntlClientProvider` отримує весь об'єкт `messages` для локалі; кожен `useTranslations("about")` читає з нього. Bundler бачить один компонент, що імпортує один hook, який читає один контекст, і не може знати, що використовується тільки гілка `about`. Маршрути нижче всі ділять один і той же об'єкт messages, тому колонка page-leak читає ~90%, доки ви самі не розділите файл, і зайве навантаження зростає за двома осями одночасно, сторінками та мовами:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -280,25 +308,106 @@ export default withIntlayer(nextConfig);
 
 ## Обмеження, які варто знати перед початком
 
-- **Routing config переміщується до `intlayer.config.ts`.** `createNavigation(routing)` та `createMiddleware(routing)` зберігають свою сигнатуру, але ігнорують аргумент: locales, default locale та стратегія префіксу беруться з Intlayer's `routing` config. Якщо ви використовуєте `next-intl`'s локалізовані `pathnames` (`/about` → `/a-propos`), адаптер їх не інтерполює; Intlayer's `routing.rewrite` охоплює цей випадок, але це окрема зміна.
-- **`useTranslations()` без namespace не прив'язаний.** Optimize pass потребує static namespace, щоб знати який dictionary імпортувати. Bare call все ще працює через runtime registry, який посилається на кожен dictionary, що є точно витоком, який ви намагалися видалити. Передавайте namespace.
-- **Адаптер не безкоштовний.** 8.0 КБ runtime проти 5.5 КБ для `next-intlayer`, та +6-7 КБ на сторінку над нативною збіркою. Це плата за `next-intl` API surface. Якщо ви дійшли до точки, де кожний компонент був перенесений на `useIntlayer`, відмовтеся від адаптера.
-- **`messages`, `timeZone`, `now` на провайдері ігноруються.** Форматери підтримуються нативним `Intl` і лише locale впливає на їх вихід; якщо ви покладаєтеся на примусову часову зону або фіксований `now` для hydration-стійких дат, обробіть це на місці виклику.
+<AccordionGroup>
+<Accordion header="Конфігурація маршрутизації переноситься в intlayer.config.ts">
+
+`createNavigation(routing)` та `createMiddleware(routing)` зберігають сигнатуру, але ігнорують аргумент: локалі, локаль за замовчуванням та стратегія префіксів надходять із конфігурації `routing` Intlayer. Якщо ви використовуєте локалізовані `pathnames` у `next-intl` (`/about` до `/a-propos`), адаптер їх не інтерполює; `routing.rewrite` в Intlayer покриває цей випадок, але це окрема зміна.
+
+</Accordion>
+<Accordion header="useTranslations() без простору імен не зв'язується">
+
+Фазі оптимізації потрібен статичний простір імен, щоб знати, який словник імпортувати. Простий виклик без namespace все одно працює через реєстр рантайму, що посилається на кожен словник, що є саме тим витоком, який ви намагалися усунути. Передавайте простір імен.
+
+</Accordion>
+<Accordion header="Адаптер не є безкоштовним">
+
+8.0 KB рантайму проти 5.5 KB для `next-intlayer`, і +6-7 KB на сторінку порівняно з нативною збіркою. Це плата за інтерфейс API `next-intl`. Коли кожен компонент перейде на `useIntlayer`, видаліть адаптер.
+
+</Accordion>
+<Accordion header="messages, timeZone та now у провайдері ігноруються">
+
+Форматери базуються на нативному `Intl`, і лише локаль впливає на їх результат. Якщо для стабільної гідратації дат ви покладаєтеся на примусовий часовий пояс або фіксований `now`, обробляйте це у місці виклику. Див. [форматування дати, часу та чисел](https://intlayer.org/uk/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## Коли використовувати що?
 
-- **Залишайтеся на `next-intl`** якщо ваш додаток малий, ваш bundle не є проблемою, і ваша команда комфортно володіє namespaces та `pick()` на сторінку.
-- **Використовуйте `@intlayer/next-intl`**, якщо ви вже використовуєте `next-intl` і хочете отримати переваги у bundle, витоки та hydration, типізовані ключі та інструменти CLI / CMS без переписування. Це рекомендована точка входу для будь-якої існуючої codebase `next-intl`.
-- **Перейдіть на native (`next-intlayer`)** для нових проектів або після того, як адаптер виконав свою роботу. Це найлегший із трьох (5.5 KB, +0.3 KB на сторінку) і розблоковує синхронні server components, файли `.content.ts` за компонентом та повний набір функцій.
+<AccordionGroup>
+<Accordion header="Залишайтеся на next-intl">
+
+Ваш застосунок невеликий, розмір бандла вас не турбує, а команді зручно вручну керувати просторами імен і `pick()` для кожної сторінки.
+
+</Accordion>
+<Accordion header="Використовуйте @intlayer/next-intl">
+
+Ви вже використовуєте `next-intl` сьогодні й бажаєте отримати переваги у розмірі бандла, відсутності витоків та швидкій гідратації, типізованих ключах та інструментах CLI / CMS без переписування коду. Це рекомендована точка входу для будь-якої існуючої кодової бази `next-intl`.
+
+</Accordion>
+<Accordion header="Перейдіть на нативний next-intlayer">
+
+Для нових проєктів або коли адаптер виконав свою перехідну роль. Це найлегший із трьох варіантів (5.5 KB, +0.3 KB на сторінку), що відкриває синхронні серверні компоненти, файли `.content.ts` для кожного компонента та повний набір функцій. Почніть з [Intlayer з Next.js](https://intlayer.org/uk/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Чи справді код мого застосунку залишається недоторканим?">
+
+У Next.js так для компонентів: збірка бенчмарку змінила лише `next.config.ts` та `intlayer.config.ts`. `getRequestConfig` у `src/i18n.ts`, проп `messages` у провайдері та виклики `pick()` стають мертвим кодом, який ви можете згодом видалити.
+
+</Question>
+
+<Question title="Що відбувається з повідомленнями ICU?">
+
+Вони продовжують працювати. `t("key", { count })`, `t.rich()`, `t.markup()`, `select`, `selectordinal`, `#` та `{ts, date, long}` обробляються резолвером ICU в Intlayer. Див. [формат повідомлень ICU](https://intlayer.org/uk/blog/icu-message-format).
+
+</Question>
+
+<Question title="Чому адаптер важчий за нативний next-intlayer?">
+
+Він несе API `next-intl` поверх ядра Intlayer: `useFormatter`, `t.rich`, резолвер ICU, хелпери навігації. Це 8.0 KB проти 5.5 KB і +6 KB на сторінку. Це міст, а не кінцева мета.
+
+</Question>
+
+<Question title="Чи можу я мігрувати компонент за компонентом?">
+
+Так. Будь-який компонент може перейти з `useTranslations("about")` на `useIntlayer("about")` з розташованим поруч файлом `.content.ts`. Словники JSON та `.content.ts` співіснують і об'єднуються.
+
+</Question>
+
+<Question title="Чи працюють локалізовані шляхи (pathnames)?">
+
+Не через `pathnames` у `next-intl`: адаптер приймає їх для типізації, але не інтерполює. Використовуйте натомість `routing.rewrite` від Intlayer.
+
+</Question>
+
+</FAQ>
 
 ## Пов'язані порівняння
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (бібліотеки, той же бенчмарк)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (та ж серія адаптерів)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (та ж серія адаптерів)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (та ж серія адаптерів)
-- [Посібник з міграції: next-intl на Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [Довідка адаптера сумісності: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+Та сама серія адаптерів:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/uk/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/uk/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Пряме порівняння бібліотек:
+
+- [next-intl vs Intlayer](https://intlayer.org/uk/blog/next-intl-vs-intlayer), той самий бенчмарк
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/uk/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/uk/blog/is-next-intl-outdated)
+
+Довідкова документація:
+
+- [Compat adapter: next-intl](https://intlayer.org/uk/doc/compatibility/next-intl)
+- [Посібник із міграції: з next-intl на Intlayer](https://intlayer.org/uk/doc/migration/next-intl)
+- [Звіт про бенчмарк Next.js](https://intlayer.org/uk/doc/benchmark/nextjs) та [звіт про бенчмарк TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack)
+- [Оптимізація бандла](https://intlayer.org/uk/doc/concept/bundle-optimization) та [компілятор Intlayer](https://intlayer.org/uk/doc/compiler)
+- [Візуальний редактор](https://intlayer.org/uk/doc/concept/editor), [CMS](https://intlayer.org/uk/doc/concept/cms) та [переклад за допомогою ШІ](https://intlayer.org/uk/doc/concept/auto-fill)
 
 ## Висновок
 

package/blog/uk/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl проти Intlayer: Бенчмарк та порівняння 2026"
 description: "Детальне порівняння next-intl та Intlayer у Next.js App Router і TanStack Start. Розмір бандла, витік контенту, розмір компонентів, гідратація та досвід розробника."
 keywords:
@@ -22,11 +22,11 @@ author: aymericzip
 
 # next-intl проти Intlayer | Бенчмарк інтернаціоналізації (i18n) у React та Next.js
 
-`next-intl` на сьогодні є стандартним вибором для i18n у Next.js App Router: тісна інтеграція з маршрутизацією, повна підтримка ICU MessageFormat та звичний досвід розробника для всіх, хто працював із класичними системами i18n.
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
 
-`Intlayer` повністю переосмислює цей підхід: жодних централізованих словників, жодної потреби вручну прив'язувати простори імен (namespaces) до маршрутів. Контент оголошується безпосередньо поруч із кожним компонентом, а компілятор часу збирання пакує лише те, що дійсно потрібно кожній окремій сторінці.
+`next-intl` є найпопулярнішою бібліотекою i18n для Next.js. Intlayer, це альтернатива на основі компілятора з областю видимості на рівні компонентів. Обидва рішення локалізують застосунок App Router. Питання полягає в тому, скільки коштує кожне з них після збирання проєкту.
 
-У цій статті порівнюються дві бібліотеки на основі даних із [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), відкритого набору тестів, який збирає однаковий додаток з кожною бібліотекою та фіксує те, що браузер насправді завантажує і виконує.
+Ця стаття не є посібником. Це порівняння, підтверджене даними з [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), відкритого набору бенчмарків, який створює однаковий застосунок із кожною бібліотекою та вимірює те, що браузер фактично завантажує та виконує.
 
 <TOC/>
 
@@ -89,6 +89,10 @@ Intlayer не має варіанта "scoped": компілятор автом
 
 ### Результати на Next.js (App Router)
 
+Виберіть метрики та бібліотеки, які вас цікавлять:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Бібліотека                      | Стратегія      | Розмір Lib (gz) | Сер. JS сторінки (gz) | Витік локалі | Витік сторінки | Сер. компонента (gz) | Реактивність E2E | Гідратація |
 | ------------------------------- | -------------- | --------------: | --------------------: | -----------: | -------------: | -------------------: | ---------------: | ---------: |
 | **Базовий додаток** (без i18n)  | -              |          0.0 KB |              141.0 KB |         0.0% |           0.0% |               0.9 KB |          13.4 ms |    11.8 ms |
@@ -107,8 +111,19 @@ Intlayer не має варіанта "scoped": компілятор автом
 - **Витік контенту.** У найпоширеніших конфігураціях (`static` та `dynamic`) `next-intl` відправляє на кожну сторінку **~90% рядків з інших сторінок**, оскільки весь файл `en.json` потрапляє до клієнтського провайдера. Щоб зменшити цей показник до 0%, потрібен складний ручний поділ на простори імен, тоді як в Intlayer це працює за замовчуванням.
 - **Розмір компонента.** Компонент із `useTranslations()` важить у середньому 21.8 КБ; той самий компонент з `useIntlayer()` важить лише 6.9 КБ.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Повна таблиця, кожна бібліотека та кожна стратегія, у [звіті бенчмарку Next.js](https://intlayer.org/uk/doc/benchmark/nextjs).
+
 ### Результати на TanStack Start (`use-intl`)
 
+`use-intl`, це незалежне від фреймворку ядро `next-intl`. Той самий API, той самий формат повідомлень. Порівняння його з `intlayer` на TanStack Start усуває особливості Next.js із рівняння.
+
 | Бібліотека                     | Стратегія      | Розмір Lib (gz) | Сер. JS сторінки (gz) | Витік локалі | Витік сторінки | Сер. компонента (gz) | Реактивність E2E |
 | ------------------------------ | -------------- | --------------: | --------------------: | -----------: | -------------: | -------------------: | ---------------: |
 | **Базовий додаток** (без i18n) | -              |          0.0 KB |              111.0 KB |         0.0% |           0.0% |               0.7 KB |           8.1 ms |
@@ -127,8 +142,19 @@ Intlayer не має варіанта "scoped": компілятор автом
 - Архітектурна різниця особливо помітна у **розмірі компонентів**: 76-87 КБ у `use-intl` проти 6-8 КБ в Intlayer.
 - **Перемикання локалі** відбувається у 2-4 рази швидше з Intlayer (3 мс проти 7-21 мс).
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Повна таблиця у [звіті бенчмарку TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack).
+
 ## Чому виникає різниця? Централізовані каталоги проти скомпільованих словників
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `next-intl` слідує класичній моделі: один JSON для кожної мови, завантажується в `getRequestConfig`, передається в `NextIntlClientProvider` і зчитується через `t("namespace.key")`.
 
 ```bash
@@ -150,6 +176,10 @@ Intlayer не має варіанта "scoped": компілятор автом
 
 Runtime не може передбачити, які саме ключі знадобляться сторінці, тому відправка всього каталогу є єдиним безпечним варіантом.
 
+Ціна недосягнення цієї мети зростає відразу по двох осях, сторінки та локалі:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer змінює цей підхід. Контент декларується безпосередньо поруч із компонентом:
 
 ```bash
@@ -177,7 +207,8 @@ Intlayer змінює цей підхід. Контент декларуєтьс
 
 ### Клієнтський компонент
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -188,7 +219,7 @@ Intlayer змінює цей підхід. Контент декларуєтьс
 }
 ```
 
-```tsx fileName="src/components/Counter.tsx"
+```tsx fileName="src/components/ClientCounter.tsx"
 "use client";
 
 import { useState } from "react";
@@ -210,7 +241,10 @@ export const Counter = () => {
 };
 ```
 
-**Intlayer**
+> Не забудьте включити простір імен `counter` у повідомлення, що передаються до `NextIntlClientProvider` на кожній сторінці, яка рендерить цей компонент.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -249,11 +283,16 @@ export const Counter = () => {
 };
 ```
 
+На сторінці нічого не потрібно реєструвати: компонент приносить власний вміст.
+
+</Tab>
+</Tabs>
 ### Синхронні серверні компоненти
 
 Елементи дизайн-системи (навігаційні панелі, підвали, картки) часто є серверними компонентами, що відображаються всередині клієнтських компонентів, тому вони не можуть бути `async`.
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -269,7 +308,10 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 );
 ```
 
-**Intlayer**
+Сторінка повинна виконати `await getTranslations("counter")` та `await getFormatter()`, а потім передати результати як пропси. Компонент більше не є автономним.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -288,9 +330,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### Метадані
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -323,7 +368,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -347,6 +393,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Збережіть API next-intl, отримайте оптимізований вихід Intlayer
 
 Вам не потрібно переписувати компоненти, щоб отримати наведені вище результати продуктивності. Пакет `@intlayer/next-intl` є сумісним адаптером: він зберігає `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()` та множинні форми ICU, обслуговуючи їх зі словників, скомпільованих компілятором Intlayer.
@@ -368,17 +417,84 @@ export default withIntlayer(nextConfig);
 
 ## Що і коли обрати?
 
-- **Обирайте next-intl**, якщо вам потрібен стандарт спільноти Next.js, ви повністю спираєтесь на ICU MessageFormat, ваш проєкт невеликий або середній, або ви використовуєте платформи перекладу з централізованими JSON (Crowdin, Phrase, Lokalise...).
-- **Обирайте Intlayer**, якщо вам потрібен **контент з прив'язкою до компонентів**, **суворий TypeScript**, **помилки про відсутні ключі під час збирання**, **автоматичний tree-shaking та ліниве завантаження**, синхронні серверні компоненти та вбудовані інструменти редагування (Візуальний редактор, CMS, переклад за допомогою ШІ, сервер MCP).
-- **Обирайте `@intlayer/next-intl`**, якщо ви вже використовуєте `next-intl` і бажаєте отримати переваги в оптимізації бандла без переписування коду.
+<AccordionGroup>
+<Accordion header="Обрати next-intl">
+
+Вам потрібен стандарт екосистеми для Next.js, ви покладаєтеся на ICU MessageFormat, ваш додаток невеликий або середнього розміру, або ви інтегруєтеся з платформою перекладу (Crowdin, Phrase, Lokalise...), яка очікує централізований JSON. Заплануйте час на поділ каталогів на простори імен і вибір повідомлень через `pick()` на кожній сторінці, якщо важлива продуктивність.
+
+</Accordion>
+<Accordion header="Обрати Intlayer">
+
+Вам потрібен **контент з областю видимості компонента**, **суворий TypeScript**, **помилки відсутніх ключів на етапі збірки**, **автоматичний tree-shaking та ліниве завантаження**, синхронні серверні компоненти та вбудовані інструменти редагування ([Візуальний редактор](https://intlayer.org/uk/doc/concept/editor), [CMS](https://intlayer.org/uk/doc/concept/cms), [ШІ-переклад](https://intlayer.org/uk/doc/concept/auto-fill), [MCP-сервер](https://intlayer.org/uk/doc/mcp-server)). Особливо актуально для великих модульних кодових баз та дизайн-систем.
+
+</Accordion>
+<Accordion header="Обрати @intlayer/next-intl">
+
+Ви вже використовуєте `next-intl` і хочете отримати переваги в розмірі бандла без повного переписування. [Адаптер сумісності](https://intlayer.org/uk/doc/compatibility/next-intl) зберігає ваші імпорти та файл `messages/{locale}.json` як єдине джерело правди. Порівняно пліч-о-пліч у [next-intl проти @intlayer/next-intl](https://intlayer.org/uk/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## Часті запитання
+
+<FAQ>
+
+<Question title="next-intl повільніший за Intlayer?">
+
+Не під час рендерингу. Різниця полягає в тому, що надсилається клієнту: `next-intl` додає **+12.6 KB gzip** рантайму на кожній сторінці і в стандартних конфігураціях надсилає ~90% рядків чужих сторінок з кожною сторінкою. Перемикання мови та гідратація порівнянні в Next.js (15-18 мс); в TanStack Start `use-intl` займає 7-21 мс проти 3-4 мс у Intlayer.
+
+</Question>
+
+<Question title="Чи можу я досягти 0% витоку з next-intl?">
+
+Так, з конфігурацією `scoped-dynamic`: розділіть `messages/{locale}.json` на простори імен для кожного маршруту, потім використовуйте `pick(messages, [...])` на кожній сторінці і підтримуйте це зіставлення правильним у міру переміщення компонентів. Рядки `scoped-*` бенчмарку якраз відображають цю роботу. Intlayer досягає 0% за замовчуванням без цього, оскільки компілятор ізолює контент по компонентах. Див. [оптимізація бандла](https://intlayer.org/uk/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Чи потрібно переписувати компоненти для міграції?">
+
+Ні. `@intlayer/next-intl` зберігає `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, множинні форми ICU та помічники навігації, надаючи їх зі скомпільованих словників. Лише один рядок плагіна в `next.config.ts`. Покроково в [посібнику з міграції next-intl](https://intlayer.org/uk/doc/migration/next-intl).
+
+</Question>
+
+<Question title="Чи підтримує Intlayer формат повідомлень ICU?">
+
+Нативна підтримка ICU знаходиться в розробці. Адаптери сумісності (`@intlayer/next-intl`, `@intlayer/use-intl`) повністю підтримують ICU: множинні форми, `select`, `selectordinal`, `#` та `{ts, date, long}` обробляються резолвером ICU від Intlayer. Докладніше читайте в [формат повідомлень ICU](https://intlayer.org/uk/blog/icu-message-format).
+
+</Question>
+
+<Question title="Чи можу я зберегти файли messages/{locale}.json?">
+
+Так. [Плагін синхронізації JSON](https://intlayer.org/uk/doc/compatibility/next-intl) читає їх, розбиває ключі верхнього рівня на словники та перезаписує переклади в ті самі файли під час оновлення через CLI або CMS. Робочий процес ваших перекладачів не змінюється.
+
+</Question>
+
+</FAQ>
 
 ## Схожі порівняння
 
-- [i18next проти Intlayer](https://intlayer.org/uk/blog/i18next-vs-intlayer) (той самий бенчмарк)
-- [Lingui проти Intlayer](https://intlayer.org/uk/blog/lingui-vs-intlayer) (той самий бенчмарк)
-- [Бенчмарк vue-i18n проти Intlayer](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer-benchmark) (той самий бенчмарк)
-- [next-i18next проти next-intl проти Intlayer](https://intlayer.org/uk/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [Чи застарів next-intl?](https://intlayer.org/uk/blog/is-next-intl-outdated)
+Той самий бенчмарк, інші бібліотеки:
+
+- [i18next vs Intlayer](https://intlayer.org/uk/blog/i18next-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/uk/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/uk/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/uk/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/uk/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Більше про next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/uk/blog/next-intl-vs-intlayer-next-intl), адаптер виміряно на тому ж додатку
+- [Is next-intl outdated?](https://intlayer.org/uk/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/uk/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/uk/blog/nextjs-internationalization-using-next-intl)
+
+Довідкова документація:
+
+- [Звіт бенчмарку Next.js](https://intlayer.org/uk/doc/benchmark/nextjs) та [звіт бенчмарку TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack)
+- [Адаптер сумісності: next-intl](https://intlayer.org/uk/doc/compatibility/next-intl) та [посібник з міграції](https://intlayer.org/uk/doc/migration/next-intl)
+- [Оптимізація бандла](https://intlayer.org/uk/doc/concept/bundle-optimization) та [компілятор Intlayer](https://intlayer.org/uk/doc/compiler)
+- [Компонентна i18n проти централізованої](https://intlayer.org/uk/blog/per-component-vs-centralized-i18n)
+- [Компіляторна i18n проти декларативної](https://intlayer.org/uk/blog/compiler-vs-declarative-i18n)
 
 ## Зірки GitHub