@intlayer/docs 9.5.6 → 9.5.8

package/blog/uk/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next проти Intlayer: бенчмарк та детальне порівняння 2026"
 description: "Порівняння react-i18next та next-i18next з Intlayer на Next.js та TanStack Start. Розмір bundle, витік контенту, швидкість перемикання мови та досвід розробника."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next проти Intlayer | Бенчмарк інтернаціоналізації (i18n) для React та Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` - найпопулярніший фреймворк інтернаціоналізації (i18n) в екосистемі JavaScript. Через `react-i18next` та `next-i18next` він використовується у величезній кількості додатків React та Next.js. Intlayer - це сучасна альтернатива на основі компілятора з ізольованою областю видимості для кожного компонента.
 
 У цій статті порівнюються дві бібліотеки на основі реальних вимірювань, а не просто переліку функцій. Усі показники отримані з [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) - відкритого набору тестів, який збирає однаковий додаток з кожною бібліотекою та фіксує те, що браузер реально завантажує по мережі.
@@ -99,6 +101,10 @@ Intlayer не потребує окремого варіанту "scoped": ко
 
 ### Результати на Next.js (`next-i18next`)
 
+Виберіть метрики та бібліотеки, які вас цікавлять:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Бібліотека                         | Стратегія      | Вага Lib (gz) | Сер. JS сторінки (gz) | Витік мов | Витік сторінок | Сер. вага комп. (gz) | Реактивність E2E | Час гідратації |
 | ---------------------------------- | -------------- | ------------: | --------------------: | --------: | -------------: | -------------------: | ---------------: | -------------: |
 | **base** (без i18n)                | -              |        0.0 KB |              141.0 KB |      0.0% |           0.0% |               0.9 KB |          13.4 ms |        11.8 ms |
@@ -119,6 +125,15 @@ Intlayer не потребує окремого варіанту "scoped": ко
 - **Розмір компонентів**: компонент із викликом `useTranslation()` компілюється у 26-79 KB; той самий компонент з `useIntlayer()` важить усього 6.9 KB.
 - **Гідратація уповільнюється**: час гідратації зростає до 27.7 ms у конфігурації `dynamic`, оскільки екземпляр i18next має ініціалізуватися й отримати дані з бекенда на клієнті до того, як React завершить гідратацію.
 
+<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 (`react-i18next`)
 
 Той самий додаток на TanStack Start із чистим `react-i18next` для виключення специфіки Next.js:
@@ -141,8 +156,19 @@ Intlayer не потребує окремого варіанту "scoped": ко
 - Режим `static` у Intlayer за замовчуванням має **0% витоку сторінок**, оскільки до бандла потрапляють лише словники, задіяні компонентами поточної сторінки. А увімкнення `importMode: 'dynamic'` повністю ліквідує витік мов.
 - **Розмір компонентів**: 24-27 KB у `react-i18next` проти 6-8 KB в Intlayer. `useTranslation()` завжди прив'язує кожен компонент до глобального екземпляра i18next.
 
+<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)
+
 `i18next` створювався у 2012 році як середовище виконання: єдиний глобальний об'єкт містить базу ресурсів, плагіни доповнюють його, а функція `t()` шукає ключі під час рендерингу. Це забезпечує високу гнучкість, але призводить до відчутного навантаження:
 
 ```bash
@@ -166,7 +192,13 @@ Intlayer не потребує окремого варіанту "scoped": ко
                 └── page.tsx     # повинна знати, що потрібні ["common", "about"]
 ```
 
-Глобальний екземпляр не знає заздалегідь, які ключі знадобляться конкретному компоненту; він завантажує весь переданий простір імен. Оптимізація вимагає, щоб **ви** розбивали каталоги, **ви** вказували простори імен для кожної сторінки та **ви** стежили за актуальністю цього списку при змінах. Як зазначається у [звіті бенчмарку](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "Підтримувати типобезпеку і точно знати, який простір імен додати на кожну сторінку - це справжній кошмар".
+Глобальний екземпляр не знає заздалегідь, які ключі знадобляться конкретному компоненту; він завантажує весь переданий простір імен. Оптимізація вимагає, щоб **ви** розбивали каталоги, **ви** вказували простори імен для кожної сторінки та **ви** стежили за актуальністю цього списку при змінах.
+
+Витрати зростають за двома осями одночасно, сторінками та локалями:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Як зазначається у [звіті бенчмарку](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "Підтримувати типобезпеку і точно знати, який простір імен додати на кожну сторінку - це справжній кошмар".
 
 Intlayer повністю позбувається глобального екземпляра. Контент оголошується безпосередньо поруч із компонентом, а компілятор розв'язує дерево залежностей під час збірки:
 
@@ -193,7 +225,8 @@ Intlayer повністю позбувається глобального екз
 
 ### Налаштування конфігурації
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Додатково потрібно налаштувати клієнтський `I18nProvider`, `generateStaticParams` та вручну вказувати масив `namespaces` на кожній сторінці.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Клієнтський компонент
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > Сторінка, на якій відображається цей компонент, зобов'язана підвантажити namespace `about`, а виклик `t("counter.label")` залишається простим нетипізованим рядком, якщо не розширювати `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 Поля `label` та `increment` суворо типізовані; будь-яка помилка друку викличе помилку TypeScript, а відсутність французького перекладу зупинить процес збірки.
 
+</Tab>
+</Tabs>
+
 ### Синхронний серверний компонент (RSC)
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 Сторінка повинна викликати `i18n.getFixedT(locale, "about")` і спускати `t` та `locale` вниз через props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Збережіть API i18next, отримайте швидкодію Intlayer
 
 Вам не потрібно переписувати всі компоненти, щоб скористатися перевагами бенчмарку. Адаптери `@intlayer/i18next`, `@intlayer/react-i18next` та `@intlayer/next-i18next` підключаються як пряма заміна: виклики `useTranslation`, `t()`, `<Trans>`, форми множини та суфікси контексту продовжують працювати, транслюючись зі словників, скомпільованих Intlayer.
@@ -415,18 +462,85 @@ export default defineConfig({
 
 ## Що і коли обирати?
 
-- **Обирайте i18next**: якщо вам критично необхідна його екосистема плагінів (специфічні детектори, кастомні бекенди, ICU, Locize), ви реалізуєте переклад поза React (сервіси Node, чистий JS, інші фреймворки), команда вже має значний досвід, або зовнішня платформа вимагає структури `locales/{lng}/{ns}.json`. Але виділіть ресурси на підтримку просторів імен та маршрутів, якщо швидкість має значення.
-- **Обирайте Intlayer**: якщо вам потрібні **контент у структурі компонентів**, **сувора типізація TypeScript**, **виявлення пропущених перекладів під час збірки**, **автоматичний tree-shaking та ліниве завантаження без зусиль**, миттєва зміна мови, синхронні серверні компоненти та вбудовані інструменти (візуальний редактор, CMS, переклад ШІ, сервер MCP). Ідеально для модульних проєктів та дизайн-систем.
-- **Обирайте адаптери `@intlayer/*-i18next`**: якщо у вас уже є готовий проєкт на i18next і ви хочете швидко зменшити розмір бандла та покращити швидкість відгуку без масштабного рефакторингу.
+<AccordionGroup>
+<Accordion header="Обрати i18next">
+
+Якщо вам критично необхідна його екосистема плагінів (специфічні детектори, кастомні бекенди, ICU, Locize), ви реалізуєте переклад поза React (сервіси Node, чистий JS, інші фреймворки), команда вже має значний досвід, або зовнішня платформа вимагає структури `locales/{lng}/{ns}.json`. Але виділіть ресурси на підтримку просторів імен та маршрутів, якщо швидкість має значення.
+
+</Accordion>
+<Accordion header="Обрати Intlayer">
+
+Вам потрібен **контент на рівні компонентів**, **суворий TypeScript**, **помилки відсутніх ключів на етапі збірки**, **tree-shaking та lazy loading без зусиль**, миттєве перемикання мови, синхронні серверні компоненти та вбудовані інструменти редагування ([Візуальний редактор](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/*-i18next">
+
+Ви вже використовуєте i18next і хочете отримати переваги у розмірі бандла та реактивності без переписування компонентів. Ваші файли `locales/{lng}/{ns}.json` залишаються джерелом істини. Виміряно пліч-о-пліч у [i18next проти @intlayer/i18next](https://intlayer.org/uk/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ (Часті запитання)
+
+<FAQ>
+
+<Question title="Чому i18next набагато важчий за інші бібліотеки?">
+
+Він створювався як агностичний до фреймворків рантайм: глобальний екземпляр, конвеєр плагінів, сховище ресурсів, резолвер ключів. Ця гнучкість компілюється в кожен бандл. Порожній компонент, який імпортує лише бібліотеку, коштує **19.7 KB gzip** з `next-i18next` проти **5.5 KB** з `next-intlayer`, і ця ціна сплачується на кожній сторінці, незалежно від обсягу вмісту.
+
+</Question>
+
+<Question title="Чи вирішує проблему ліниве завантаження з бекендом?">
+
+Воно вирішує проблему байтів, а не затримки. Перехід на `i18next-resources-to-backend` заощаджує ~49 KB на сторінку, але додає мережевий запит при зміні мови: **123 мс** у конфігурації `dynamic` і **185 мс** у `scoped-static` проти **3-4 мс** в Intlayer. Гідратація також стрибає до 27.7 мс, оскільки інстанс опитує бекенд до гідратації React.
+
+</Question>
+
+<Question title="Чи можу я досягти 0% витоку з i18next?">
+
+Так, із `scoped-dynamic`: один простір імен на маршрут, бекенд ресурсів і карта сторінок до просторів імен, яка підтримується вручну. Це дає 163.4 KB на сторінку в Next.js, що все одно на **+22 KB** більше, ніж 141.3 KB в Intlayer, який не вимагав жодного налаштування. Див. [оптимізацію бандла](https://intlayer.org/uk/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Чи потрібно переписувати компоненти для міграції?">
+
+Ні. `@intlayer/i18next`, `@intlayer/react-i18next` та `@intlayer/next-i18next` зберігають `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, множинні форми `_one` / `_other`, контекстні суфікси та `returnObjects`. Всього один рядок плагіна в `next.config.ts` або `vite.config.ts`. Покроково в [посібнику з міграції next-i18next](https://intlayer.org/uk/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Що відбувається з моїми плагінами i18next?">
+
+Бекенди та детектори мови приймаються, але залишаються пасивними: у рантаймі більше нічого завантажувати або визначати. Визначення мови стає конфігурацією маршрутизації Intlayer (префікс URL, cookie, заголовок). Якщо ваш додаток отримує переклади з CMS під час запиту, використовуйте [Intlayer CMS](https://intlayer.org/uk/doc/concept/cms) або команди `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Схожі порівняння
 
-- [next-intl проти Intlayer](https://intlayer.org/uk/blog/next-intl-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)
-- [react-i18next проти react-intl та Intlayer](https://intlayer.org/uk/blog/react-i18next-vs-react-intl-vs-intlayer)
+Той самий бенчмарк, інші бібліотеки:
+
+- [next-intl vs Intlayer](https://intlayer.org/uk/blog/next-intl-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)
+
+Докладніше про i18next:
+
+- [i18next проти @intlayer/i18next](https://intlayer.org/uk/blog/i18next-vs-intlayer-i18next), адаптери виміряні на одному додатку
 - [Чи застарів i18next?](https://intlayer.org/uk/blog/is-i18next-outdated)
+- [Використання Intlayer з i18next](https://intlayer.org/uk/blog/intlayer-with-i18next) та [з react-i18next](https://intlayer.org/uk/blog/intlayer-with-react-i18next)
+- [Як інтернаціоналізувати додаток Next.js за допомогою next-i18next](https://intlayer.org/uk/blog/nextjs-internationalization-using-next-i18next)
+
+Довідкова документація:
+
+- [Звіт про бенчмарк Next.js](https://intlayer.org/uk/doc/benchmark/nextjs) та [звіт про бенчмарк TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack)
+- Адаптери сумісності: [i18next](https://intlayer.org/uk/doc/compatibility/i18next), [react-i18next](https://intlayer.org/uk/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/uk/doc/compatibility/next-i18next)
+- Посібники з міграції: [i18next](https://intlayer.org/uk/doc/migration/i18next), [react-i18next](https://intlayer.org/uk/doc/migration/react-i18next), [next-i18next](https://intlayer.org/uk/doc/migration/next-i18next)
+- [Оптимізація бандла](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
 

package/blog/uk/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Чи легший Intlayer за Paraglide?
+description: Paraglide виглядає практично безкоштовним у бенчмарках i18n, оскільки його код генерується безпосередньо у ваш репозиторій. Розбираємося, куди насправді дівається ця вага, чому зчитування локалі для кожного вузла знижує продуктивність і як динамічне завантаження Intlayer передає одну локаль замість усіх.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Інтернаціоналізація
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Чи легший Intlayer за Paraglide?
+
+Так.
+
+`Paraglide` має чудову репутацію найлегшого рішення для i18n, і на перший погляд [бенчмарк](https://intlayer.org/uk/doc/benchmark/tanstack) це підтверджує: розмір його бібліотеки близький до нуля. Проте нульовий розмір бібліотеки зовсім не означає нуль переданих байтів. Це лише вказує на те, що байти знаходяться там, куди ця метрика не заглядає.
+
+<TOC/>
+
+## Ключові висновки
+
+**Розмір бібліотеки прихований, а не усунутий:**
+
+Paraglide генерує свій runtime та функції повідомлень безпосередньо у вашу кодову базу. Цей код відправляється в браузер, але враховується як _ваш_ код, а не код бібліотеки.
+
+**Відсутність провайдера - це не безкоштовний виграш:**
+
+Кожен виклик `m.my_key()` самостійно визначає локаль, зчитуючи cookie або сховище для кожного відрендереного вузла, замість того щоб прочитати її один раз із контексту.
+
+**Немає динамічного завантаження:**
+
+Paraglide імпортує всі локалі повідомлення в клієнтський бандл. Intlayer із параметром `importMode: 'dynamic'` або `'fetch'` завантажує лише ту локаль, яка зараз відображається.
+
+**Tree shaking не гарантується:**
+
+У деяких наших тестах заявлений Paraglide tree shaking не спрацював. Обов'язково перевірте власний бандл.
+
+## Куди дівається вага Paraglide?
+
+У звітах бенчмарків метрика «розмір бібліотеки» вимірює провайдер і хуки кожної бібліотеки i18n у порожньому компоненті, до додавання будь-якого контенту.
+
+| Бібліотека (TanStack Start)   | Розмір ліби (gz) | Розмір ліби (min) |
+| ----------------------------- | ---------------- | ----------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB           | 4.5 KB            |
+| `react-intlayer@9.5.1`        | 5.0 KB           | 15.2 KB           |
+
+Якщо розглядати ці цифри окремо, Paraglide виграє. Але Paraglide - це компілятор: він читає ваші файли `messages/*.json` і записує папку `paraglide/` у ваш репозиторій. Вона містить `runtime.js` (визначення локалі, стратегії cookie та сховища, локалізація URL) і по одній функції JavaScript на кожне повідомлення.
+
+```bash
+src/paraglide/
+├── runtime.js      # визначення локалі, стратегії, допоміжні інструменти URL
+├── server.js
+├── messages.js     # реекспорт усіх повідомлень
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Оскільки цей код розташований у вашій папці `src/` і імпортується за відносним шляхом, бандлер зараховує його до вашого додатку, а не до пакетів у `node_modules`. Колонка розміру бібліотеки не показує майже нічого, тоді як та сама логіка все одно передається в бандлі вашої сторінки.
+
+Генерація коду сама по собі не є поганою ідеєю: згенерований runtime містить лише ту логіку, яка потрібна вашій конфігурації (стратегія префіксів, cookie проти local storage тощо). Intlayer досягає того ж результату інакше: впроваджуючи змінні середовища під час збірки, завдяки чому бандлер відкидає гілки, які ваша конфігурація не використовує. Обидва підходи виявляються в 3–10 разів легшими за `i18next` або `next-intl`.
+
+Тому справедливе порівняння полягає не в розмірі бібліотеки. Це **обсяг JavaScript, який фактично передається на сторінку**.
+
+## Виміряна вага сторінки
+
+Додаток TanStack Start, 10 сторінок, виміри на маршрутах `en` та `fr`, стиснення gzip:
+
+| Конфігурація                       | Сер. JS стор (gz) | Понад базу  | Витік локалі | Витік інших сторінок |
+| ---------------------------------- | ----------------- | ----------- | ------------ | -------------------- |
+| База (без i18n)                    | 111.0 KB          | -           | 0.0%         | 0.0%                 |
+| `paraglide` (будь-яка стратегія)   | 125.1 KB          | +14.1 KB    | 49.7%        | 0.0%                 |
+| `intlayer` (`importMode: static`)  | 125.8 KB          | +14.8 KB    | 50.0%        | 0.0%                 |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**      | **+7.6 KB** | **0.0%**     | **0.0%**             |
+
+Next.js 16 App Router, той самий додаток:
+
+| Конфігурація     | Сер. JS стор (gz) | Понад базу  |
+| ---------------- | ----------------- | ----------- |
+| База (без i18n)  | 141.0 KB          | -           |
+| `paraglide-next` | 155.3 KB          | +14.3 KB    |
+| `next-intlayer`  | **141.3 KB**      | **+0.3 KB** |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Повні дані наведено у [звіті бенчмарку TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack) та [звіті бенчмарку Next.js](https://intlayer.org/uk/doc/benchmark/nextjs). Кожен бандл можна детально оглянути в [репозиторії бенчмарку](https://github.com/intlayer-org/benchmark-i18n).
+
+Два висновки стають очевидними:
+
+- У режимі `static` Intlayer передає практично той самий обсяг контенту, що й Paraglide (125.8 KB проти 125.1 KB). Це природно: обидва містять усі локалі повідомлень, які використовує сторінка.
+- Paraglide залишається на рівні 125.1 KB за будь-якої стратегії, оскільки не має динамічного режиму. Кожен рядок у таблиці вище відповідає статичному варіанту.
+
+## Відсутність Provider: ідея, яка здається гарною лише зовні
+
+Paraglide не потребує провайдера. Ви просто імпортуєте повідомлення та викликаєте його:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Жодного контексту, жодних обгорток, жодних хуків. Здається простішим. Але інформацію про локаль усе одно потрібно звідкись отримувати. Кожна згенерована функція повідомлення виглядає приблизно так (спрощено):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // обчислюється під час кожного виклику
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...по одній гілці на кожну локаль
+};
+```
+
+А `getLocale()` проходить по всіх налаштованих стратегіях (cookie, local storage, URL, базова локаль), щоб знайти поточну мову. Отже, кожен відрендерений текстовий вузол (`<>{m.my_key()}</>`) виконує власне визначення локалі, включно зі зчитуванням `document.cookie` в браузері. Сторінка з 200 перекладеними рядками визначає локаль 200 разів за одне рендерення, і повторює це під час кожного повторного рендерення.
+
+Бібліотека з провайдером зчитує локаль **один раз**, зберігає її в контексті (або сигналі, або сторі), і кожен вузол читає значення, яке вже присутнє в пам'яті. Провайдер коштує всього кілька сотень байтів. Відмова від нього навантажує процесор під час кожного рендерення, що чітко видно в бенчмарках: час завантаження сторінки та перемикання мови в Paraglide стабільно поступаються Intlayer на TanStack Start (22.1 мс проти 14.6 мс при завантаженні сторінки, 4.3 мс проти 3.2 мс у реактивності E2E).
+
+## Досвід розробника (DX)
+
+Джерелом правди для Paraglide є JSON, але розробник ніколи не імпортує файли JSON безпосередньо. Ви імпортуєте згенерований файл `.js`:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/uk.json"
+{
+  "hero_title": "Публікуйте свій застосунок усіма мовами"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Існує лише після перегенерації компілятором із файлу JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      uk: "Публікуйте свій застосунок усіма мовами",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Такий робочий процес створює труднощі:
+
+- Будь-яка зміна у файлі JSON вимагає перегенерації, перш ніж імпорт спрацює або оновляться типи.
+- Згенеровану папку `paraglide/` доводиться або фіксувати в git (що призводить до конфліктів злиття у згенерованих файлах під час кожного PR зі зміною тексту), або ігнорувати (що вимагає кроку генерації перед кожною перевіркою типів, тестом і завданням CI).
+- Кожен рядок стає викликом функції. Константи перетворюються на `m.key()` всюди, навіть там, де цілком вистачило б звичайного статичного значення.
+
+## Tree Shaking: перевірте свій бандл
+
+Головна обіцянка Paraglide полягає в тому, що невикористані повідомлення видаляються за допомогою tree shaking, оскільки кожне повідомлення є окремим експортом. У бенчмарку Svelte + Vite це працює саме так, як заявлено.
+
+В інших середовищах цього не сталося. У наших тестах на [Next.js](https://intlayer.org/uk/doc/benchmark/nextjs) сторінки Paraglide важать на 14 KB більше за базовий додаток, тоді як `next-intlayer` додає лише 0.3 KB. Попередні виміри на TanStack Start також показали, що повідомлення з інших сторінок потрапляли в бандл поточного маршруту.
+
+Tree shaking залежить від вашого бандлера (Turbopack, Rolldown, Rollup), способу імпорту повідомлень (`import { m }` проти `import * as m`) та аналізу побічних ефектів. Якщо ви обираєте Paraglide через компактність, відкрийте візуалізатор бандла та перевірте, чи працює це у вашому додатку.
+
+## Відсутність динамічного завантаження
+
+Це фундаментальне структурне обмеження. У Paraglide немає можливості завантажувати по одній локалі за раз: кожна функція повідомлення статично імпортує реалізацію кожної мови, тому абсолютно всі мови потрапляють у ваш клієнтський бандл.
+
+При 2 мовах половина переданих даних перекладів витрачається марно, що відповідає витоку локалі близько ~50%, виміряному вище. При 10 мовах марно витрачається 90%. При 30 мовах - 97%.
+
+Перехід на динамічне завантаження також не вирішив би проблеми: коли кожне повідомлення є окремою функцією, ліниве завантаження кожної з них створило б тисячі мережевих запитів.
+
+Intlayer дозволяє обирати стратегію глобально або для кожного словника окремо:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Що відправляється клієнту                                     | vs. Paraglide                     |
+| ------------ | ------------------------------------------------------------- | --------------------------------- |
+| `static`     | Усі локалі словників, які використовує сторінка               | Теоретично той самий обсяг        |
+| `dynamic`    | Лише поточна локаль, ліниве завантаження для кожного словника | **У N разів менше** при N локалях |
+| `fetch`      | Лише поточна локаль, отримана через Live Sync API             | **У N разів менше** при N локалях |
+
+Завдяки [трансформації під час збірки](https://intlayer.org/uk/doc/concept/bundle-optimization) та режиму `importMode: 'static'`, Intlayer теоретично завантажує рівно той самий обсяг даних, що й Paraglide. А в режимах `'dynamic'` або `'fetch'` він завантажує лише те, що потрібно поточній мові: для додатку на N мовах обсяг переданих перекладів у N разів менший, ніж у Paraglide.
+
+## Де Paraglide усе ще доречний
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite з невеликою кількістю мов">
+
+Якщо ваш стек побудований на Svelte з Vite і ви підтримуєте дві або три мови, tree shaking працює за планом, а накладні витрати на додаткові локалі залишаються незначними.
+
+</Accordion>
+<Accordion header="Наявний робочий процес із inlang">
+
+Якщо ваша команда вже використовує екосистему inlang (Fink, Sherlock, плагіни форматів повідомлень), Paraglide нативно інтегрується в цей процес.
+
+</Accordion>
+</AccordionGroup>
+
+## Спробуйте на власному додатку
+
+Перевірте обсяг передачі даних та витоки локалей вашого робочого додатку за допомогою безкоштовного інструменту [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner):
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Встановлення Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Додаткові матеріали
+
+- [Бенчмарк i18n TanStack Start](https://intlayer.org/uk/doc/benchmark/tanstack)
+- [Бенчмарк i18n Next.js](https://intlayer.org/uk/doc/benchmark/nextjs)
+- [Оптимізація бандла та `importMode`](https://intlayer.org/uk/doc/concept/bundle-optimization)
+- [Як вибрати бібліотеку i18n для React](https://intlayer.org/uk/blog/how-to-pick-react-i18n-library)
+- [Аргументи на користь компіляторного підходу до інтернаціоналізації](https://intlayer.org/uk/blog/compiler-vs-declarative-i18n)